| *** tpb has joined #litex | 00:00 | |
| *** futarisIRCcloud has joined #litex | 01:41 | |
| *** futarisIRCcloud has quit IRC | 03:51 | |
| *** sb0 has joined #litex | 07:04 | |
| sb0 | _florent__: migen is missing from litex install_requires setup.py | 07:04 |
|---|---|---|
| sb0 | _florent__: also stream_packet.py doesn't need litex.gen, does it? | 07:33 |
| keesj | are you talking about https://github.com/enjoy-digital/litex/blob/master/litex_setup.py ? | 07:37 |
| tpb | Title: litex/litex_setup.py at master · enjoy-digital/litex · GitHub (at github.com) | 07:37 |
| keesj | or perhaps this one https://github.com/enjoy-digital/litex/blob/master/setup.py ? | 07:37 |
| tpb | Title: litex/setup.py at master · enjoy-digital/litex · GitHub (at github.com) | 07:37 |
| keesj | I am playing the litesdcard (and gateware for the first time) how do I load the firmware/software stuff? after flashing I am getting the BIOS but not the firmware https://github.com/enjoy-digital/litesdcard/tree/master/litesdcard/firmware | 07:52 |
| tpb | Title: litesdcard/litesdcard/firmware at master · enjoy-digital/litesdcard · GitHub (at github.com) | 07:52 |
| keesj | or.. is there a litex_serial upload thingy? | 08:03 |
| keesj | it is documented in the README https://github.com/enjoy-digital/litesdcard/blob/master/README#L83 | 08:17 |
| tpb | Title: litesdcard/README at master · enjoy-digital/litesdcard · GitHub (at github.com) | 08:17 |
| _florent__ | sb0: migen is installed manually with https://github.com/enjoy-digital/litex/blob/master/litex_setup.py#L12 | 08:30 |
| tpb | Title: litex/litex_setup.py at master · enjoy-digital/litex · GitHub (at github.com) | 08:30 |
| _florent__ | sb0: i'll check for litex.gen in stream_packet | 08:33 |
| *** futarisIRCcloud has joined #litex | 08:33 | |
| _florent__ | keesj: to load the firmware, you need to run litex_term /dev/ttyUSBX --kernel=firmware.bin, it will load the firmware over serial | 08:35 |
| keesj | thanks | 08:43 |
| sb0 | _florent__: then why is pyserial in setup.py? | 08:59 |
| sb0 | afaik even things that are installed manually should be in install_requires | 09:00 |
| sb0 | _florent__: also in test_axi.py, you do not need from litex.gen.sim import * | 09:20 |
| _florent__ | sb0: can you give a bit of context for these questions? | 09:21 |
| sb0 | _florent__: it's just good coding practice that things that are not required should not be imported | 09:21 |
| _florent__ | sb0: i don't mind adding migen to install_requires, but that's also not in misoc | 09:22 |
| sb0 | ah, let me add it then | 09:22 |
| sb0 | thanks for pointing this out | 09:22 |
| _florent__ | sb0: for litex.gen.sim in test_axi.py, in fact that's because i use the modified version of the migen simulator that in is litex.gen | 09:22 |
| sb0 | ah, I see | 09:23 |
| sb0 | btw this runs just fine with the unmodified nmigen simulator | 09:23 |
| _florent__ | sb0: the changes make it dumps to the .vcd continously instead of writing at the end of the simulation | 09:23 |
| _florent__ | sb0: that's useful when you don't want to wait the end of the simulation to look at the .vcd and just do a refresh with gtkwave | 09:24 |
| _florent__ | sb0: but yes, the simulation is also working with default simulator | 09:25 |
| sb0 | ah, is gtkwave handling this fine? | 09:25 |
| sb0 | i've seen it segfault on corrupted vcd files but that was a long time ago | 09:25 |
| _florent__ | sb0: i can remove the litex.gen import if you want to reuse this code outside of litex, it was mostly useful for debug | 09:25 |
| _florent__ | yes gtkwave is handling this fine (at least most of the time... :)) | 09:26 |
| sb0 | oh, I can remove it easily with a substituteInPlace in nix | 09:26 |
| _florent__ | ok | 09:26 |
| sb0 | so no problem leaving it there if it's useful | 09:26 |
| sb0 | on the other hand the stream_packet import isn't useful and should go afaict | 09:27 |
| _florent__ | are you reusing the AXI code in HeavyX? | 09:27 |
| sb0 | I'm packaging most of litex into heavyx | 09:27 |
| _florent__ | yes it's probably true for this one, i'll look at that | 09:27 |
| _florent__ | ok nice, so the AXI simulation is working fine with nmigen compatibility mode and nmigen simulator? | 09:29 |
| sb0 | yes | 09:29 |
| sb0 | so the idea is to make lite* cores available to heavyx designs, not sure how far the interoperability can go but I'm experimenting | 09:30 |
| _florent__ | ok, i thought nmigen compat mode still required some change to the code so wasn't expected for example stream.Endpoint from LiteX to work with it, great if it's the case | 09:32 |
| sb0 | well the test passes but there may be issues | 09:36 |
| sb0 | were there issues with Record? I had heard of those but iirc they were fixed a long time ago | 09:40 |
| _florent__ | sb0: https://github.com/enjoy-digital/litex/commit/5318bcd3c3bd97a0e2cae6ea384b09f3cb755f24 | 09:40 |
| tpb | Title: setup.py: add migen to install_requires · enjoy-digital/litex@5318bcd · GitHub (at github.com) | 09:40 |
| _florent__ | sb0: https://github.com/enjoy-digital/litex/commit/ab1f58047064c459475970d11e540c6e0e5367a8 | 09:40 |
| tpb | Title: test/test_axi: remove litex.gen.sim import (was only useful for debug) · enjoy-digital/litex@ab1f580 · GitHub (at github.com) | 09:40 |
| _florent__ | in fact, i litex.gen import in stream_packet is needed for the reverse_bytes function | 09:41 |
| _florent__ | litex.gen.common | 09:41 |
| _florent__ | i could change the import to from litex.gen.common import * if it's better for you | 09:42 |
| sb0 | https://git.m-labs.hk/M-Labs/HeavyX/commit/4c7ca4a8d1bfec75dc04eea292e5023c30eb8fc5 | 09:43 |
| tpb | Title: add experimental LiteX package · 4c7ca4a8d1 - M-Labs Git (at git.m-labs.hk) | 09:43 |
| sb0 | https://nixbld.m-labs.hk/build/6275/log | 09:43 |
| tpb | Title: Hydra - Log of build 6275 of job fpga:heavyx:litex (at nixbld.m-labs.hk) | 09:43 |
| sb0 | quite a hack but seems to work | 09:43 |
| _florent__ | ok thanks interesting | 09:50 |
| *** sb0 has quit IRC | 10:13 | |
| *** futarisIRCcloud has quit IRC | 12:13 | |
| *** ambro718 has joined #litex | 16:36 | |
| somlo | Rocket + Litex booting BBL (github.com/riscv/riscv-bbl): http://www.contrib.andrew.cmu.edu/~somlo/BTCP/RocketLitexBBL.mp4 | 17:51 |
| _florent__ | somlo: nice, thanks for sharing | 18:47 |
| ambro718 | Now all that's left is to use that to boot u-boot :) | 18:52 |
| ambro718 | What exactly is BBL anyway? I can't find much info. | 18:53 |
| sorear | bbl is https://github.com/riscv/riscv-pk | 18:55 |
| tpb | Title: GitHub - riscv/riscv-pk: RISC-V Proxy Kernel (at github.com) | 18:55 |
| ambro718 | What's it for, why is it needed? I am used to bootloader loading kernel directly. | 18:56 |
| sorear | the name is a misnomer; it is not a boot *loader*, it is an implementation of the SBI + M-mode emulator for riscv features omitted from rocket | 18:56 |
| ambro718 | It's needed for rocket but not vexriscv? | 18:56 |
| sorear | for instance riscv requires misaligned loads/stores to work, rocket generates traps for them → bbl contains a trap handler to emulate misaligned loads/stores | 18:56 |
| sorear | i have no idea what vexriscv does or does not require | 18:57 |
| sorear | there is a newer project "opensbi" which does exactly the same things bbl does | 18:57 |
| ambro718 | I'm not sure I like the idea of needing extra blobs to boot a kernel... | 18:58 |
| daveshah | This is the equivalent for VexRiscv: https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/emulator/main.c | 18:59 |
| tpb | Title: linux-on-litex-vexriscv/main.c at master · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com) | 18:59 |
| daveshah | It implements timer & console SBIs and some missing atomics | 18:59 |
| ambro718 | They should just fix the cores to implement risc-v :) | 19:00 |
| daveshah | Doesn't seem to do misaligned load/stores | 19:00 |
| somlo | it should also handle FPU traps, so the kernel and above *think* they have rv64gc | 19:03 |
| somlo | I'm in the middle of trying to figure out if the uart model exposed by litex is supported in linux, and, more interestingly, if being forced to align MMIO registers on 64-bit boundaries will screw up any otherwise available support :) | 19:05 |
| somlo | also, the BBL is designed to encapsulate the kernel as its "payload", so one would only have to tftp one single blob (default LiteX configuration) | 19:07 |
| somlo | ambro718 ^^ | 19:07 |
| ambro718 | somlo: yes but is it built automatically as part of the kernel? It doesn't add complexity to the build process? | 19:08 |
| sorear | no, it massively complicates the build process | 19:09 |
| somlo | ambro718: it's a wrapper *around* vmlinux (optionally -- you could have it as a separate blob as well) | 19:10 |
| ambro718 | Yeah that's my point, anyone who wants to use rocket basically needs to learn about bbl and get it working right. | 19:10 |
| sorear | is that "optionally" a thing now? back when I was doing it, it was always a wrapper and you had to recompile bbl after linux every. damn. time. | 19:10 |
| somlo | sorear: step 1. build kernel, obtain vmlinux file; step 2. build bbl, using vmlinux file from step 1, obtain boot.bin; step 3. profit! :) | 19:11 |
| sorear | never could get anyone to care | 19:11 |
| ambro718 | Someone should just get very angry and implement the missing bits in riscv. | 19:12 |
| ambro718 | I mean rocket or whatever core. | 19:12 |
| somlo | sorear: for the record, I'm using it mostly for the (promised) FPU emulation, and because lowRISC uses it and I figured out how it all hangs together :) | 19:13 |
| somlo | not really emotionally invested in it, either way | 19:13 |
| sorear | i would like people to stop complaining to me about things I have already done everything in my power to fix | 19:13 |
| sorear | it's exhausting | 19:13 |
| ambro718 | No complaining to you really :) | 19:14 |
| ambro718 | Not | 19:14 |
| somlo | sorear: re. "optionally" -- seems to say so in that "default payload" message it prints out :) I personally don't care too much at the moment, too many other moving parts to juggle... | 19:15 |
| somlo | and, just to be pedantic, I don't think it's *complicated*. Annoying as heck? yeah, if one has to do it over and over and over; but not complicated :D | 19:16 |
| somlo | sorear: I looked at that message, and it says "firmware-only mode" in cooperation with QEMU's -bios and -kernel command line options | 19:20 |
| somlo | which means "not really optional" for my scenario, since I'm not using QEMU | 19:21 |
| somlo | I guess one explanation for why it works the way it does is that it can avoid having its own software implementation of a network stack, microSD, etc. -- if the kernel is linked in as a "payload", or already in memory by some other magic (QEMU), all BBL has to do is jump there (after installing the requisite M-mode trap handler) | 19:22 |
| sorear | qemu isn't doing anything super magical here, it's just getting the kernel from a device tree slot | 19:23 |
| sorear | so instead of 2 blobs (bbl, initramfs) you have 3 (bbl, vmlinux, initramfs) | 19:23 |
| ambro718 | and device tree? | 19:24 |
| somlo | you can have initramfs linked into the kernel, so back to a single blob: (bbl (kernel (initramfs))) | 19:25 |
| somlo | ambro718: the "right way" would be for the gateware to provide the device tree to the BBL and above | 19:25 |
| sorear | unfortunately, I was trying to debug something in userspace at the time | 19:26 |
| somlo | you can also get away with linking the DTB blob into the BBL -- useful during development, and/or if you're trying to save BRAMS on the FPGA side | 19:26 |
| ambro718 | device tree won't be embedded into hardware, it can vary between kernel versions for example | 19:26 |
| sorear | why would the kernel developers do that | 19:27 |
| sorear | were you here long enough to remember config string? | 19:27 |
| somlo | ambro718: not *hardware* hardware, but ROM (firmware) | 19:27 |
| sorear | the risc-v devs, pre-2016, took a look at device tree, decided that it wasn't suitable for risc-v because it was big endian (seriously) | 19:28 |
| somlo | it's the firmware's job to tell the kernel where things are on the hardware. So even BBL "should" be told that information from "below", whatever "below" might be | 19:28 |
| ambro718 | with that perspective it would also make sense (and I think even more) for the firmware (missing instructions etc) to be in ROM and completely transparent to software. | 19:28 |
| sorear | they made their own kinda-like-device-tree format "config string" which was ASCII and a completely incompatible data model, and decreed in the spec that implementations should have a config string in ROM | 19:29 |
| sorear | we eventually convinced them that big endian wasn't a big deal and they should use the same data structure ppc and arm were already using | 19:29 |
| sorear | but they kept the "this is kernel version independent, should be used by all kernels not just Linux, and should be in ROM" parts | 19:29 |
| sorear | (being told "oops, device tree cannot be shared between kernel versions, we actually have no way to make hardware self describing" is pretty depressing) | 19:33 |
| ambro718 | That's why I think the most essential things should be standardized. For example, no mising instructions or features in cores, and standard interrupt controller. | 19:36 |
| ambro718 | Also big endian should die :) | 19:36 |
| somlo | ambro718: a 64bit rocket core with no FPU and no MMU, and litex wrapped around it, will consume cca. 45K CLBs on an ECP5 FPGA | 19:37 |
| ambro718 | Not familiar with the numbers, what's your point? | 19:38 |
| somlo | add in the MMU (so Linux works), and it's up to 65K CLBs (requiring an 85K ECP5 :) | 19:38 |
| sorear | is ariane better? | 19:39 |
| somlo | *try* to add an FPU, and 85K is not enough by half, so you can't NOT emulate it :) | 19:39 |
| somlo | my point is that optional/missing instructions is a good thing :) | 19:40 |
| ambro718 | somlo: actually you can not emulate it, by compiling your code to link to SW fp routines | 19:40 |
| ambro718 | It doesn't have to be via a trap. | 19:40 |
| somlo | sorear: haven't tried ariane, so I don't know; rumor has it it's comparable in size to Rocket for similar feature sets, but I don't know first hand | 19:41 |
| somlo | ambro718: you can stick to integer-only programs, you can link in explicit fp support, or you can let fp instructions trap and have something like the BBL emulate | 19:42 |
| somlo | I strongly prefer the latter, just because it simplifies everything else... | 19:43 |
| sorear | I mean, have you looked at Rocket ASIC floorplans? the FPU is larger than the rest of the core combined, including the L1 cache | 19:43 |
| ambro718 | somlo: or have the kernel do the emulation, which is more convenient for users | 19:43 |
| sorear | and asics are much more favorable to logic vs. memory | 19:43 |
| ambro718 | Linux can do FP emulation for many architectures. | 19:43 |
| sorear | the rocket FPU is quite silly. it's a straightforward, "obviously correct", design with a fully combinatorial multiply-add unit | 19:44 |
| somlo | ok, so the Linux kernel can install the trap handlers in S-mode, instead of having the BBL install them in M-mode | 19:44 |
| sorear | (there are enough edge cases in rounding that this isn't trivial, but it's much simpler than a multicycle design would be) | 19:45 |
| sorear | but, the rest of the pipeline cannot come anywhere close to matching a 2 flop/cycle FPU, so you have the giant multiplier that's 90% idle even in numerics code | 19:45 |
| ambro718 | sorear: unless it can get better utilized with vector instructions? | 19:47 |
| sorear | (remember, rocket's Purpose is to be the host to Hwacha, so the area of the scalar core isn't terribly important and they needed a highly pipelined FPU for the vector side) | 19:47 |
| sorear | there is no public implementation of anything close to riscv/riscv-v-spec on the Rocket base | 19:48 |
| somlo | oh well, back to screwing around with the UART :) | 19:52 |
| * felix_ slightly prefers big endian format. but most stuff is little endian nowadays and sadly people don't care to write endian-safe code :/ | 20:28 | |
| Dolu | daveshah : Yes unaligned access are missing | 21:00 |
| somlo | oh, wait... everything from kernel on up uses sbi_console_[put|get]char(), which is an ecall into the "emulator", so if I already have the uart working in the BBL I'm done :) | 22:04 |
| somlo | I was trying hard to outsmart myself, unnecessarily, as it turns out :D | 22:05 |
| somlo | well, on that note, I'm fried, but cautiously optimistic about tomorrow -- see y'all later | 22:06 |
| Dolu | somlo : this + set a timer, and time CSR emulation | 22:07 |
| somlo | Dolu: I will probably have to figure out the timer, since I think Rocket comes with one built in ("north" of the PLIC, which is also built in) | 22:09 |
| somlo | anyhow, looks like my "medium-core" rocket config option is on its way upstream, which means tomorrow I'll probably send PRs to update the rocket-litex-verilog repo and then add a "linux" variant to the rocket cpu option in litex (https://github.com/freechipsproject/rocket-chip/pull/2004) | 22:14 |
| ambro718 | What's wrong here? If(self._interrupt_enabled and self._ring_count != 0 and self._next_ring_count == 0, | 22:28 |
| ambro718 | TypeError: Attempted to convert Migen value to boolean | 22:28 |
| ambro718 | How do I disable building ethernet software (libnet)? | 22:54 |
| daveshah | ambro718: I think you need to use & not and when building logic | 22:55 |
| ambro718 | daveshah: Yeah I figured that out | 22:55 |
| *** ambro718 has quit IRC | 23:43 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!