Merge Ariane changes from Florian(ETHZ)

[jrrk]

I don't appear to have write access to this repo.

[zarubaf]

I can also fork this repository into pulp_platform and then we can better cherry-pick the changes. I don't think that my hacky register top is really useful for lowrisc.

[imphil]

@zarubaf that would be great!

[jrrk]

Good point, but I just want to capture the state of affairs at the moment, which is that  https://github.com/lowRISC/ariane.git branch rng-tools has your changes merged, and is receiving interrupts. <blah blah> Welcome to Buildroot buildroot login: root # more /proc/interrupts            CPU0   1:        164  SiFive PLIC   1  ttyS0   2:         48  SiFive PLIC   2  lowrisc-mmc   3:        313  SiFive PLIC   3  eth0 IPI0:         0  Rescheduling interrupts IPI1:         0  Function call interrupts I don't think it's any better or worse in reliability than the old PLIC at the moment. I'm not ruling out a software bug though.

…

On 03/04/2019 09:16, Florian Zaruba wrote: I can also fork this repository into |pulp_platform| and then we can better cherry-pick the changes. I don't think that my hacky register top is really useful for |lowrisc|. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAgF10KaGJhsufTS4ZeqZB82BuzQs1exks5vdGNFgaJpZM4cZ3p3>.

[jrrk]

Very happy for you to maintain the Ariane version of rv-plic. I have a feeling the new PLIC is a little better than before, but still not 100% robust: <snip> Welcome to Buildroot buildroot login: root # more /proc/interrupts            CPU0   1:        164  SiFive PLIC   1  ttyS0   2:         48  SiFive PLIC   2  lowrisc-mmc   3:        313  SiFive PLIC   3  eth0 IPI0:         0  Rescheduling interrupts IPI1:         0  Function call interrupts # mount -t msdos /dev/mmcblk0p1 /mnt [ 1427.040000] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. [ 1427.040000] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. # ls -l /mnt -rwxr-xr-x    1 root     root      15080360 Mar 29  2019 boot.bin # md5sum /mnt/boot.bin ebfb3e57120d51bedd49e37892e79700  /mnt/boot.bin # more /proc/interrupts            CPU0   1:        536  SiFive PLIC   1  ttyS0   2:      59080  SiFive PLIC   2  lowrisc-mmc   3:       6191  SiFive PLIC   3  eth0 IPI0:         0  Rescheduling interrupts IPI1:         0  Function call interrupts This is quite a heavyweight test. 15080360 bytes is 29454 sectors each of which has a command complete and a data complete interrupt. It would be much better if an I/O Minion dealt with 4K clusters autonomously, but I haven't got around to implementing this functionality. It would be even better if Ariane had a coherent AXI DMA slave port.

…

On 03/04/2019 09:16, Florian Zaruba wrote: I can also fork this repository into |pulp_platform| and then we can better cherry-pick the changes. I don't think that my hacky register top is really useful for |lowrisc|. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAgF10KaGJhsufTS4ZeqZB82BuzQs1exks5vdGNFgaJpZM4cZ3p3>.

[zarubaf]

I've bumped plic-dev with a forked version of this plic. Let's take this interesting discussion to the ariane issue tracker.

[eunchan]

I am happy to help the issue if it is related to the interrupt.

[jrrk]

Dear Eunchan,
I'm happy to say the rv_plic is working well up to a point, however after a large number of interrupts have been serviced, there seems to be a state of affairs where the interrupt source is active but this is not passed on to the CPU. I have some waveforms to send to you, but do not have your email and I do not think this platform supports attachments. If you want to meet to discuss how to reproduce the problem in simulation that would work for me as well. Meanwhile I am trying to reproduce a more accurate trace of exactly what sequence of writes goes into the PLIC to cause the problem.

[asb]

Hi Jonathan. Attachments are supported on GitHub (drag and drop onto the comment box from a graphical file manager). Eunchan is based in the Bay Area, so communicating via GitHub is most sensible. Once you have a trace or waveform that shows a problem, I'd suggest making a new issue on this repo to discuss further.