Wednesday, 2019-06-12

*** tpb has joined #litex00:00
*** futarisIRCcloud has joined #litex01:41
*** futarisIRCcloud has quit IRC03:51
*** sb0 has joined #litex07:04
sb0_florent__: migen is missing from litex install_requires setup.py07:04
sb0_florent__: also stream_packet.py doesn't need litex.gen, does it?07:33
keesjare you talking about https://github.com/enjoy-digital/litex/blob/master/litex_setup.py  ?07:37
tpbTitle: litex/litex_setup.py at master · enjoy-digital/litex · GitHub (at github.com)07:37
keesjor perhaps this one https://github.com/enjoy-digital/litex/blob/master/setup.py ?07:37
tpbTitle: litex/setup.py at master · enjoy-digital/litex · GitHub (at github.com)07:37
keesjI 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/firmware07:52
tpbTitle: litesdcard/litesdcard/firmware at master · enjoy-digital/litesdcard · GitHub (at github.com)07:52
keesjor.. is there a litex_serial upload thingy?08:03
keesjit is documented in the README https://github.com/enjoy-digital/litesdcard/blob/master/README#L8308:17
tpbTitle: 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#L1208:30
tpbTitle: 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_packet08:33
*** futarisIRCcloud has joined #litex08:33
_florent__keesj: to load the firmware, you need to run litex_term /dev/ttyUSBX --kernel=firmware.bin, it will load the firmware over serial08:35
keesjthanks08:43
sb0_florent__: then why is pyserial in setup.py?08:59
sb0afaik even things that are installed manually should be in install_requires09: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 imported09:21
_florent__sb0: i don't mind adding migen to install_requires, but that's also not in misoc09:22
sb0ah, let me add it then09:22
sb0thanks for pointing this out09: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.gen09:22
sb0ah, I see09:23
sb0btw this runs just fine with the unmodified nmigen simulator09:23
_florent__sb0: the changes make it dumps to the .vcd continously instead of writing at the end of the simulation09: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 gtkwave09:24
_florent__sb0: but yes, the simulation is also working with default simulator09:25
sb0ah, is gtkwave handling this fine?09:25
sb0i've seen it segfault on corrupted vcd files but that was a long time ago09: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 debug09:25
_florent__yes gtkwave is handling this fine (at least most of the time... :))09:26
sb0oh, I can remove it easily with a substituteInPlace in nix09:26
_florent__ok09:26
sb0so no problem leaving it there if it's useful09:26
sb0on the other hand the stream_packet import isn't useful and should go afaict09:27
_florent__are you reusing  the AXI code in HeavyX?09:27
sb0I'm packaging most of litex into heavyx09:27
_florent__yes it's probably true for this one, i'll look at that09:27
_florent__ok nice, so the AXI simulation is working fine with nmigen compatibility mode and nmigen simulator?09:29
sb0yes09:29
sb0so the idea is to make lite* cores available to heavyx designs, not sure how far the interoperability can go but I'm experimenting09: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 case09:32
sb0well the test passes but there may be issues09:36
sb0were there issues with Record? I had heard of those but iirc they were fixed a long time ago09:40
_florent__sb0: https://github.com/enjoy-digital/litex/commit/5318bcd3c3bd97a0e2cae6ea384b09f3cb755f2409:40
tpbTitle: setup.py: add migen to install_requires · enjoy-digital/[email protected] · GitHub (at github.com)09:40
_florent__sb0: https://github.com/enjoy-digital/litex/commit/ab1f58047064c459475970d11e540c6e0e5367a809:40
tpbTitle: test/test_axi: remove litex.gen.sim import (was only useful for debug) · enjoy-digital/[email protected] · GitHub (at github.com)09:40
_florent__in fact, i litex.gen import in stream_packet is needed for the reverse_bytes function09:41
_florent__litex.gen.common09:41
_florent__i could change the import to from litex.gen.common import * if it's better for you09:42
sb0https://git.m-labs.hk/M-Labs/HeavyX/commit/4c7ca4a8d1bfec75dc04eea292e5023c30eb8fc509:43
tpbTitle: add experimental LiteX package · 4c7ca4a8d1 - M-Labs Git (at git.m-labs.hk)09:43
sb0https://nixbld.m-labs.hk/build/6275/log09:43
tpbTitle: Hydra - Log of build 6275 of job fpga:heavyx:litex (at nixbld.m-labs.hk)09:43
sb0quite a hack but seems to work09:43
_florent__ok thanks interesting09:50
*** sb0 has quit IRC10:13
*** futarisIRCcloud has quit IRC12:13
*** ambro718 has joined #litex16:36
somloRocket + Litex booting BBL (github.com/riscv/riscv-bbl): http://www.contrib.andrew.cmu.edu/~somlo/BTCP/RocketLitexBBL.mp417:51
_florent__somlo: nice, thanks for sharing18:47
ambro718Now all that's left is to use that to boot u-boot :)18:52
ambro718What exactly is BBL anyway? I can't find much info.18:53
sorearbbl is https://github.com/riscv/riscv-pk18:55
tpbTitle: GitHub - riscv/riscv-pk: RISC-V Proxy Kernel (at github.com)18:55
ambro718What's it for, why is it needed? I am used to bootloader loading kernel directly.18:56
sorearthe 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 rocket18:56
ambro718It's needed for rocket but not vexriscv?18:56
sorearfor instance riscv requires misaligned loads/stores to work, rocket generates traps for them → bbl contains a trap handler to emulate misaligned loads/stores18:56
soreari have no idea what vexriscv does or does not require18:57
sorearthere is a newer project "opensbi" which does exactly the same things bbl does18:57
ambro718I'm not sure I like the idea of needing extra blobs to boot a kernel...18:58
daveshahThis is the equivalent for VexRiscv: https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/emulator/main.c18:59
tpbTitle: linux-on-litex-vexriscv/main.c at master · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com)18:59
daveshahIt implements timer & console SBIs and some missing atomics18:59
ambro718They should just fix the cores to implement risc-v :)19:00
daveshahDoesn't seem to do misaligned load/stores19:00
somloit should also handle FPU traps, so the kernel and above *think* they have rv64gc19:03
somloI'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
somloalso, 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
somloambro718 ^^19:07
ambro718somlo: yes but is it built automatically as part of the kernel? It doesn't add complexity to the build process?19:08
sorearno, it massively complicates the build process19:09
somloambro718: it's a wrapper *around* vmlinux (optionally -- you could have it as a separate blob as well)19:10
ambro718Yeah that's my point, anyone who wants to use rocket basically needs to learn about bbl and get it working right.19:10
sorearis 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
somlosorear: 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
sorearnever could get anyone to care19:11
ambro718Someone should just get very angry and implement the missing bits in riscv.19:12
ambro718I mean rocket or whatever core.19:12
somlosorear: 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
somlonot really emotionally invested in it, either way19:13
soreari would like people to stop complaining to me about things I have already done everything in my power to fix19:13
sorearit's exhausting19:13
ambro718No complaining to you really :)19:14
ambro718Not19:14
somlosorear: 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
somloand, 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 :D19:16
somlosorear: I looked at that message, and it says "firmware-only mode" in cooperation with QEMU's -bios and -kernel command line options19:20
somlowhich means "not really optional" for my scenario, since I'm not using QEMU19:21
somloI 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
sorearqemu isn't doing anything super magical here, it's just getting the kernel from a device tree slot19:23
sorearso instead of 2 blobs (bbl, initramfs) you have 3 (bbl, vmlinux, initramfs)19:23
ambro718and device tree?19:24
somloyou can have initramfs linked into the kernel, so back to a single blob: (bbl (kernel (initramfs)))19:25
somloambro718: the "right way" would be for the gateware to provide the device tree to the BBL and above19:25
sorearunfortunately, I was trying to debug something in userspace at the time19:26
somloyou 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 side19:26
ambro718device tree won't be embedded into hardware, it can vary between kernel versions for example19:26
sorearwhy would the kernel developers do that19:27
sorearwere you here long enough to remember config string?19:27
somloambro718: not *hardware* hardware, but ROM (firmware)19:27
sorearthe 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
somloit'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 be19:28
ambro718with 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
sorearthey 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 ROM19:29
sorearwe eventually convinced them that big endian wasn't a big deal and they should use the same data structure ppc and arm were already using19:29
sorearbut they kept the "this is kernel version independent, should be used by all kernels not just Linux, and should be in ROM" parts19: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
ambro718That'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
ambro718Also big endian should die :)19:36
somloambro718: a 64bit rocket core with no FPU and no MMU, and litex wrapped around it, will consume cca. 45K CLBs on an ECP5 FPGA19:37
ambro718Not familiar with the numbers, what's your point?19:38
somloadd in the MMU (so Linux works), and it's up to 65K CLBs (requiring an 85K ECP5 :)19:38
sorearis 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
somlomy point is that optional/missing instructions is a good thing :)19:40
ambro718somlo: actually you can not emulate it, by compiling your code to link to SW fp routines19:40
ambro718It doesn't have to be via a trap.19:40
somlosorear: 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 hand19:41
somloambro718: 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 emulate19:42
somloI strongly prefer the latter, just because it simplifies everything else...19:43
sorearI mean, have you looked at Rocket ASIC floorplans?  the FPU is larger than the rest of the core combined, including the L1 cache19:43
ambro718somlo: or have the kernel do the emulation, which is more convenient for users19:43
sorearand asics are much more favorable to logic vs. memory19:43
ambro718Linux can do FP emulation for many architectures.19:43
sorearthe rocket FPU is quite silly.  it's a straightforward, "obviously correct", design with a fully combinatorial multiply-add unit19:44
somlook, so the Linux kernel can install the trap handlers in S-mode, instead of having the BBL install them in M-mode19: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
sorearbut, 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 code19:45
ambro718sorear: 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
sorearthere is no public implementation of anything close to riscv/riscv-v-spec on the Rocket base19:48
somlooh 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
Doludaveshah : Yes unaligned access are missing21:00
somlooh, 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
somloI was trying hard to outsmart myself, unnecessarily, as it turns out :D22:05
somlowell, on that note, I'm fried, but cautiously optimistic about tomorrow -- see y'all later22:06
Dolusomlo : this + set a timer, and time CSR emulation22:07
somloDolu: 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
somloanyhow, 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
ambro718What's wrong here?  If(self._interrupt_enabled and self._ring_count != 0 and self._next_ring_count == 0,22:28
ambro718TypeError: Attempted to convert Migen value to boolean22:28
ambro718How do I disable building ethernet software (libnet)?22:54
daveshahambro718: I think you need to use & not and when building logic22:55
ambro718daveshah: Yeah I figured that out22:55
*** ambro718 has quit IRC23:43

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