Friday, 2016-12-23

*** tpb has joined #timvideos00:00
*** CarlFK has quit IRC00:36
*** CarlFK has joined #timvideos00:39
*** ChanServ sets mode: +v CarlFK00:39
*** rohitksingh_work has joined #timvideos04:01
*** rohitksingh_work has quit IRC04:31
*** rohitksingh_work has joined #timvideos04:32
*** andi-m has quit IRC04:41
*** andi-m has joined #timvideos04:43
*** rohitksingh_work has quit IRC09:24
*** cr1901_modern1 is now known as cr1901_modern09:44
mithro_florent_: Mind if I just merge ?10:23
tpbTitle: Raise AttributeError. by mithro · Pull Request #13 · enjoy-digital/litex · GitHub (at
*** sb0 has joined #timvideos10:47
mithro_florent_: working on getting Bertl from apertus up and running with opsis-soc/litex11:02
*** sb0 has quit IRC13:47
cr1901_modernmithro: This warning doesn't actually occur for me in mimasv2_base_lm32:
mithroI haven't checked recently....18:01
cr1901_modernOkay, just was letting you know :)18:02
cr1901_modernmithro: You may have known this already, but the CPU actually *is* executing instructions. I suspect what is happening is that the BIOS is crashing. This is starting to mirror a bug I had when trying to get MiSoC to boot on a Spartan 3 200A with a modified LM32 (no D-cache)19:28
cr1901_moderni.e. your SPI flash impl works, but the CPU doesn't like something else19:29
cr1901_modernmithro: Confirmed it's crashing in the first printf()20:12
_florent_mithro: sorry wasn't around, good for Bertl playing with opsis-soc/litex :)20:26
cr1901_modernNeed to check where the stack pointer is being initialized to20:27
cr1901_modernokay it's initialied to the end of SRAM, that's correct. Now why would the CPU be crashing...20:30
_florent_cr1901_modern: you are debugging the bios executed from the SPI flash?20:36
cr1901_modern_florent_: Correct20:53
cr1901_modernThe BIOS crashes in printf, before any characters are written...20:54
cr1901_modernI know this b/c I set a write to the Mimas LEDs on return, but they never light up20:54
cr1901_modern*before* the printf, however, the LED write is honored20:54
cr1901_modernI have a few things left to try...20:56
cr1901_modernstack usage looks fine20:56
mithrocr1901_modern: I think I was seeing an effect where reading from the same address (on the SPI flash) multiple times was getting different data.21:25
cr1901_modernmithro: This was from the scope target? I'll check.21:42
mithrocr1901_modern: yeah, but I'm very uncertain21:44
cr1901_modernObviously at least one of printf's children is going to have iteration. It's plausible that printf is the first place that the ROM depends on, well, the data at a specific address not changing when read :P21:44
cr1901_modernmithro: At the very least, I can confirm that the CPU is running, even if it's crashing21:44
mithroYeah, add some loops :-P21:44
mithroSingle step the CPU?21:45
mithroIt would be good to have the JTAG<->gdb bridge stuff working for debugging things like this21:46
cr1901_modernmithro: As a last resort, I've thought about that. LM32 has JTAG support for spartan 621:46
cr1901_modernAnother option would be to clock gate the CPU via a litescope core21:47
mithroOr a button21:48
mithroPress button, go forward one cycle :-P21:48
mithroMight be too much button pressing21:48
cr1901_modernYea, I'm gonna be there for an hour T_T21:48
mithroIt would be good to have a gdb bridge which works with the wish bone bridge21:49
mithroGdb is a much nicer interface for debugging :-)21:50
mithroBe back later, maybe21:51
cr1901_modernmithro: I'd have to think hard about how a gdb/wishbone bridge would work21:51
cr1901_modernB/c I'd somehow need to either gate the clock or get access to the JTAG interface21:52
cr1901_modernlike I said tho. Not all options exhausted yet21:52
mithroTake a look at the adv debug JTAG task21:53
mithroNot necessarily right now21:53
*** SamSagaZ has joined #timvideos23:15

Generated by 2.13.1 by Marius Gedminas - find it at!