05:55 <kscz> okay - I'm caught in an infinite loop of isr handling????

05:55 <kscz> but the default handler looks like it should clear the interrupt flag and return

05:55 <kscz> breakpoints do not work so this is very hard to debug

07:36 <kscz> why would just linking libliteeth cause infinite ISR handling?

07:36 <kscz> I am befuddled

07:38 <geertu> kscz: Are there any constructors in the library?

07:40 <kscz> not that I can spot?

07:41 <kscz> and the crt0.S doesn't even call global initializers so I would expect I need to make it somewhere in the code for there to be a failure due to a constructor

07:42 <kscz> I mean, this feels like something someone else using libLiteEth would have spotted already... I guess I am mostly befuddled because I don't feel like I'm pushing very hard on the frameworks and I'm running into a lot of issues

07:43 <kscz> which normally indicates I'm doing something very wrong

07:43 <kscz> but I can't for the life of me figure out what

07:43 <kscz> https://github.com/enjoy-digital/litex/issues/2110 - it looks like the primary issue I'm running into was reported in October

07:44 <kscz> are other people not seeing this issue? Is it just me?

07:44 <kscz> are other people not seeing this issue?

07:44 <kscz> ack, sorry, meant to edit but forgot this is IRC for a moment

07:59 <kscz> Maybe there is something in .bss or .data which is causing an issue when crt0.S tries to initialize it?

07:59 <kscz> looking at the map file though, that seems unlikely

08:38 <geertu> Binary too large? Overlap with the isr? Is that address of the isr pinned in an assembler file?

08:45 <flygoat> kscz: Have you checked what exception is it in ISR? Sometimes exceptions like illegal memory access is also going into ISR.

14:13 <kscz> @geertu - I don't think the binary is too large as I tend to get compiler errors when I spill over the ram or rom size. Not sure what you mean by "overlap with the ISR"? The ISR is pinned in the linker file - https://github.com/kscz/wyrm/blob/debug_bridge/software/linker.ld#L8-L22

14:15 <kscz> @flygoat I will try but the debugger is *very* slow and spits out a lot of errors while running. I need to go find a good reference on checking exceptions in riscv

14:16 <geertu> kscz: And the actual isr_vector and text.isr are still at the expected locations in the final binary?

14:22 <kscz> yes it appears so based on the map file

14:23 <kscz> do you know how to check the CSR registers from gdb?

14:31 <kscz> ahhha - okay, it's just "info register foo"

14:34 <kscz> alright, so about what I would expect - it says it's performing a misaligned load in .data initialization

14:51 <kscz> yep - no bueno:

14:51 <kscz> 66460: 0x000027c2 PROVIDE (_fdata_rom = LOADADDR (.data))

15:06 <kscz> does anyone know how to force the load address to be aligned???

15:07 <kscz> https://github.com/kscz/wyrm/blob/debug_bridge/software/linker.ld#L53

15:07 <kscz> the sram section is aligned but the "AT > main_ram" section is not

15:27 <geertu> kscz: Probably that should be LOADADDR (_fdata)

15:27 <kscz> ..........

15:27 <kscz> well that'll teach me to use someone else's linker script

15:30 <kscz> hm

15:30 <kscz> linker.ld:78: undefined section `_fdata' referenced in expression

15:31 <kscz> for the moment - I got it to work by patching the crt0.S

15:31 <kscz> and have it loading and storing bytes instead of words

15:31 <kscz> which slows down startup time, but it at least *works*

15:38 <geertu> kscz: Move the ". = ALIGN(8);" up, before .data

23:49 <kscz> @geertu I was actually surprised that didn't error out! But my linker still gave a misaligned symbol