| *** tpb has joined #litex | 00:00 | |
| futarisIRCcloud | _florent__ / Dolu1990 / daveshah: So I made the changes for ulx3s and tried compiling for 12F and 25F (using FOSS tools). It fits, but I don't have access to a ulx3s to test it on, though. I think gojimmypi has a 12F though... | 03:38 |
|---|---|---|
| keesj | daveshah: what server are you using? the one with dnsmasq or some tftpd? | 06:49 |
| keesj | dnsmasq is quite reliable in my experience | 06:50 |
| keesj | the latter not | 06:50 |
| daveshah | keesj: tftp-hpa, so the latter | 07:43 |
| daveshah | I'll try dnsmasq | 07:43 |
| daveshah | futarisIRCcloud: Awesome | 07:43 |
| daveshah | How are you planning to boot it (the ULX3S doesn't have Ethernet) | 07:44 |
| futarisIRCcloud | daveshah: SPI flash, much like arty does. | 07:44 |
| daveshah | Ah, I didn't realise it had enough | 07:44 |
| daveshah | Some of the early ULX3Ss only have 4MB | 07:45 |
| futarisIRCcloud | Flash: Quad-SPI Flash IS25LP128F (4/8/16 MB for FPGA config and user data) | 07:45 |
| futarisIRCcloud | I suppose someone can load things over jtag or use the esp32. | 07:45 |
| daveshah | The FOSS tools don't support the SPI flash either yet (need to sort out the MCLK primitive, and write some script to deal with the SPI over JTAG stuff) | 07:48 |
| futarisIRCcloud | flterm over ttyUSB serial should work at the very least. | 07:50 |
| daveshah | Yes, might want to use something a bit faster than 115200 though | 07:51 |
| _florent__ | it should work up to 3Mbauds | 07:53 |
| keesj | http://paste.ubuntu.com/p/KsbzwW6HSK/ (my setup) I have two network card and one of them I configured using a static address. I am running ubuntu (that already has dnsmasq running). I start a second session with the config in the link (dhcp server and tftp boot). I am quite carefull to not play dhcp server in the office | 07:53 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 07:53 |
| daveshah | _florent__: perfect, think that's the limit of the SPI chip the ULX3S uses too | 07:54 |
| futarisIRCcloud | Yep. We could also get valentyusb running in the litex BIOS... | 07:54 |
| _florent__ | we would also boot from SDCard with the ULX3S | 07:55 |
| daveshah | That would be great | 07:55 |
| _florent__ | i saw the discussion about that on twitter, i was also planning to add LiteSDCard boot support to LiteX BIOS | 07:55 |
| daveshah | Guess we could also have Linux SD access, even if just using GPIO for now to avoid custom drivers | 07:55 |
| daveshah | Perfect | 07:56 |
| _florent__ | LiteSDCard is not resource optimal for now, lots of resources are lost on CDC (the PHY is running in another clock domain) | 07:57 |
| _florent__ | we could have a minimal version that just runs with the sys_clk and remove this CDC | 07:57 |
| daveshah | If you ran the link at 2x system clock, you could probably avoid the need for arch-specific DDR primitives too | 08:02 |
| _florent__ | yes, that would be nice to have something vendor agnostic | 08:04 |
| _florent__ | daveshah: i haven't yet looked how you integrated ethernet on your previous linux work, could you eventually provide me the linux patches, config, dts and directions on how to integrate it? | 08:06 |
| _florent__ | for now we could probably just provide the linux patches and make buildroot apply the patches directly during the build | 08:07 |
| daveshah | _florent__: yes, that should work | 08:08 |
| _florent__ | this avoid having to maintain a buildroot/linux kernel fork | 08:08 |
| daveshah | I'll look at the patches I made for 4.19 and see if they all still work on 5 | 08:08 |
| _florent__ | ok thanks | 08:09 |
| _florent__ | btw, i just tested rebuilding the versa5g target, it's working fine here too | 08:09 |
| futarisIRCcloud | litex ethernet driver doesn't really work well in linux. I just e-mailed Joel earlier today... | 08:09 |
| daveshah | If you are curious, it's pretty much all commits from e736fb4 on https://github.com/daveshah1/litex-linux-riscv/commits/nfs | 08:10 |
| tpb | Title: Commits · daveshah1/litex-linux-riscv · GitHub (at github.com) | 08:10 |
| futarisIRCcloud | he said "I saw that some people had done some further work on the networkdriver. Something I keep meaning to clarify was that the driver was work in progress - I was quite surprised that anyone could use it for anything more than sending a handful of UDP packets. As people found out, it hadn't implemented the reuse of memory, so every packet that came in would consume more and more memory until the system OOMd." | 08:10 |
| daveshah | I added a free to fix that | 08:10 |
| daveshah | I also fixed another panic bug | 08:10 |
| daveshah | It was rock solid after that for a NFS rootfs with Yosys and nextpnr in it | 08:10 |
| daveshah | See https://github.com/daveshah1/litex-linux-riscv/commit/5c46c48d2b91fbcd5030a16155e09eacf22bb8e0 and https://github.com/daveshah1/litex-linux-riscv/commit/ac29e8f8771681daa29ab690011730aad32cc033 | 08:11 |
| tpb | Title: liteeth: memory leak fix · daveshah1/litex-linux-riscv@5c46c48 · GitHub (at github.com) | 08:11 |
| futarisIRCcloud | I should just make a patch, and test it in buildroot (on arty). | 08:12 |
| futarisIRCcloud | https://github.com/futaris/linux-on-litex-vexriscv/commits/ulx3s | 08:12 |
| tpb | Title: Commits · futaris/linux-on-litex-vexriscv · GitHub (at github.com) | 08:12 |
| futarisIRCcloud | OlofK has a ULX3S at latchup.io ... | 08:19 |
| _florent__ | futarisIRCcloud: i also have one and daveshah too | 08:23 |
| futarisIRCcloud | So it looks like the esp32 doesn't have a driver for linux (esp8689), like the esp8266 had (esp8089). | 08:40 |
| *** Dolu has joined #litex | 10:03 | |
| Dolu | daveshah : I added the yesterday specified option to relax the MMU translation timings for the D$. It improve timings by 6 Mhz in my case (unless that's seed luck ^^) | 10:42 |
| Dolu | I used sbt "runMain vexriscv.GenCoreDefault --externalInterruptArray=true --csrPluginConfig=linux-minimal --singleCycleMulDiv false --dBusCachedRelaxedMemoryTranslationRegister true --prediction none" on the enjoy-digital master head. | 10:42 |
| Dolu | But in all try i did, the critical paths names where completly eated by Yosys. Did you used a specific option/command to get them in the reports to sent me ? Or it was directly like this at the end of the synthesis logs ? | 10:45 |
| daveshah | Dolu: there was a bug because a recent change in abc | 11:59 |
| daveshah | https://github.com/YosysHQ/yosys/pull/989 fixes it but isn't merged yet | 11:59 |
| daveshah | Then the net names should be more sensible (also make sure to look at net, not cell names) | 12:00 |
| daveshah | _florent__: I've added the liteeth driver as a kernel patch here: https://github.com/daveshah1/linux-on-litex-vexriscv/tree/linux_liteeth | 13:27 |
| tpb | Title: GitHub - daveshah1/linux-on-litex-vexriscv at linux_liteeth (at github.com) | 13:27 |
| daveshah | It isn't working yet however, as I can't figure out how to wire up the interrupt in the dts | 13:28 |
| daveshah | I think the external interrupt controller might not be being set up correctly, afaik nothing else is using it in Linux yet (timer is a special interrupt and UART is SBI) | 13:28 |
| Dolu | Let's me know if you need help for debugging the RISC-V side of stuff. Also on change compared to previously, is that now VexRiscv has a specific external interrupt pin for the supervisor mode. | 13:35 |
| Dolu | By the past i don't know exactly how they tricked the things to get it working without it. | 13:35 |
| daveshah | Previously Antmicro wrote a driver for the VexRiscv custom interrupt controller that used the CSRs | 13:35 |
| daveshah | I seem to remember tweaking how the interrupt was routed too | 13:36 |
| Dolu | Ahhh | 13:37 |
| Dolu | right | 13:37 |
| Dolu | So | 13:37 |
| Dolu | --externalInterruptArray add the ExternalInterruptArrayPlugin plugin which is a none standard way of having 32 bits external interrupts in CSR | 13:38 |
| Dolu | But that's machine mode only | 13:38 |
| Dolu | If it can help i can realy easily create the same for the supervisor mode. | 13:39 |
| Dolu | Actualy it is https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/vexriscv/plugin/ExternalInterruptArrayPlugin.scala for the machine mode one | 13:39 |
| tpb | Title: VexRiscv/ExternalInterruptArrayPlugin.scala at master · SpinalHDL/VexRiscv · GitHub (at github.com) | 13:39 |
| Dolu | Or we can have in this plugin a set of interrupt mask for both Machine and Supervisor mode. | 13:40 |
| Dolu | As far i remember, this none standard way of handeling a vector of interrupts in the CSR was made to be similar to the other softcore already presents in Migen/Litex | 13:43 |
| daveshah | Yes, one of the issues is that stuff needs to work both in the LiteX BIOS and in Linux | 13:45 |
| Dolu | So, modifying https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/vexriscv/plugin/ExternalInterruptArrayPlugin.scala, modifying the mask system to have maskMachine + maskSupervisor. And potentialy generating interrupts on both externalInterrupt and supervisorExternalInterrupt would be a good way of solving things ? | 13:48 |
| _florent__ | Dolu: yes that could be a way to start getting things working | 13:54 |
| _florent__ | daveshah: thanks for the liteeth patch, can't look now but i'll do a bit later | 13:55 |
| Dolu | So i go patch the ExternalInterruptArrayPlugin plugin ? | 13:56 |
| _florent__ | Dolu: having the same interrupt interface for the supervisor mode than for the machine mode seems fine yes (if i'm understanding things correctly) | 14:06 |
| Dolu | Right, it would use exactle the same physical 32 bits inputs pins | 14:11 |
| Dolu | And internal in the CPU, you will get to set of interrupts mask, one for machine mode, one for supervisor | 14:11 |
| Dolu | Which would then be used to drive the two external interrupts flags of the cpu internaly, externalInterrupt (for the machine mode) and supervisorExternalInterrupt | 14:12 |
| Dolu | I just have one question : Actualy, the pendings CSR flags is masked with the mask CSR val pendings = mask & RegNext(externalInterruptArray) | 14:13 |
| Dolu | Is that what you expect ? or when you read the pendings CSR, you expect to see all interrupts values, independently of the state of their mask ? | 14:13 |
| _florent__ | Dolu: this seems fine, we don't want to see the status of interrupts that are not enabled, if you are not doing the mask in hardware, we would have to do it in software | 14:16 |
| Dolu | right | 14:19 |
| Dolu | Ok | 14:19 |
| Dolu | So i go forward with that | 14:20 |
| _florent__ | thanks :) | 14:26 |
| Dolu | daveshah _florent__ : It's updated and merged in the VexRiscv-Verilog repo. You just have to regenerate the VexRiscv.v for your needs. No addititional arguements is required | 14:33 |
| _florent__ | great | 14:34 |
| daveshah | https://twitter.com/mad_archer_/status/1125409075020300290?s=19 | 14:45 |
| Dolu | Nice ^.^ | 14:50 |
| Dolu | So, there would be probably a bit of waveform debugging to figure out why for instance, on that system, the boot time is that slow. | 14:50 |
| daveshah | That system is SDRAM rather than DDR3 | 14:51 |
| Dolu | ok,What is the write policy of the L2 ? write-back or write through ? | 14:54 |
| Dolu | It is write-back, cool. | 14:57 |
| somlo | _florent__: is this line: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/boot.c#L27 strictly necessary, given that it's immediately followed by "irq_setie(0)" ? | 16:17 |
| tpb | Title: litex/boot.c at master · enjoy-digital/litex · GitHub (at github.com) | 16:17 |
| _florent__ | somlo: it will probably work without, but that's better to keep it (at least we know that the mask is cleared when jumping to new code) | 16:19 |
| somlo | Makes sense, thanks! -- I was just studying the code, trying to figure out how to integrate the rocket PLIC with the least possible disruption :) | 16:22 |
| somlo | It looks like once the PLIC is initialized, it has MMIO bitmap registers for mask/unmask and pending pins, so it should hopefully fit into the existing model, mostly. Substitute MMIO register read/write ops for csrr/csrw, but that's about it | 16:25 |
| somlo | the only funky part will be the isr() routine in bios/isr.c -- the PLIC has this thing where one "claims" an interrupt, then handles it, then notifies the PLIC of its "completion" | 16:27 |
| somlo | but that's a small routine, I can just #ifdef a rocket-specific one in its place | 16:28 |
| keesj | so WOW all this stuff amazing | 17:17 |
| Dolu | daveshah, _florent__ : For the vector interrupt, notice the CSR id at https://github.com/enjoy-digital/VexRiscv-verilog/blob/master/src/main/scala/vexriscv/GenCoreDefault.scala#L205 | 17:25 |
| tpb | Title: VexRiscv-verilog/GenCoreDefault.scala at master · enjoy-digital/VexRiscv-verilog · GitHub (at github.com) | 17:25 |
| daveshah | So I think the Antmicro Vexriscv IRQ driver (https://github.com/daveshah1/litex-linux-riscv/blob/master/drivers/irqchip/irq-vex.c) will need some tweaking, and integration with the new kernel, to get the Ethernet interrupts working | 17:29 |
| tpb | Title: litex-linux-riscv/irq-vex.c at master · daveshah1/litex-linux-riscv · GitHub (at github.com) | 17:29 |
| Dolu | From a hardware point of view, just swapping the CSR ID should be fine | 17:39 |
| Dolu | It would then generate a regular Supervisor External Interrupt. I'm just not sure how the Supervisor External Interrupt is binded to that irq driver. | 17:40 |
| daveshah | Yeah, in the old system the Linux startup code was hacked to jump to vex_handle_irq when SEI occurred | 17:41 |
| daveshah | Not sure how upstream Linux does this | 17:41 |
| daveshah | Seems like it calls handle_arch_irq https://github.com/torvalds/linux/blob/master/arch/riscv/kernel/irq.c#L54 | 17:44 |
| tpb | Title: linux/irq.c at master · torvalds/linux · GitHub (at github.com) | 17:44 |
| daveshah | need to work out where that goes | 17:44 |
| *** Dolu has quit IRC | 17:45 | |
| daveshah | aha, looks like we use set_handle_irq to set this function as a IRQ handler | 17:45 |
| daveshah | https://github.com/torvalds/linux/blob/master/kernel/irq/handle.c#L214 | 17:45 |
| tpb | Title: linux/handle.c at master · torvalds/linux · GitHub (at github.com) | 17:45 |
| daveshah | (afaik CONFIG_GENERIC_IRQ_MULTI_HANDLER is always set on RISC-V) | 17:46 |
| *** Dolu has joined #litex | 19:05 | |
| *** Dolu has quit IRC | 19:10 | |
| *** Dolu has joined #litex | 21:29 | |
| *** Dolu has quit IRC | 22:19 | |
| *** Dolu1990 has joined #litex | 22:20 | |
| *** Dolu1942 has joined #litex | 23:13 | |
| futarisIRCcloud | Wow. So in a weekend we've gone from vexrisc-linux running in sim, to arty, then ecp5 versa, then ulx3s. | 23:13 |
| futarisIRCcloud | daveshah: Yep. CONFIG_GENERIC_IRQ_MULTI_HANDLER is always on in RISC-V. | 23:14 |
| *** Dolu1990 has quit IRC | 23:17 | |
| Dolu1942 | XD | 23:17 |
| Dolu1942 | That's great ! | 23:18 |
| Dolu1942 | But please, let's me know if performance are poor, area is too big, or if things are going wrong | 23:21 |
| futarisIRCcloud | mithro: Some discussion in #debian-riscv on OFTC / irc.debian.org re rv32 debian | 23:41 |
| futarisIRCcloud | https://www.irccloud.com/pastebin/BuxZRyWg/ | 23:42 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 23:42 |
| *** Dolu1942 has quit IRC | 23:57 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!