willmore Posted September 4, 2017 Share Posted September 4, 2017 Hello, all. My Orange Pi PC2 recently broke when doing an upgrade. So I hooked a serial cable to it and watched what it did. The error was that it couldn't find the dtb file. It was looking for "/boot/dtb/allwinner/allwinner/sun50i-h5-orangepi-pc2.dtb" and "/dtb/allwinner/allwinner/sun50i-h5-orangepi-pc2.dtb", but the former fails because the file is at "/boot/dtb/allwinner/sun50i-h5-orangepi-pc2.dtb". So, I put a simlink in dtb/allwinner called 'allwinner' and pointing to the parent directory. Now the device boots. I'm not sure if that's the proper fix, but it works for now and I'll fix it if I manage to break something with it later on. This brings me to the real questions which I discovered as I tried to debug this. While booting uboot says it loads something--it dosn't say what--and reports "6944 bytes read in 180 ms (37.1 KiB/s)" That looks like it was the boot.bmp file. Which--according to 'file'--is really a BMP file. But it looks like uboot wasn't expecting that because it says "Unknown command 'bmp' - try 'help'" That probably come from the 'BMP' magic entry at the beginning of the boot.bmp file. So, first question: Why are we loading a .bmp file? uboot clearly doesn't expect it and doesn't seem to know what to do with it. Where does uboot get the idea that it should even load that file? The next set of quesitons come from what uboot does next. It does "2253 bytes read in 191 ms (10.7 KiB/s)" which is the right size to be boot.scr. That file seems to start with some non-printable garbage which doesn't seem to upset uboot. It uses a bunch of predefined variables and I can't find where they are defined--the location of the dtb files in particular are what I was trying to determine the source of. Where does uboot get this? The armbianEnv.txt file doesn't have it. I'd like to know more about how the boot process works. If anyone could point me to a good source of information about this, I would appreciate it. The uboot documentation is very generic and doesn't deal with the specifics of how armbian handles things. Thank you! Link to comment Share on other sites More sharing options...
zador.blood.stained Posted September 4, 2017 Share Posted September 4, 2017 17 minutes ago, willmore said: So, first question: Why are we loading a .bmp file? To (try to) display a boot logo 17 minutes ago, willmore said: uboot clearly doesn't expect it and doesn't seem to know what to do with it. Where does uboot get the idea that it should even load that file? The logo patch contains 2 parts: extra commands in the boot sequence and a configuration patch to compile in BMP support code: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/sunxi-boot-splash.patch Obviously "unknown command "bmp"" error means that one part of the patch doesn't work. 17 minutes ago, willmore said: It uses a bunch of predefined variables and I can't find where they are defined--the location of the dtb files in particular are what I was trying to determine the source of. Where does uboot get this? The armbianEnv.txt file doesn't have it. boot.scr is boot.cmd packaged with a special header that contains the image type, checksum and similar things. U-boot sets some variables during the boot sequence, some of them come from platform specific include files, others come from generic distro_bootmd support. You can check the u-boot environment with "env print", it will contain most of the boot sequence commands and variables, you'll just have to trace how commands are calling other commands while setting some variables in the process. 1 Link to comment Share on other sites More sharing options...
zador.blood.stained Posted September 4, 2017 Share Posted September 4, 2017 I already answered in another thread, but OPi PC2 (and all old A64 and H5 images in general) were broken recently because we upgraded u-boot from 2017.01-rc to 2017.09-rc and it included this change: http://git.denx.de/?p=u-boot.git;a=commit;h=2eff3b7179a95a5cde0eaf8fae8c4b18956f2f59 Since these images are still considered experimental backwards compatibility was not a concern during this upgrade. Link to comment Share on other sites More sharing options...
willmore Posted September 4, 2017 Author Share Posted September 4, 2017 @zador.blood.stained Perfect, thank you, that's exactly what I was looking for! Link to comment Share on other sites More sharing options...
willmore Posted September 4, 2017 Author Share Posted September 4, 2017 (edited) 2 minutes ago, zador.blood.stained said: I already answered in the other thread, but OPi PC2 (and all old A64 and H5 images in general) were broken recently because we upgraded u-boot from 2017.01-rc to 2017.09-rc and it included this change: http://git.denx.de/?p=u-boot.git;a=commit;h=2eff3b7179a95a5cde0eaf8fae8c4b18956f2f59 Since these images are still considered experimental backwards compatibility was not a concern during this upgrade. Understood. I wasn't worried about the breakage as it's easily fixed and--as you said--this is an experimental build. But I did think it was a good time to improve my understanding of the boot process. Edited September 4, 2017 by willmore grammar Link to comment Share on other sites More sharing options...
Recommended Posts