02:43 <wens> mort: support for Fibocom devices was added to qmi_wwan.c around v4.20. Maybe you should backport the commit?

02:43 <wens> mort: AFAICT, option gives you a tty to control the modem using AT commands. qmi_wwan.c gives you a network device for network access. you need both.

11:32 <Net147> if I boot RK3399 with U-Boot 2022.01 TPL, then reboot to maskrom with "mw 0xff320300 0xef08a53c; sleep 1; reset" from U-Boot, then "rkdeveloptool db rk3399_loader_v1.22.119.bin" from computer connected to RK3399 using USB-C cable, it hangs when trying to do soft reset. any ideas?

11:34 <Net147> using LPDDR4

12:53 <robmur01> Belgin[m]: http://opensource.rock-chips.com/wiki_Boot_option

13:22 <Belgin[m]> robmur01: I just realized my question wasn't clear. I am interested in where in volatile memory does the bootrom load the SPL from spi, emmc or wherever.

13:23 <Belgin[m]> But thanks for this link. It will be useful.

13:26 <robmur01> ah, indeed I missed the crucial significance of "at" :)

13:26 <Belgin[m]> Also, I realized yesterday, the bootrom only loads exactly what it needs, which is the SPL, and maybe the third stage bootloader if some option is enabled in the SPL. I was under the impression that it loads the whole SPI chip, but it probably doesn't.

13:26 <Belgin[m]> robmur01: lol

13:28 <Belgin[m]> So i would have implement the SPI protocol in my code to get the rest of the bios chip loaded

13:28 <robmur01> I'd guess at somewhere near the beginning of DRAM - it ought to be fairly simple to hack U-Boot to dump the PC and/or some symbol addresses early on (before relocation) to get a fair idea

13:30 <robmur01> yeah, if you've got other stuff which isn't inside the loader image itself I think you're on your own (at least as far as convincing U-Boot to load it for you, maybe)

13:30 <Belgin[m]> Thank you for the information!

13:31 <Belgin[m]> According to this https://github.com/trini/u-boot/blob/master/doc/README.rockchip "The boot ROM loads image to 0xff704000 which is in the internal SRAM. The SRAM

13:31 <Belgin[m]> starts at 0xff700000 and extends to 0xff718000 where we put the stack."

13:31 <Belgin[m]> i am guessing dram initialization is up to the later stage bootloaders

13:35 <robmur01> ah, I was assuming 1st-stage being the IDB loader in SRAM (which is really tight) that initialises DRAM and then loads the full-featured 2nd-stage there. As an end-user I don't see much point in counting the boot ROM. Or it's the 0th stage because as we all know numbering starts at 0 :D