Hello Niteesh, thanks for the (private) remainder. This thread really stopped quite some time ago. A lot of us are quite busy right now but that shouldn't happen. If you don't get a response for some question: Please give it about a week of time and then just ping the thread.
On 05/03/2020 11:06, G. S. Niteesh wrote: > On Wed, Feb 26, 2020 at 8:39 AM Chris Johns <chr...@rtems.org > <mailto:chr...@rtems.org>> wrote: > > On 22/2/20 1:45 am, G. S. Niteesh wrote: > > Hi, > > > > This is regarding adding RPi support to the boot image generation > tool. > > > > The boot process for Raspberry Pi is very unconventional. The GPU > starts > > first, initializes RAM, other hardware, loads the bootloaders and > then starts > > the ARM CPU. > > > > The minimum files that are required to boot an RPi are > > bootcode.bin, startx.elf, fixup.dat, kernel.img, config.txt > > There are also other variants of startx.elf and fixup.dat. > > Please have a look > > > at > https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md > > for information on the variants. > > > > From what I have tried on my Rpi3 model b v1.2 the minimum files > that are > > required are start_x.elf, fixup_x.dat, bootcode.bin, kernel.img, > config.txt > > But for this to work, we must add start_x=1 to config.txt because > by default > > start.elf is loaded. > > Hello Chris, > > > I would have look at how the tool maps to RPi to know if it needs > more work :) > > > Did you take a look at it? Chris is most likely too busy with the release right now. > > In my opinion, there are two ways to do it. > The first would be to modify the U-Boot bootloader object to have a > files field > to make sure the user provides all the necessary files(fixup.dat, > startx.elf, config.txt). > So after this change the rtems-boot.ini for RPI should look something > like this > [u-boot-raspberrypi] > uses = u-boot-arm-raspberrypi > .. > .. > first_stage = %{ubootdir}/bootcode.bin > boot_device = mmc 0 > second_stage = uboot or startx > files = [config.txt, fixup.dat etc] > But also please keep in mind that if we want to support RPi4 then the > first_stage > will start4x.elf since bootcode.bin is now replaced by code in the > EEPROM in RPi4 SOC. As far as I understand that approach it more or less tells: To start a raspberry you need U-Boot. U-Boot needs the fixup.dat, startx.elf and config.txt to boot. But that sounds a bit wrong. On Raspberry U-Boot is purely optional, isn't it? So from a high-level view it would be more a - Raspberry needs fixup.dat, startx.elf and config.txt - That can start either: - an application or - an U-Boot which can then start an application (or do other things) > > Another approach will be to create the default Raspberry Pi bootloader > object. But having > support for U-Boot is important since it will allow for automatic testing. That approach sounds more correct. But I don't really know the rtems-boot-image tool. That makes it a lot harder for me to tell whether that approach works well. From that ignorant position I would say that it would be nice to have a boot-image command that can be called with or without a option (like --with-u-boot). Alternatively maybe two targets would be possible. One raspiboot-u-boot-pi1 and one raspiboot-raw-pi1. But your best bet might is to wait for Chris to get free again and answer that question. He knows the boot image tool and can tell you a lot better which concept works best. Best regards Christian > > Which one do you think is a better approach? > > Thank you. > > > > > > So, what should be the values for the first and second stages in > rtems-boot.ini > > for Rpi? > > Would this be bootcode.bin? > > > And also wouldn't it be nice if we could add a files field, which > will copy the > > specified files to the image? This would save a lot of typing in > case of RPi > > Do you have an example? > > Chris > > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
