HELLO! BOOT0 is starting!
boot0 version : .3.0
dram size =1024
Succeed in opening nand flash.
Succeed in reading Boot1 file head.
The size of Boot1 is 0x00036000.
The file stored in 0X00000000 of block 2 is perfect.
Check is correct.
Ready to disable icache.
Succeed in loading Boot1.
Jump to Boot1.
[ 0.146] boot1 version : 1.3.1a
[ 0.146] pmu type = 3
[ 0.146] bat vol = 0
[ 0.177] axi:ahb:apb=3:2:2
[ 0.177] set dcdc2=1400, clock=1008 successed
[ 0.179] key
[ 0.191] no key found
[ 0.191] flash init start
[ 1.570] flash init finish
[ 1.571] fs init ok
[ 1.572] fattype FAT16
[ 1.572] fs mount ok
[ 1.578] script finish
[ 1.580] power finish
[ 1.584] BootMain start
[ 1.584] 0
[ 1.593] usbdc_vol = 4000, usbdc_cur = 0
[ 1.593] usbpc_vol = 4000, usbpc_cur = 0
[ 1.595] init to usb pc
[ 1.598] set pc
[ 1.601] key value = 0
[ 1.603] recovery key high 6, low 4
[ 1.607] unable to find fastboot_key key_max value
[ 1.613] test for multi os boot with display
[ 1.616] show pic finish
[ 1.619] load kernel start
[ 1.639] load kernel successed
[ 1.639] start address = 0x4a000000
[ 1.641] power exit detect
[ 1.644] usb exit d
As we can see boot0 loads and initialises the SDRAM Ram and then jumps to Boot1. Boot1 checks to see if the FEL Recovery button is pressed by the following
[ 0.179] key
[ 0.191] no key found
[ 0.191] no key found
While continuing the remaining steps in boot1 until [ 1.584] 0 it also waits for key input from the serial port. In fact the '0' is the ASCII key value it detected, in this case zero (no key pressed). So what happens if we hold a key pressed while the board is booting?
If we keep key '1' pressed while the board is booting we get this
Jump to Boot1.
[ 0.146] boot1 version : 1.3.1a
[ 0.146] pmu type = 3
[ 0.146] bat vol = 0
[ 0.177] axi:ahb:apb=3:2:2
[ 0.177] set dcdc2=1400, clock=1008 successed
[ 0.178] key
[ 0.191] no key found
[ 0.191] flash init start
[ 1.568] flash init finish
[ 1.569] fs init ok
[ 1.570] fattype FAT16
[ 1.570] fs mount ok
[ 1.576] script finish
[ 1.577] power finish
[ 1.582] BootMain start
[ 1.582] 49
[ 1.582] part count = 2
[ 1.585] USB Device!!
[ 1.588] USB Connect!!
[ 1.643] uSuspend
If we now connect the lower usb port to a PC we get this
[ 188.626] uSuspend
[ 188.701] uSuspend
[ 188.768] usb_device: Set Address 0x0x00000006
[ 189.788] usb_device: Get MaxLUN
And for this board 2 usb drives should appear in Windows/Linux showing the boot nand partition and I think the Android data partition. In fact it will shown every FAT partition it can recognise from the NAND chip. I was hoping that it would also show FAT partitions for the SD card/USB drive but it doesn't seem to be the case. This feature is used to facilitate the coping of files to the boot partition while developing the bootloader code without having to re-flash the whole chip. For me this is an alternative way to get to the boot partition files or to copy files from another FAT partition. To get out of this mode press the FEL recovery button and the board reboots.
If we try key '2' we get this
[ 0.221] BootMain start
[ 0.221] 50
[ 0.222] Jump to fel
The boot1 jumps to FEL recovery mode to be used with Livesuite.
If we try key '3' we get this
[ 0.221] BootMain start
[ 0.221] 51
[ 0.222] welcome to key value test
[ 0.225] press any key, and the value would be printed
[ 0.231] press power key to exit
Seems to be some kind of test mode for detecting button presses in our case we have just one button the FEL recovery button to test.
[ 47.254] key value = 15
[ 47.257] key value = 63
Unfortunately none of the other numerical keys seems to have any effect while boot1 is booting.
Interesting..
ReplyDeleteWasn't this documented by the manufacturer, who provided you this board,
Nope the manufacture doesn't provide this information because its part of the closed sourced AllWinner boot loader.
DeleteIt is documented by Allwinner in the bootloader documentation, available in the A10 SDK which can be found at numerous places.
ReplyDeleteI've been scratching my head trying to figure out the recovery boot process.
ReplyDeleteWhen the special key combination is detected, how does boot.axf pass this information to u-boot.bin? the latter has all the necessary settings for normal and recovery boot steps but after many, many hours scrubbing the web I couldn't find this explained anywhere.
It was simpler in the pre-u-boot times (GB) because the linux.ini file have the arguments passed to the Linux kernel. Now that u-boot is part of the picture, I really don't know how this works.