Tuesday, 2019-06-04

*** tpb has joined #litex00:00
*** Dolu has quit IRC00:33
*** Dolu has joined #litex00:36
*** futarisIRCcloud has quit IRC02:01
*** futarisIRCcloud has joined #litex03:56
*** futarisIRCcloud has quit IRC07:05
*** Xark has quit IRC08:32
*** Xark has joined #litex08:35
daveshahPoor Tux is a bit cold :P but litevideo and simplefb do work together12:32
daveshahJust need to swap R and B to warm Tux up12:32
daveshahlooking good now https://usercontent.irccloud-cdn.com/file/NNc0bHJc/IMG_20190604_133507.jpg12:44
somlodaveshah: is that using the trellis board?13:03
daveshahHas a TFP410 serialiser for HDMI13:03
_florent__daveshah: great!13:21
daveshahCode at https://github.com/daveshah1/linux-on-litex-vexriscv/tree/trellisboard_1gb_hack and https://github.com/daveshah1/litex/tree/trellisboard_1gb_hack if you are curious13:22
tpbTitle: GitHub - daveshah1/linux-on-litex-vexriscv at trellisboard_1gb_hack (at github.com)13:22
daveshahCurrently intermingled with the 1GB support hack13:22
_florent__daveshah: thanks, sure i'll look at that. I also wanted to add that for the others boards that have  HDMI/VGA, so your work will be useful also for the others boards13:29
_florent__daveshah: nice to see that it does not require too much lines of code13:30
daveshahBasically just https://github.com/daveshah1/linux-on-litex-vexriscv/blob/trellisboard_1gb_hack/soc_linux.py#L83 and  https://github.com/daveshah1/linux-on-litex-vexriscv/blob/trellisboard_1gb_hack/emulator/main.c#L43413:31
tpbTitle: linux-on-litex-vexriscv/soc_linux.py at trellisboard_1gb_hack · daveshah1/linux-on-litex-vexriscv · GitHub (at github.com)13:31
daveshahThen https://github.com/daveshah1/linux-on-litex-vexriscv/blob/trellisboard_1gb_hack/buildroot/board/litex_vexriscv/litex_vexriscv_trellisboard.dts#L83 lets Linux see it13:32
tpbTitle: linux-on-litex-vexriscv/litex_vexriscv_trellisboard.dts at trellisboard_1gb_hack · daveshah1/linux-on-litex-vexriscv · GitHub (at github.com)13:32
daveshahNot sure if there is a better place than the emulator for the init code...13:32
_florent__that's probably fine for now (and we could rename emulator if it's doing more than the initial emulation code)13:38
somlo_florent__: what's the simplest, silliest boot.bin one can try with "standard" litex to test tftp-boot with 64-bit?15:51
_florent__somlo: i can try to find one or prepare one for you15:56
_florent__somlo: you can use this: https://github.com/enjoy-digital/chubby75/tree/master/firmware15:57
tpbTitle: chubby75/firmware at master · enjoy-digital/chubby75 · GitHub (at github.com)15:57
_florent__and remove the sdram related part15:57
somlojust want to see it working before I try booting *linux* (which might require a different memory map altogether, based on how you all did it with linux-on-litex-vexriscv)16:01
mithro_florent__: Where is the best place to find a "basic arty-soc" ?16:37
mithro_florent__: Looks like "arty-soc" repo has disappear16:38
mithro_florent__: We are at the stage with prjxray / SymbiFlow that we would like to start understanding what is needed to support LiteX+LiteEth+LiteDRAM on Arty using the toolchain17:43
somlo\o/ litex+rocket tftp: https://imgur.com/QKaMfTR18:38
tpbTitle: Imgur: The magic of the Internet (at imgur.com)18:38
*** ambro718 has joined #litex18:40
ambro718Hi, if a sync statement assigns to a signal, and a subsequent sync statement reads it, does it get the new value or the original value?18:41
somlo_florent__: there's the 64bit CSR alignment patch, and I had to fix memcpy (which was optimized so much for rv32 that it was bombing out on 64-bit arch transfers)18:41
somlowhat's the best way to handle this, single PR with both patches and we can debate in the comments, or separate PRs per issue (csr alignment  orthogonal to 64-bit memcpy) ?18:42
daveshahsomlo: very nice¡18:42
somlodaveshah: I guess I should actually get litex_vexriscv_linux working, then "port" it to 64bit Rocket18:45
somlomight be interesting to get all the interleaved MMIO and cached-RAM regions set up correctly :)18:45
somloright now, with "standard" litex, I have it easy -- anything below 0x8000_0000 is cached, anything above is MMIO18:47
somlohttps://github.com/enjoy-digital/litex/pull/193 for memcpy (orthogonal enough w.r.t. CSR alignment to merit its own PR)19:01
tpbTitle: software/libbase: memcpy: simple, arch-width agnostic implementation by gsomlo · Pull Request #193 · enjoy-digital/litex · GitHub (at github.com)19:01
somlothat leaves https://github.com/enjoy-digital/litex/commit/0ac65365e43dd749ea1ed85854a59256e762bb98 which I'll post as a separate RFC/PR once we're done with memcpy...19:05
tpbTitle: [RFC - Do NOT Pull] Align MMIO/CSRs on 64-bit address boundary · enjoy-digital/[email protected] · GitHub (at github.com)19:05
ambro718What does this do:  sync += [signal.eq(signal+1), signal.eq(signal+1)] ? Is signal incremented by one or two?19:32
_florent__mithro: yes, i removed some repo that were experimental and too difficult to maintain.  The EthernetSoC target of https://github.com/enjoy-digital/litex/blob/master/litex/boards/targets/arty.py use LiteX+LiteDRAM+LiteEth and is the one used for linux-on-litex-vexriscv19:41
tpbTitle: litex/arty.py at master · enjoy-digital/litex · GitHub (at github.com)19:41
_florent__somlo: nice :), were some changes needed in the netboot code?19:42
_florent__ambro718: in your case, the last assignment to signal will win, so it will only increment by one19:44
_florent__ambro718: all the assignements you add to sync take effect at the next clock edge19:45
ambro718_florent__: Thanks. Are there any patterns to fix this "problem"? In particular, I may have some code that may increment a singal, and some code in a different place that may decrement it, and both should be done.19:45
ambro718I'd like to have these two pieces of code reasonably separate because one piece is generic and the other is more specific.19:47
_florent__ambro718: knowing that the last assignment wins, you can do multiple assignments but just be sure that will give you the behavior you want19:47
ambro718In VHDL I'd use a variable, initialize it from the signal, update it a number of times, then assign it to the signal.19:48
_florent__or you create increment/decrement signals, have the increment/decrement logic regrouped in your code, and use the increment/decrement signals in the others part of your code19:48
ambro718To use additional signals, good idea, thanks.19:49
somlo_florent__: if you mean the chubby boot.bin -- just alignment in linker.ld, and commenting out the sdram stuff per your advice19:53
somlono changes in litex's netboot routines, besides fixing memcpy19:54
somlooh, and I didn't (re)initialize interrupt handling or anything, just wanted to see if the litex bios can tftp a blob and jump to it successfully, which it now can :)19:57
somlo* which it now can even on the 64-bit arch :)19:58
mithrosomlo: 1MHz?20:09
somlomithro: in the simulator; it goes up to 50MHz on e.g. ecp5versa or nexys4ddr20:10
tpbTitle: [RFC - Do NOT Pull] Align MMIO/CSRs on 64-bit address boundary by gsomlo · Pull Request #194 · enjoy-digital/litex · GitHub (at github.com)20:23
somlo_florent__: I'm not sure this is complete (i.e., is there a check that ensures there aren't too many CSRs inside a device-specific bank)20:24
Doludaveshah: Nice terminal :D20:24
ambro718Is there a conditional expression in migen? As if, signal.eq(if condition then a else b).20:24
somlo_florent__: or that it's even the best way to go about it20:25
somlobut as a PR it might be easier for everyone who might care to review it...20:26
_florent__somlo: thanks for the pull request, i'll look at that soon20:58
_florent__ambro718: If(condition1, signal.eq(foo)).Elif(condition2, signal.eq(bar))20:59
ambro718Yeah that's what I wrote :)20:59
ambro718_florent__: Could you give a quick explanation on how eth_phy_description works? I'm guessing last_be is used to specify which byte in the data is the last during the last transaction for a packet?21:01
ambro718What about error? I really just need to know if there has been an error during reception to mark the packet as invalid so it won't be processed.21:05
DoluThere is currently an issue with the linux-litex-vexriscv SoC. When i run the top command, it show that the CPU is heavily in sirq : CPU:   0% usr   1% sys   0% nic  48% idle   0% io   0% irq  50% sirq21:16
Dolu(tested on arty). But i don't have that issue on some other systems with very similar linux setup (non-litex SoC)21:18
DoluRunning some sim now to figure out what is happening21:19
ambro718What's the proper way to assign a default value to a signal outside of certain fsm states?21:25
DoluAlso, there a miss spec implementation of the WFI instruction, which will make the linux freeze to death in a random time (hours). I'm fixing that now.22:25
*** ambro718 has quit IRC23:03
*** futarisIRCcloud has joined #litex23:45

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!