MobileRead Forums - View Single Post

geekmaster · 09-26-2012, 08:49 AM

My custom u-boot images for Select Boot initialize the DRAM using the newer K5 u-boot code, which also supports the K4 (and other models). The K4 u-boot was stripped down, and did not have K5 support, so I did not use it.

Any app you upload would need to borrow the DRAM init code from the u-boot code in the amazon GPL. I recommend using the K5 u-boot code.

There are actually two u-boots, the one used by Select Boot is the small one (not bist, no fastboot)) that does not use DRAM (but does initialize it for later use AFTER determining what init method to use after examining the idme SERIAL and PCBSN. Then it loads the larger u-boot bist from mmc into DRAM, so that fastboot can work, or the linux kernel can be loaded from mmc. So it is multi-stage (u-boot, then u-boot bist, then linux kernel).

Any app that runs directly in DRAM would also need a small "bootstrap" (a very stripped down u-boot) to first load in internal SoC RAM, then init DRAM, then load the larger DRAM part of the app. You can see that u-boot also uses some self-relocating code, so it can start in internal RAM and move to DRAM after it is initialized.

So, "bare hardware" native apps designed to run from USB Downloader mode need to init the hardware (and DRAM) themselves, in stages, before they can use it.

At least that is my understanding of how this works when I was making the custom u-boot changes...

EDIT: I see that yifanlu did exactly that. His code contains the "DRAM init" portion of u-boot. All "USB Downloader mode" apps need to do this too, as part of a multi-stage boot sequence, if they need to use DRAM. Tiny apps that fit in SoC RAM do not need DRAM, but that is very constrained. Perhaps a tiny remote debugger?

09-26-2012, 08:49 AM	#238
geekmaster Carpe diem, c'est la vie. Posts: 6,433 Karma: 10773670 Join Date: Nov 2011 Location: Multiverse 6627A Device: K1 to PW3	My custom u-boot images for Select Boot initialize the DRAM using the newer K5 u-boot code, which also supports the K4 (and other models). The K4 u-boot was stripped down, and did not have K5 support, so I did not use it. Any app you upload would need to borrow the DRAM init code from the u-boot code in the amazon GPL. I recommend using the K5 u-boot code. There are actually two u-boots, the one used by Select Boot is the small one (not bist, no fastboot)) that does not use DRAM (but does initialize it for later use AFTER determining what init method to use after examining the idme SERIAL and PCBSN. Then it loads the larger u-boot bist from mmc into DRAM, so that fastboot can work, or the linux kernel can be loaded from mmc. So it is multi-stage (u-boot, then u-boot bist, then linux kernel). Any app that runs directly in DRAM would also need a small "bootstrap" (a very stripped down u-boot) to first load in internal SoC RAM, then init DRAM, then load the larger DRAM part of the app. You can see that u-boot also uses some self-relocating code, so it can start in internal RAM and move to DRAM after it is initialized. So, "bare hardware" native apps designed to run from USB Downloader mode need to init the hardware (and DRAM) themselves, in stages, before they can use it. At least that is my understanding of how this works when I was making the custom u-boot changes... EDIT: I see that yifanlu did exactly that. His code contains the "DRAM init" portion of u-boot. All "USB Downloader mode" apps need to do this too, as part of a multi-stage boot sequence, if they need to use DRAM. Tiny apps that fit in SoC RAM do not need DRAM, but that is very constrained. Perhaps a tiny remote debugger? Last edited by geekmaster; 05-29-2016 at 06:56 PM.