0
votes

Recently I build a system for soc on OrangePi-win board. I use the original uboot and kernel source code from each offical site, and a workable ATF code. These are build well, and I can use them to bootup the board: but the graphic on hdmi does not work at all, while the debug serial port works just OK.

Here is my questions:

  1. As I understand, after uboot start up, it will load kernel to handle the whole board, when pass the correct device tree information and other need kernel arguments. Can I say that uboot only need a simply device tree to build and bring up the board, while the kernel will need the full configured device tree information?

  2. After uboot loaded the kernel, kernel will handle everything, nothing deal with uboot anymore, is it right? If this is correct, when I let uboot to load a kernel and a device tree just copied from a working well system: together with their /lib/modules, why the kernel meet many errors? Notice that I have modified the original working system to let it changed only the bootloader part. The kernel, the rootfs just has nothing changed. That is, what I changed is only doing a command:

    dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=8k seek=1

and then put kernel image together with the dtb to correct location and file name to let new bootloader can find and load them. Now the bootloader do works, and loads the kernel, dtb, but then just failed to show hdmi console and with many other failures, and with the root file system mounted as read only state. As I mention above, now the kernel has been loaded, so it should handle everything, nothing should fail, it would just like the unchanged system as before, is it? But it just every different with a changed bootloader. Am I missed something to figure out?

  1. The modified system just failed to initialize the hdmi output, many garbage show on screen, or just with a blank screen. Notice that the kernel works just well when using another bootloader, where should a change for it to work well again?
1
Sounds like you have a boot issue, but you're asking roundabout questions to validate your theories and you want a thesis on how U-Boot loads and executes the kernel. Even if you got all those answers, you still might not figure out the actual boot problem that you have. Why not study How To Ask Questions The Smart Way (especially "Describe the problem's symptoms, not your guesses"), and start over?sawdust
If I get all those answers, it will help to me great to understand that. Now I'm still confuse about why different bootloader will effect the kernel executino, because kernel will handle the whole system, right?K.L

1 Answers

-1
votes

Neither Uboot nor the Kernel is a monolithic thing that runs in a vacuum. Uboot has a command line input of parameters that get passed to the Kernel. The Kernel also has various modules that it loads (often for device drivers). So you can change these parameters that are passed to change their behaviour. The boot.ini file, for example.

Just doing a random copy of some Uboot stuff from here and some Kernel stuff from there (whatever the build parameters were when you compiled it) is unlikely to work well. Different vendors and different releases (and even different builds) will end up with different things they expect from the environment.

In particular, various parameters are passed about how to handle HDMI, or if it ought to be turned on at all. So that is where you need to look.