01:21 <FergusL> re: rg351 u-boot on sdcard Okay, that's interesting: unless I'm too tired to read my terminal, I just got to that point: I used the building and image assembly script provided by odroid (and used in other custom firmwares) *except* for u-boot.bin which is the one I built from v2022.04 mainline instead of from odroid's tree (or any fork) and boom,

01:21 <FergusL> booted my rg351m, no CS to 3v3 hack, it went straight to the u-boot console, and `version` confirmed it's indeed 2022.04

01:27 <FergusL> https://github.com/hardkernel/u-boot/blob/odroidgoA-v2017.09/make.sh#L849 basically I just commented this line and changed a rkbin command for it to use the one I used before (just to factor out as much as possible of their workflow, to narrow down on the cause of an booting to the sdcard's u-boot without the spi chip hack)

08:14 <Kwiboo> FergusL: the spi nor in your device probably contains rk miniloader (and not u-boot SPL) that will look for uboot.img and trust.img created by rk imageloader/trust_merger tool, see boot flow 1 at https://opensource.rock-chips.com/wiki_Boot_option

08:16 <Kwiboo> you can probably run something like "../rkbin/tools/loaderimage --pack --uboot u-boot-dtb.bin uboot.img <CONFIG_TEXT_BASE>" to generate a uboot.img and dd that to secor 0x4000 (16384) of sd-card

08:18 <Kwiboo> possible that you also need to build and dd a trust.img at 0x8000 using rkbin

08:21 <Kwiboo> the rockchip-u-boot.bin will contain u-boot.itb at 0x4000, seen in boot flow 2, so miniloader in spi nor will not understand that format and insted loads uboot.img from spi nor instead of from your sd-card

08:23 <Kwiboo> should be 0x6000 (24576) and not 0x8000 for trust.img

08:26 <Kwiboo> running "tools/trust_merger --ignore-bl32 RKTRUST/RK3326TRUST.ini" in rkbin repo should generate a trust.img without bl32/optee

10:14 <FergusL> Kwiboo thanks! Ill try that right away. It looks like I'm getting closer to success

12:01 <FergusL> before going ahead with your suggestion I did a little bit of grepping on the rk binaries using the strings I see in the early stage debut (using uart speed of 1500000) to find out, and confirm, where they come from exactly

12:01 <FergusL> https://dpaste.com/EECYJC23H

12:15 <FergusL> the only match I get grepping the date in the first message is in a file called "rk3326_header_miniloader_spiboot.img" , in the original hardkernel uboot tree for OGA

12:16 <FergusL> that would seem to confirm that it's indeed miniloader in the spi flash

13:37 <FergusL> Kwiboo awesome! that was it. Just had to match the bl31 version with that in the SPI flash, which makes sense

13:38 <FergusL> and for some reason the official rkbin repo only has history for a few versions

13:39 <FergusL> so grabbed rk3326_bl31_v1.14.elf, modified the RKTRUST ini file to use it instead, then trust_merger as you typed it, dd'ed and voila

13:43 <FergusL> macromorgan fyi, the last little bits of informations above got me to get the rg351m to boot sdcard uboot just fine. Since it's clearly not specific to my device, it should work the same on the oga

13:48 <FergusL> finally, as far as contributing is concerned: even though u-boot hacking and gettings one's feet wet with that is no easy thing, my humble suggestion would be to include some infos around here https://github.com/u-boot/u-boot/blob/master/doc/board/rockchip/rockchip.rst#2-package-the-image-with-rockchip-miniloader and I'm willing to do that

14:11 <macromorgan> I'll be brutally honest, I'm not sure why you'd use the rockchip miniloader since mainline everything works. The one possible exception would be if you are trying to use Optee.

14:13 <macromorgan> even then it's possible to get Optee to work on mainline, I just haven't figured out the right incantation to do so yet...

14:14 <macromorgan> sorry, missed the part above about the miniloader on your SPI chip and whatnot

14:14 <macromorgan> either way, you can also flash mainline U-Boot to the SPI chip, though it might clash with the custom firmware that's using the older U-Boot

14:15 <macromorgan> I tend to forget that not everyone develops on these devices, some people actually want to play games :-p

14:22 <FergusL> haha yeah, I agree but I find it beneficial, if not important, to document a way to use mainline as much as possible and not have to touch any of the hardware. Arguably though, resorting to the rk tools and the binaries in their repo, (and worst even, having to dig old .bin not officially published anymore) is not really mainline anymore... but

14:22 <FergusL> hey, that's cool

14:48 <FergusL> there https://github.com/Simon-L/u-boot/commit/041089ea616430cd0999d877535d999316902005

14:50 <FergusL> Kwiboo how does it sound to you that there is indeed a need to match compatible versions (which aren't documented afaik) for trust_merger?

14:50 <FergusL> I'm talking about the versions of miniloader and bl31 binaries

15:16 <marex> macromorgan: you mean to use it for Game Console Cornucopia and co. ?

16:24 <Tartarus> marex: Hummm, I _think_ I have a HW now fails with your series. Network test failed twice now. Starting a just that board sanity check and then bisect

16:37 <Tartarus> marex: Yeah, configs/j721e_evm_a72_defconfig fails now with your series

16:38 <Tartarus> k3-navss-ringacc ringacc@2b800000: Ring Accelerator probed rings:286, gp-rings[96,20] sci-dev-i

16:38 <Tartarus> am65_cpsw_nuss_port ethernet@46000000port@1: K3 CPSW: rflow_id_base: 2

16:38 <Tartarus> d:235

16:38 <Tartarus> link up on port 1, speed 1000, full duplex

16:38 <Tartarus> k3-navss-ringacc ringacc@2b800000: dma-ring-reset-quirk: disabled

16:38 <Tartarus> => => dhcp

16:38 <Tartarus> ethernet@46000000port@1 Waiting for PHY auto negotiation to complete....... done

16:38 <Tartarus> BOOTP broadcast 1

16:38 <Tartarus> ... repeats until out of broadcast attempts, fails

16:38 <Tartarus> bisect run going now

17:09 <Tartarus> marex: Ah, well, bisect _almost_ done and I think this falls in to the hole of things NishanthMenon is working on getting un-stuck, device trees in U-Boot out of sync with Linux

17:10 <Tartarus> NishanthMenon: Assuming I'm right here, I'm just going to disable ethernet on j721e_evm now, and it can get re-enabled when you're able to get the device trees re-synced with Linux, yes?

17:10 <Tartarus> NishanthMenon: Or should I leave it enabled and build but not functions, and just tell my setup to skip network tests?

17:13 <Tartarus> marex, NishanthMenon: Yup, "net: phy: Synchronize PHY interface modes with Linux" breaks network on j721e as I bet the u-boot dts has the wrong PHY mode/info somewhere here and was fixed in Linux

17:38 <NishanthMenon> Tartarus: yes please.

17:39 <Tartarus> OK, updated my scripts to just skip network tests

17:39 <NishanthMenon> Tartarus: thanks

18:39 <marex> Tartarus: errrr, well, what should I do here ?

18:39 <marex> Tartarus: wait for NishanthMenon with a fix or drop a patch ?

19:15 <Tartarus> marex: You're good, applied & pushed

19:38 <sjg1_> Tartarus: In the bootstd series the statement at the end is wrong. It also affect boards which currently have no boot command. I suppose you know that but thought I should mention it. I can redo that patch

19:38 <Tartarus> sjg1_: Well, lemme fire off this other email I just finished