13:32 <somlo> what kernel version, and what tool was used with these patches: https://github.com/litex-hub/linux-on-litex-vexriscv/tree/master/buildroot/board/litex_vexriscv/patches/linux

13:32 <tpb> Title: linux-on-litex-vexriscv/buildroot/board/litex_vexriscv/patches/linux at master · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com)

13:33 <somlo> I'm trying to apply them to a current kernel, and 'git am' says "Patch format detection failed"

13:33 <somlo> nevermind actual merge conflicts or anything :)

13:59 <daveshah> somlo: kernel 5.0.13 according to the buildroot config

14:00 <daveshah> I guess this is traditional patch style; whatever buildroot uses

14:08 <somlo> can it handle additional patches generated using git-format-patch? (Because I'm about to send a PR adding a patch generated that way, and if that won't work, might as well not do it :)

14:14 <somlo> https://github.com/litex-hub/linux-on-litex-vexriscv/pull/60

14:14 <tpb> Title: RFC: update liteeth driver to automatically calculate hwreg offsets by gsomlo · Pull Request #60 · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com)

14:16 <somlo> it's a hack on the liteeth driver to allow it to figure out its register offsets automatically, regardless of whether it's on a 32-bit or 64-bit kernel, and with a csr-data-width parameter passed in via DT (defaulting to 8, to keep it backward compatible)

14:16 <somlo> my only issue is that the mmio-dw-bytes (csr data width expressed in bytes) property should be in the parent node (soc) in DT, as it applies to all mmio/csr registers, not just liteeth

14:17 <somlo> haven't figured out yet how to do *that* cleanly, so any comments or hints that could shortcut my bumbling around would be much appreciated! :)

15:09 <somlo> hmm, might be as simple as of_property_read_u32(pdev->dev.of_node->parent, "mmio-dw-bytes", &mmio_dw_bytes);

15:10 <somlo> i.e. just query the parent of the "mac" DT node... I'll give it a try, then respin the patch if that works :)

17:10 <scanakci> I am a little bit confused about UART_INTERRUPT macro. I would like to use UART_POLLING (sounds easier) than UART_INTERRUPT. I changed libbase/uart.c and defined the UART_POLLING. When I run litex_sim, it gives me compilation error since UART_INTERRUPT is not defined in isr.c. If I do use uart.c as it is, it gives the same undefined UART_INTERRUPT error in uart.c.

17:15 <scanakci> I run the rocket in standard mode to see where UART_INTERRUPT is defined. Apparently, it is in the generated folder in soc.h. When I check the same file in the generated folder for Blackparrot simulation, I do not see UART_INTERRUPT macro. What is the proper way to control this Macro?

17:35 <somlo> scanakci: UART_INTERRUPT is just the interrupt pin number that's going to let your CPU know the UART needs some attention

17:36 <somlo> from there, it's just used by the software to figure out which handler to invoke, from the isr() routine in litex/soc/software/bios/isr.c

17:36 <somlo> I haven't thought about how I'd do polling with the UART, just wiring things up and adding the appropriate interrupt handler felt like the easier thing to do

17:37 <somlo> now granted, rocket comes complete with a PLIC, no idea how Blackparrot handles interrupts...

17:38 <somlo> depending on that, maybe looking at one of the 32bit cpu models (e.g. vexriscv) for inspiration on that might make more sense...

17:39 <somlo> mithro: thanks for the patchwork link, looks like for now they're trying to hardcode 8-bit register slices (a.k.a. LITEX_SUBREG_SIZE), so I added a comment about that :)

19:17 <somlo> kgugala: ping

19:20 <somlo> kgugala: I'm interested in finding a generic, csr-data-width agnostic solution for LiteX Linux-kernel MMIO support (re: https://lore.kernel.org/patchwork/patch/1143354/)

19:20 <tpb> Title: [v2,2/4] litex: add common LiteX header - Patchwork (at lore.kernel.org)

19:20 <somlo> happy to brainstorm here or in the lkml thread :)

22:58 <scanakci> somlo: Thank you so much. As a first step, I want to run BIOS so I do not think I need to use UART anyways until we want to load linux image to DRAM (please correct me if it is wrong). If I can come to that point, I will utilize interrupts as you suggested. Does executing BIOS instructions from ROM cause any interrupts? I looked at BlackParrot and need to spend more time to handle interrupts for couple of reasons.

22:59 <scanakci> For now, if there is a chance that I can run BIOS by only using ROM (w/o any other memory) and without interrupt support; I would like to do that

23:37 <somlo> scanakci: it's been almost a year, but I remember being able to generate *output* from the BIOS, but I had to sort out interrupts before I could accept input from the keyboard. But as I said, it's getting hard to remember :)

23:41 <scanakci> makes sense. typing some commands in BIOS screen will require interrupt support but printing "hello from blackparrot processor" with Litex logo should not hopefully.