Menu
Newbie question here.
I'm looking at a u-boot boardfile, and it has many functions in it.
For example; board_mmc_init(), enet_board_init(), setup_splash_img(), etc.
Most of these functions don't get called from within the boardfile. They get called from somewhere else. But I can't figure out where.
In Linux kernel boardfiles there's a machine structure. In there we might have .init_machine = myboard_init. Then myboard_init(void) will call other functions which will in turn call other functions. I find this style easy to read.
My question is; does u-boot have an equivalent of .init_machine? Where do I look to see where everything 'starts'? Who calls all those loose functions thrown together inside a u-boot boardfile?
585
The U-Boot environment is stored in the SD Card memory and is persistent across power or reset cycles. Parameters defined by the U-boot environment variables include: target IP address, target MAC address, location in RAM where a Linux bootable image will be loaded, and many others.
U-Boot boots an operating system by reading the kernel and any other required data (e.g. device tree and ramdisk image) into memory, and then executing the kernel with the appropriate arguments. U-Boot's commands are actually generalized commands which can be used to read or write any arbitrary data.
U-Boot is a full bootloader but grub is only a 'second-stage' loader, i.e. it needs something to load it. In this case U-Boot also provides the EFI support needed by grub to work. So, yes, U-Boot can directly call linux.
Once you can read the output from your host machine, the U-Boot Console can be easily accessed by pressing any button before the autoboot sequence starts. By default, U-Boot waits up to 3 seconds before starting the autoboot sequence.
First of first, uboot will start at start.S of the specify CPU, like this: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/start.S;h=ef62fc83270a327bc7df970f598540f1d7ce0fe2;hb=HEAD
It will do some stuff like "exception vector" setup, cache setup, etc.
Then it will jump to http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=arch/arm/lib/crt0.S do some c runtime setup,
Then it will back to start.S, after some misc stuff, you can refer the comments, it will jump into lowlevel_init.S http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/lowlevel_init.S;h=82b2b86520eb2b2d63c2478145b625a49f931542;hb=HEAD
Then.. it will going to soc(very common in ARM) init, like this: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/mx6/soc.c
After soc init finish , it will going to some board relate init, in the board init, it will call some periphery device/driver init.
Hope that will give your some hit on uboot process.
94
I have an raspberry pi board which comes with bcm283x broadcom architecture and arm1176 arm core. So start.S is located in arch/arm/cpu/arm1176/start.S. This will initializes critical registers and disables mmu. Next it will do lowlevel_init and then branch to _main which is defined in case of raspberry pi is in arch/arm/lib/crt0.S This initializes stack pointer and global data and calls board_init_f to initialize the system RAM(DRAM) for executing u-boot code. It should use global_data pointer to execute.
26
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
