https://linux-sunxi.org/api.php?action=feedcontributions&user=Hmk&feedformat=atomlinux-sunxi.org - User contributions [en]2024-03-28T09:31:07ZUser contributionsMediaWiki 1.35.8https://linux-sunxi.org/index.php?title=User_talk:Hmk&diff=22578User talk:Hmk2019-07-11T16:33:26Z<p>Hmk: hay</p>
<hr />
<div>What S3 device do you have ? Can you make wiki page for it?<br />
:It's a custom board, not available on the market.</div>Hmkhttps://linux-sunxi.org/index.php?title=Boot_Process&diff=22576Boot Process2019-07-11T09:12:45Z<p>Hmk: explain how to determine boot source</p>
<hr />
<div>Our SoCs have a very specific boot process. First it executes [[BROM | a tiny on chip rom (BROM)]] which then checks the buttons for [[FEL]] mode and then starts checking the various storage options for a valid boot signature at the right location.<br />
<br />
Generally, the BROM first check [[Bootable_SD_card | SD-card]] boot availability, then in second, [[NAND]] one. The BROM will try to load the [[U-Boot|SPL]] from U-Boot in each of these devices, which in turn loads the [http://en.wikipedia.org/wiki/Kernel_(operating_system) kernel].<br />
<br />
= NAND and SD-card =<br />
There is no real difference between NAND and an SD-card apart from the fact that directly attached flash use the Sunxi NAND controller directly while SD-Cards come with a standard interface and an embedded controller. The sunxi nand controller is harder to implement than the sunxi sd-card controller, and the sample code provided by allwinner is rather large (and shared between [[U-boot]] and the kernel).<br />
<br />
* "[[Bootable SD card]]" article contains more informations about SD card boot process and explains how to make a bootable SD card.<br />
* "[[NAND]]" article contains more informations about NAND boot process<br />
* "[[Installing to NAND]]" article contains informations to make a bootable NAND.<br />
<br />
= Other =<br />
That's also possible to boot system on other devices (SATA, USB, network using TFTP/NFS,...) but [[U-boot]] standing on NAND or SD card is needed as first boot step.<br />
<br />
= Determining boot source =<br />
On boards that have a choice of different boot media, it is sometimes useful to determine which device the bootloader was started from. In U-Boot, this can be done by inspecting the byte at address 0x28 (tested on S3):<br />
<br />
=> md.b 0x28 1<br />
00000028: 03<br />
<br />
In this case, the value 03 indicates that we booted from SPI NOR. The byte reads 0 when booting from SD card.<br />
<br />
== Network ==<br />
The kernel can be loaded using TFTP, that is supported by U-boot and system can be booted using NFS. In network boot process, each of this choice are not mandatory for the other one. <br />
* "[[How_to_boot_the_A10_or_A20_over_the_network]]" explains how to configure U-boot for TFTP boot and NFS for system network boot process. <br />
<br />
== SATA ==<br />
[[A10]] and [[A20]] SoCs, support [[SATA]] controler. U-boot also support SATA boot process. That's so possible to boot on SATA device (hard disc drive, solid state device, ...).<br />
<br />
In this case, [[initial Ramdisk]] is needed.<br />
<br />
* [[:Category:Devices with SATA port|Category:Devices with SATA port]] contains list of devices with SATA port.<br />
<br />
== USB ==<br />
Most devices with Allwinner SoC have USB ports. U-boot also support USB Boot but U-boot needs to be built specifically for booting over USB<br />
<br />
* [[FEL/USBBoot]] explains how to prepare U-boot for USB boot.<br />
<br />
= A10 Boot overview =<br />
While the Allwinner series of SoC's are quite open, there is an unmodifiable ROM called [[BROM]] or Boot ROM that is in charge of booting the SoC.<br />
The BROM will try to load the [[U-Boot|SPL]] from U-Boot, which in turn loads the kernel.<br />
<br />
It should be noted, that if using Allwinner bootloaders (especially true when booting from nand storage), the order is slightly different.<br />
[[BROM]] loads boot0 as its SPL and that chainloads boot1. These all reside in unaccessable (not easily anyway) nand flash, before the partition table. boot1 loads [[boot.axf]] from the first fat partition which in turn chainloads (in our case) u-boot and then the kernel. It is in theory possible to directly boot the kernel, or some other OS. Also boot.axf has the ability to display images on the framebuffer.<br />
<br />
[[Category:Boot]]</div>Hmk