| *** tpb has joined #litex | 00:00 | |
| *** Dolu has quit IRC | 00:33 | |
| *** Dolu has joined #litex | 00:36 | |
| *** futarisIRCcloud has quit IRC | 02:01 | |
| *** futarisIRCcloud has joined #litex | 03:56 | |
| *** futarisIRCcloud has quit IRC | 07:05 | |
| *** Xark has quit IRC | 08:32 | |
| *** Xark has joined #litex | 08:35 | |
| daveshah | https://usercontent.irccloud-cdn.com/file/XxsV6udA/IMG_20190604_132240.jpg | 12:31 |
|---|---|---|
| daveshah | Poor Tux is a bit cold :P but litevideo and simplefb do work together | 12:32 |
| daveshah | Just need to swap R and B to warm Tux up | 12:32 |
| daveshah | looking good now https://usercontent.irccloud-cdn.com/file/NNc0bHJc/IMG_20190604_133507.jpg | 12:44 |
| somlo | daveshah: is that using the trellis board? | 13:03 |
| daveshah | Yup | 13:03 |
| somlo | nice | 13:03 |
| daveshah | Has a TFP410 serialiser for HDMI | 13:03 |
| _florent__ | daveshah: great! | 13:21 |
| daveshah | Code 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 curious | 13:22 |
| tpb | Title: GitHub - daveshah1/linux-on-litex-vexriscv at trellisboard_1gb_hack (at github.com) | 13:22 |
| daveshah | Currently intermingled with the 1GB support hack | 13: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 boards | 13:29 |
| _florent__ | daveshah: nice to see that it does not require too much lines of code | 13:30 |
| daveshah | Basically 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#L434 | 13:31 |
| tpb | Title: linux-on-litex-vexriscv/soc_linux.py at trellisboard_1gb_hack · daveshah1/linux-on-litex-vexriscv · GitHub (at github.com) | 13:31 |
| daveshah | Then https://github.com/daveshah1/linux-on-litex-vexriscv/blob/trellisboard_1gb_hack/buildroot/board/litex_vexriscv/litex_vexriscv_trellisboard.dts#L83 lets Linux see it | 13:32 |
| tpb | Title: linux-on-litex-vexriscv/litex_vexriscv_trellisboard.dts at trellisboard_1gb_hack · daveshah1/linux-on-litex-vexriscv · GitHub (at github.com) | 13:32 |
| daveshah | Not 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 you | 15:56 |
| _florent__ | somlo: you can use this: https://github.com/enjoy-digital/chubby75/tree/master/firmware | 15:57 |
| tpb | Title: chubby75/firmware at master · enjoy-digital/chubby75 · GitHub (at github.com) | 15:57 |
| _florent__ | and remove the sdram related part | 15:57 |
| somlo | thanks! | 15:59 |
| somlo | just 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 disappear | 16: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 toolchain | 17:43 |
| somlo | \o/ litex+rocket tftp: https://imgur.com/QKaMfTR | 18:38 |
| tpb | Title: Imgur: The magic of the Internet (at imgur.com) | 18:38 |
| *** ambro718 has joined #litex | 18:40 | |
| ambro718 | Hi, 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 |
| somlo | what'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 |
| daveshah | somlo: very nice¡ | 18:42 |
| daveshah | *! | 18:42 |
| somlo | daveshah: I guess I should actually get litex_vexriscv_linux working, then "port" it to 64bit Rocket | 18:45 |
| somlo | might be interesting to get all the interleaved MMIO and cached-RAM regions set up correctly :) | 18:45 |
| somlo | right now, with "standard" litex, I have it easy -- anything below 0x8000_0000 is cached, anything above is MMIO | 18:47 |
| somlo | https://github.com/enjoy-digital/litex/pull/193 for memcpy (orthogonal enough w.r.t. CSR alignment to merit its own PR) | 19:01 |
| tpb | Title: software/libbase: memcpy: simple, arch-width agnostic implementation by gsomlo · Pull Request #193 · enjoy-digital/litex · GitHub (at github.com) | 19:01 |
| somlo | that 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 |
| tpb | Title: [RFC - Do NOT Pull] Align MMIO/CSRs on 64-bit address boundary · enjoy-digital/litex@0ac6536 · GitHub (at github.com) | 19:05 |
| ambro718 | What 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-vexriscv | 19:41 |
| tpb | Title: 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 one | 19:44 |
| _florent__ | ambro718: all the assignements you add to sync take effect at the next clock edge | 19: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 |
| ambro718 | I'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 want | 19:47 |
| ambro718 | In 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 code | 19:48 |
| ambro718 | To 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 advice | 19:53 |
| somlo | no changes in litex's netboot routines, besides fixing memcpy | 19:54 |
| somlo | oh, 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 |
| mithro | somlo: 1MHz? | 20:09 |
| somlo | mithro: in the simulator; it goes up to 50MHz on e.g. ecp5versa or nexys4ddr | 20:10 |
| mithro | Ahh | 20:10 |
| somlo | https://github.com/enjoy-digital/litex/pull/194 | 20:23 |
| tpb | Title: [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 |
| Dolu | daveshah: Nice terminal :D | 20:24 |
| ambro718 | Is 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 it | 20:25 |
| somlo | but 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 soon | 20:58 |
| _florent__ | ambro718: If(condition1, signal.eq(foo)).Elif(condition2, signal.eq(bar)) | 20:59 |
| ambro718 | Yeah 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 |
| ambro718 | What 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 |
| Dolu | There 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% sirq | 21: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 |
| Dolu | Running some sim now to figure out what is happening | 21:19 |
| ambro718 | What's the proper way to assign a default value to a signal outside of certain fsm states? | 21:25 |
| Dolu | Also, 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 IRC | 23:03 | |
| *** futarisIRCcloud has joined #litex | 23:45 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
