00:21 <flyback> is it possible to use a old version of u-boot to load a 2nd newer version as a payload

00:22 <flyback> nm

00:22 <flyback> guess it doesn't make sense

00:24 <flyback> this embedded powerpc board I guess needs a old version of u-boot that has a patch for initializing the onboard promise ide controller but it doesnt support newer linux kernel image format

09:17 <wyre> hi guys, I've been checking my vendor fork for u-boot https://github.com/engicam-stable/u-boot-engicam-nxp/tree/2020.04/board/engicam but I'd like to know how is particularly handled/generated the shipped environment for u-boot

09:18 <wyre> because I'd like to patch this to ship my own custom environment

09:18 <wyre> but I can't see how is this handled and what should I patch

11:16 <wyre> hmmm, that's apparently the place! 😊 https://github.com/engicam-stable/u-boot-engicam-nxp/blob/2020.04/configs/microgea_mx6ull_sd_defconfig

13:19 <Guest97> Hello, quick newbie question but is there a way to natively dump all registers values while in uboot with a specific command? Kind of what happens with the exception handler (cf. https://stackoverflow.com/q/71109958 , for example)

13:28 <rfs613> Guest97: in general no, because the action of printing the values will involve executing code, which will modify the values in the CPU registers

13:29 <rfs613> the reason the exception handler can print them, is because upon entry to exception, all the register values have been pushed to the stack. Then the function show_regs() picks those saved values and displays them.

13:30 <rfs613> normally, if you want to inspect the registers while executing code, you either use JTAG hardware, or you run the whole thing in emulation (like qemu)

13:31 <Guest97> That's what I ended up finding while researching my issue, but I'm working on actual hardware, and don't have any JTAG access

13:31 <Guest97> What would be the best approach to dump register values at a specific time with such a setup?

13:33 <Guest97> The approach that would modify these values as least as possible

13:34 <rfs613> perhaps taking one step back, what are you trying to debug? problems in some assembly code?

13:37 <Guest97> I'm trying to characterize hardware faults on a board, but don't have much experience in embedded development

13:37 <Guest97> So I'm developing my test codes in uboot SPL (hooked right before run_main_loop() in common/board_r.c), and trying to understand the consequences of my faults

13:38 <rfs613> to try and answer your question, an instruction like "push {r0-r12, lr}" (this is for arm32) would copy the current value of those 14 registers into the stack. Now they are snapshotted, so you could call a function like show_regs() to display the values (assuming it expects the same layout, we'd need to verify that).

13:43 <Guest97> Okay, so I could simply add some inline assembly like this and use show_regs() to achieve what I'm trying to do? Even if this implies having a few values modified inbetween, I could keep in mind some "trust" percentage for these values

13:43 <Guest97> Also I'm working on a RISC-V board, but I don't think this changes much about the methodology

13:45 <rfs613> Guest97: you likely won't be able to snapshot *all* the registers exactly like a hardware exception would do. But you can probably get most of them. The trick is to get the stack layout exactly how show_regs() expects it to be... or write your own versionof show_regs that matches how you push registers on the stack.

13:45 <rfs613> it also means modifying code and re-uploading each time you want to inspect registers... quite tedious

13:46 <Guest97> So far that's my best lead, so I guess I'll try that to start with it. And thanks a lot for the clear explanation, I'll take a look at show_regs()

13:47 <rfs613> ok, also see 'struct pt_regs' which shows what the expected stack layout is. There are of course differnet version of this for each cpu/architecture.

13:49 <rfs613> for riscv seems to be defined in arch/riscv/include/asm/ptrace.h

13:49 <Guest97> Yeah I just found it, thanks again

13:50 <rfs613> out of curisity which board is it (if you are able to share this?) I would expect there to be jtag available somehow...

13:52 <Guest97> It's a LicheeRV: https://linux-sunxi.org/Sipeed_Lichee_RV . There might be some JTAG access somewhere but I haven't found it yet

13:54 <Guest97> Even the dock doesn't seem to have JTAG pins available, hence why I'm not sure it's even routed: https://bbs.aw-ol.com/assets/uploads/files/1641787337331-sipeed-lichee-rv-dock-datasheet-v1.0.pdf#page=5

13:56 <rfs613> I found the schematic for "Lichee_RV_V1.0" and this appears to show some multiplexed pins which have JTAG as one of their functions. But they appear to be using them for other functions like ethernet (RGMII) and SDCARD.

13:59 <Guest97> Wait, does that mean it would be possible to enable JTAG thanks to some configuration while building my boot image?

14:02 <Guest97> Okay I found the "PE Configure Register" in the D1 datasheet, that might allow to do such a thing, but I still have no clue if it's a viable approach

14:03 <rfs613> I'm not sure if the schematic I was looking at matches up with the board you have. Your board doesn't seem like it has wired ethernet ports.

14:04 <rfs613> but it is possible that some of those pins (page 5 of the document you linked) could be configured as JTAG.

14:04 <rfs613> even though they don't show it in the document.

14:05 <Guest97> Okay, I guess I'll try to dig a bit in this direction as well then, thanks again for the ideas

15:32 <hanetzer> ello. who should I speak to about mips64/cavium octeon boards?

16:00 <Forty-Bot> Guest97: https://linux-sunxi.org/JTAG

20:06 <beanbag-> is there a way to ram load a new version and execute it once to confirm it's good before flashing?

20:12 <marex> load <put TEXT_BASE here> ; dcache off ; icache off ; go <put TEXT_BASE here>

20:12 <marex> it is unsupported

20:23 <beanbag-> thx

20:59 <beanbag-> CANUCK