| *** tpb has joined #timvideos | 00:00 | |
| *** Kripton has quit IRC | 00:02 | |
| *** Kripton has joined #timvideos | 00:06 | |
| *** sb0 has quit IRC | 02:38 | |
| cr1901_modern | mithro: Did a test on icebreaker... still can duplicate the crash, but... it's not actually crashing. I can reset the CPU using a push button and it goes back to the reset vector just fine. | 03:13 |
|---|---|---|
| cr1901_modern | hmmm | 03:14 |
| *** thaytan has quit IRC | 03:23 | |
| *** thaytan has joined #timvideos | 03:29 | |
| *** ChanServ sets mode: +v thaytan | 03:29 | |
| *** thaytan has quit IRC | 03:49 | |
| cr1901_modern | mithro: I found the culprit of the BIOS crash on picorv32 | 05:06 |
| cr1901_modern | Trying micropython right now w/ my hack | 05:07 |
| *** thaytan has joined #timvideos | 05:08 | |
| *** ChanServ sets mode: +v thaytan | 05:08 | |
| cr1901_modern | micropython boots beyond the prompt with my hack, but as soon as I try to type anything it crashes. | 05:10 |
| cr1901_modern | mithro: Culprit is these two lines: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/libbase/console.c#L26-L27 Apparently write_hook isn't set properly on icebreaker/ice40 boards | 05:11 |
| tpb | Title: litex/console.c at master · enjoy-digital/litex · GitHub (at github.com) | 05:11 |
| cr1901_modern | so the BIOS goes and jumps to write_hook and locks up | 05:11 |
| *** sb0 has joined #timvideos | 05:12 | |
| *** thaytan has quit IRC | 05:13 | |
| cr1901_modern | mithro: There's also another problem... picorv32's irq and reset address are hardcoded at synthesis time; micropython links in its own copy of crt0, but when an interrupt occurs, the old version of the crt0 (that was linked into the BIOS) is run instead | 05:22 |
| cr1901_modern | I can already promise you by visual inspection that the addresses used by the micropython crt0 != the ones used by the BIOS crt0 | 05:22 |
| cr1901_modern | picorv32 will need to be modified to permit a user to move the irq vector. | 05:23 |
| cr1901_modern | the data*/global addresses. | 05:23 |
| cr1901_modern | Actually, I think I might know an alternative... | 05:37 |
| *** thaytan has joined #timvideos | 05:45 | |
| *** ChanServ sets mode: +v thaytan | 05:45 | |
| *** thaytan has quit IRC | 06:00 | |
| *** rohitksingh has joined #timvideos | 06:01 | |
| *** thaytan has joined #timvideos | 06:06 | |
| *** thaytan has quit IRC | 06:10 | |
| *** thaytan has joined #timvideos | 06:11 | |
| *** ChanServ sets mode: +v thaytan | 06:11 | |
| cr1901_modern | BIOS boot is fixed; .bss wasn't being zero'd out in the startup code. When using SPRAM, this means that the CPU saw garbage | 06:11 |
| *** thaytan has quit IRC | 06:19 | |
| cr1901_modern | cc: daveshah, in case you're interested when you wake up ^^. I figured out _part_ of the problem | 06:21 |
| cr1901_modern | perhaps the whole problem... | 06:21 |
| *** thaytan has joined #timvideos | 06:25 | |
| *** ChanServ sets mode: +v thaytan | 06:25 | |
| mithro | CarlFK: https://smile.amazon.com/gp/product/B06W5WB26H/ref=smi_www_rco2_go_smi_9689862631?_encoding=UTF8&ie=UTF8&pldnSite=1&psc=1 <-- Have you seen that? | 06:40 |
| mithro | CarlFK: Did they come down in price recently? It's only $60 USD!? | 06:41 |
| cr1901_modern | mithro: To boot micropython on picorv32 requires me to modify picorv32 itself. All other bugs AFAICT are fixed (BIOS boots on icebreaker). | 07:08 |
| mithro | cr1901_modern: Why not use a jmp proxy? | 07:18 |
| cr1901_modern | Because what happens if the proxy is at a different address in the micropython firmware versus the BIOS | 07:19 |
| cr1901_modern | ? | 07:19 |
| cr1901_modern | (Meaning I already tried that) | 07:19 |
| cr1901_modern | mithro: This is what I got so fatr | 07:20 |
| cr1901_modern | far* even | 07:20 |
| cr1901_modern | http://ix.io/1qBf | 07:20 |
| cr1901_modern | The IRQ vector is hardcoded at synthesis time, right? Meaning the BIOS version will always be the one called. | 07:20 |
| cr1901_modern | How do I modify the BIOS' copy of _irq_entry from the startup code of the micropython firmware? | 07:21 |
| mithro | cr1901_modern: you make the IRQ vector be in SRAM? When you start, the first thing you so is copy your IRQ vector to the correct location in SRAM? | 07:34 |
| cr1901_modern | mithro: How do I get the address of the BIOS' IRQ vector from the micropython crt0? | 07:39 |
| mithro | Why do you need that? | 07:40 |
| cr1901_modern | Because picorv32's IRQ vector is hardcoded | 07:40 |
| cr1901_modern | at synthesis time | 07:40 |
| cr1901_modern | in other words, even when running micropython, when an IRQ occurs, it jumps _back_ to the BIOS' copy of the crt0 | 07:41 |
| mithro | cr1901_modern: Put the IRQ vector in SRAM, the crt0 of the bios copies the BIOS IRQ vector into SRAM and when the crt0 of micropython copies the micropython IRQ vector into SRAM | 07:45 |
| cr1901_modern | Let's call the address of the IRQ vector _irq_entry | 07:47 |
| cr1901_modern | How do I know that the C compiler is going to put _irq_entry in both the BIOS and micropython _at the same exact SRAM address_? | 07:47 |
| cr1901_modern | (spoiler alert: It didn't :(...) | 07:47 |
| cr1901_modern | If micropython and the BIOS' _irq_entry don't share the same address, then micropython's crt0 will _clear_ the SRAM (as part of BSS clear), and then store to _irq_entry at a different location than the BIOS did | 07:49 |
| cr1901_modern | http://ix.io/1qBi Micropython | 07:50 |
| cr1901_modern | http://ix.io/1qBj BIOS | 07:50 |
| mithro | The IRQ vector address is called _irq_entry which is in SRAM | 07:59 |
| cr1901_modern | They are different in Micropython and BIOS | 07:59 |
| mithro | The BIOS does "(*_irq_entry) = jump to bios_irq_entry;" | 08:00 |
| cr1901_modern | in order for a trampoline to work, they both need to be accessing the same address | 08:00 |
| mithro | The micropython does "(*_irq_entry) = jump to micropython_irq_entry;" | 08:00 |
| cr1901_modern | 1000095c <_irq_entry> | 08:00 |
| mithro | There is only one _irq_entry value which is hard coded to X as you mentioned | 08:01 |
| mithro | X has to be in user modifiable region | 08:01 |
| mithro | You replace the _irq_entry with a jump instruction to your own irq_entry table | 08:02 |
| cr1901_modern | 1. This is downright horrifying | 08:03 |
| cr1901_modern | 2. How do I do this from C? | 08:03 |
| cr1901_modern | well okay ignore #2 | 08:03 |
| cr1901_modern | err, I don't really have all that fine control over where the _irq_vector actually ends up | 08:04 |
| mithro | It's pretty normal to have the original _irq_vector just be a second jump to a user modifiable location | 08:06 |
| cr1901_modern | right, but this means a whole new linker script just for picorv32 | 08:08 |
| mithro | Isn't the linker script custom to each CPU anyway? | 08:12 |
| cr1901_modern | nope! | 08:12 |
| cr1901_modern | mithro: In any case, I'm talking to clifford right now. If he accepts a PR to increase the number of QREGs, all my problems go away | 08:12 |
| cr1901_modern | I can just squirrel away the IRQ pointer in one of the new QREGs | 08:13 |
| cr1901_modern | actually I think I figured it out | 08:17 |
| *** rohitksingh has quit IRC | 08:31 | |
| *** rohitksingh has joined #timvideos | 08:32 | |
| cr1901_modern | mithro: It boots | 08:54 |
| cr1901_modern | micropython on picorv32 on icebreaker boots | 08:54 |
| daveshah | Yay! | 08:54 |
| cr1901_modern | mithro: https://github.com/fupy/micropython/pull/54 | 09:20 |
| tpb | Title: RISCV32 support by cr1901 · Pull Request #54 · fupy/micropython · GitHub (at github.com) | 09:20 |
| cr1901_modern | https://github.com/enjoy-digital/litex/pull/123 | 09:20 |
| tpb | Title: PicoRV32 Enhancements by cr1901 · Pull Request #123 · enjoy-digital/litex · GitHub (at github.com) | 09:20 |
| cr1901_modern | After these are merged, I'll make a PR for litex-buildenv | 09:21 |
| cr1901_modern | Well actually... LEDs aren;t working... hrm | 09:23 |
| _florent_ | cr1901_modern: it seems fine, happy to merge if it's working | 09:48 |
| cr1901_modern | _florent_: Well, a trace of SPI flash activity isn't giving me many answers... hrm | 09:49 |
| cr1901_modern | In any case, we get to the prompt and the prompt works besides the LEDs. That's an important milestone. | 09:49 |
| _florent_ | cr1901_modern: so micropython boots but you are not able to toggle a led with it? | 09:49 |
| cr1901_modern | _florent_: Correct | 09:49 |
| cr1901_modern | There's nothing indicating that the CPU jumped into the weeds | 09:50 |
| _florent_ | cr1901_modern: ok, i can merge you PR is you want then, | 09:50 |
| _florent_ | cr1901_modern: you'll create another one if the led issue is related to that | 09:50 |
| cr1901_modern | _florent_: Yes, that works for me. | 09:51 |
| daveshah | Could the LED issue be another endian one? | 09:51 |
| daveshah | To do with the GPIO regs or something? | 09:51 |
| cr1901_modern | LED regs work fine outside of micropython | 09:53 |
| daveshah | Oh, I see | 09:54 |
| cr1901_modern | Of course it's also 256kb of micropython code. I highly doubt I'm gonna figure out anything substantial from staring at that. | 09:55 |
| daveshah | Seems like something best debugged with a few printfs | 09:56 |
| cr1901_modern | one notable thing is that the SPI flash started fetching the next insn immediately after the last one is done, instead of waiting for picorv32 to finish | 09:57 |
| cr1901_modern | In any case, at present, the bug doesn't make sense for me. I think I've gotten far enough tonight to be satisfied. | 09:58 |
| daveshah | Does an import math and math.sin(1) work? | 09:58 |
| cr1901_modern | Lemme reboot and check | 09:59 |
| daveshah | If that's fine, then the LED issue is most likely somewhere in the Python driver stuff | 09:59 |
| cr1901_modern | math.sin(1) indeed does work | 09:59 |
| daveshah | Sounds good | 10:00 |
| daveshah | I've never had a broken Python design succeed at that and then fail later on | 10:00 |
| cr1901_modern | picorv32 is fetching the next insn while executing the current one, correct? | 10:01 |
| daveshah | I think so, yes | 10:01 |
| daveshah | Pretty sure I've noticed that before | 10:01 |
| cr1901_modern | The insn before the last one was: lw a5,28(s2) | 10:02 |
| cr1901_modern | possible it went into the weeds | 10:02 |
| daveshah | So did it crash, or just not work? | 10:02 |
| cr1901_modern | crash | 10:03 |
| cr1901_modern | IME, if we access an invalid memory location, the CPU locks | 10:03 |
| daveshah | Yep | 10:03 |
| daveshah | there's no timeout or anything | 10:03 |
| cr1901_modern | Well, it's a problem for another day :P. | 10:08 |
| * cr1901_modern zzz | 10:08 | |
| daveshah | _florent_: ping? | 10:26 |
| *** sb0 has quit IRC | 10:41 | |
| *** sb0 has joined #timvideos | 13:09 | |
| _florent_ | daveshah: i'm here now | 13:54 |
| daveshah | _florent_: I'm looking at the ECP5 PLLs, and I'm wondering how you would set attribute values on instances in migen | 13:56 |
| daveshah | or litex | 13:56 |
| daveshah | I would like to generate something like this | 13:56 |
| daveshah | https://www.irccloud.com/pastebin/DSMVfGMj/ | 13:56 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 13:56 |
| _florent_ | https://hastebin.com/aqurilogey.py | 14:04 |
| daveshah | _florent_: thanks, I missed the tuple requirement | 14:04 |
| daveshah | I'll test this this evening when I'm home | 14:05 |
| _florent_ | cool, thanks | 14:05 |
| *** mauz555 has joined #timvideos | 14:41 | |
| *** mauz555 has quit IRC | 16:13 | |
| *** TimGremalm has quit IRC | 16:59 | |
| *** mauz555 has joined #timvideos | 17:03 | |
| *** TimGremalm has joined #timvideos | 17:10 | |
| *** rohitksingh has quit IRC | 17:30 | |
| *** rohitksingh has joined #timvideos | 17:42 | |
| *** rohitksingh has quit IRC | 18:10 | |
| CarlFK[m] | tac-tics ridk5 what? | 19:17 |
| *** mauz555 has quit IRC | 19:23 | |
| daveshah | _florent_: PLL is working, but still getting a low percentage of failures (Memtest data failed: 17/524288 errors, Memtest addr failed: 18/8192 errors) with memtest | 19:45 |
| daveshah | I have a few ideas which I will test tomorrow | 19:45 |
| _florent_ | daveshah: great for the PLL. Have you tried with different phase shifts? | 20:12 |
| daveshah | _florent_: not yet | 20:12 |
| daveshah | I realised the IO were is slow slew mode | 20:12 |
| daveshah | I'm trying to fix that first | 20:12 |
| _florent_ | daveshah: ah ok | 20:12 |
| daveshah | at the moment ps_clk which is also output to the sdram has a phase of 270 degress | 20:12 |
| daveshah | _florent_: seeing more errors with fast slew | 20:19 |
| daveshah | this is very strange | 20:19 |
| daveshah | Memtest data failed: 86/524288 errors | 20:20 |
| daveshah | Memtest addr failed: 78/8192 errors | 20:20 |
| *** fischerm has quit IRC | 21:11 | |
| *** springermac has quit IRC | 21:24 | |
| *** fischerm has joined #timvideos | 22:12 | |
| *** TimGremalm has quit IRC | 23:30 | |
| *** TimGremalm has joined #timvideos | 23:31 | |
| *** thaytan has quit IRC | 23:40 | |
| *** thaytan has joined #timvideos | 23:40 | |
| *** ChanServ sets mode: +v thaytan | 23:40 | |
| *** thaytan has quit IRC | 23:44 | |
| *** thaytan has joined #timvideos | 23:46 | |
| *** ChanServ sets mode: +v thaytan | 23:46 | |
| *** thaytan has quit IRC | 23:47 | |
| *** thaytan has joined #timvideos | 23:47 | |
| *** ChanServ sets mode: +v thaytan | 23:47 | |
| *** thaytan has quit IRC | 23:48 | |
| *** thaytan has joined #timvideos | 23:49 | |
| *** ChanServ sets mode: +v thaytan | 23:49 | |
| *** Kripton has quit IRC | 23:50 | |
| *** thaytan has quit IRC | 23:50 | |
| *** Kripton has joined #timvideos | 23:51 | |
| *** thaytan has joined #timvideos | 23:51 | |
| *** ChanServ sets mode: +v thaytan | 23:51 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!