All sources that I have found so far have mentioned that device tree blobs are used as part of Linux initialization after u-boot is already up and running. I am trying to bring up u-boot itself on my ARM board and I see many OF errors in parsing the dtb even before I get to the u-boot console. Does u-boot use the device tree directly? Would you please point to any relevant documentation on this process? Thanks!
Related
I'm currently trying to understand booting process of AM65x SoC by Texas Instrument and I'm getting confused on SPL. Can somebody please correct me if I'm wrong? Here is what I understanding so far. (Assume we are using TMDX654IDKEVM.)
SPL is second piece of SW that is running, and according readme in u-boot should run on R5 cores. In TI terminology it get called tiboot.bin and it is produced by u-boot config am65x_evm_r5_defconfig, isn't it? And it is not only binary file straight from compiler, but it have some header with load address added, isn't it?
Next task for this component is to load sysfw (from TI) into M3 core and setup DRAM controller. That is somehow clear to me, except one thing, I'm still not sure where is code from DRAM config in u-boot.
Then we have working DRAM and we can load big things, so we are loading full u-boot with all features that is able to load kernel and rootfs from various sources. Am I correct if I say that this second u-boot binary is get from u-boot config am65x_evm_a53_defconfig? If so, what is A53 SPL in above readme link? Is there two u-boot binaries running on A53 core?
Many thanks in advance.
Yes, on the A53 (and for other TI SoCs in this overall family, ie the whole J72 line) we load an SPL on the Cortex-A core and that loads the full U-Boot on the Cortex-A.
I'm reading the Zircon source code: https://fuchsia.googlesource.com/fuchsia/+/master/ and I'm trying to find how the kernel image is linked. That is, where is the start function placed?
For example, on raspberry pi, the kernel.img start function is placed at 0x80000 with a link script like here: https://github.com/bztsrc/raspi3-tutorial/blob/master/01_bareminimum/link.ld
There is the boards directory: https://fuchsia.googlesource.com/fuchsia/+/master/boards/ which has some dependencies for some boards. It adds some needed drivers. However, I couldn't find anywhere where the linking occurs for each board.
What if I want to support a new board? Suppose I want to port Zircon to raspberry pi, so I need to make the start.S, specifically the start function on it, start at 0x80000. How would I instruct the Zircon build system to do it?
There are a handful of layers to understand, some of which are a little different.
Here's the linker script you may be looking for, but it doesn't tell the whole story: https://cs.opensource.google/fuchsia/fuchsia/+/master:zircon/kernel/phys/zbi_executable.gni
Kernel images included in ZBI's are generated around here, depending on configuration:
https://cs.opensource.google/fuchsia/fuchsia/+/master:zircon/kernel/BUILD.gn;l=465
There are also boot-shims, which are used to bridge various worlds to ZBI, some for arm64 are here: https://cs.opensource.google/fuchsia/fuchsia/+/master:zircon/kernel/target/arm64/boot-shim/
These also have the kinds of build parameters you may be looking for:
https://cs.opensource.google/fuchsia/fuchsia/+/master:zircon/kernel/target/arm64/boot-shim/BUILD.gn;l=37
Multiboot is common in the Linux world, and this shim for x64 handles exactly that:
https://cs.opensource.google/fuchsia/fuchsia/+/master:zircon/kernel/target/pc/multiboot/
An example boot shim configuration with minimal dtb interaction is here: https://cs.opensource.google/fuchsia/fuchsia/+/master:zircon/kernel/target/arm64/board/msm8998/boot-shim-config.h;bpv=0
I'm trying to load FreeRTOS on Cortex-M4 of i.MX8MQ SoC and found that it is a heterogeneous multi-core architecture, where the Cortex-A53 processor acts as master and loads the Cortex-M4 controller by using the bootaux command. When tried to get information on bootaux I was unable to find any except the references to TCM & DDR. I tried looking into the U-boot reference manual and no luck.
So, my questions are
What exactly does the bootaux command do?
How it loads the binary to Cortex-M4 controller? And kick-off execution of that binary?
What is the physical medium over which U-boot of Cortex-A53 loads binary to Cortex-M4?
Are these kind of processor architectures physically connected inside the SoC?
I think bootaux is custom command implemented by the NXP customization to U-boot, where can I find the code for the same?
I'm new to U-boot, any corrections to my understanding, references and additional info is appreciated.
Quoted from below link (tried it and it works):
You can then start your first Hello World application on the Cortex-M4 manually (after copying one of the binary above to your storage):
=> load mmc 0 $m4loadaddr hello_world.bin
=> dcache flush
=> bootaux $m4loadaddr
https://boundarydevices.com/freertos-sdk-v2-3-for-i-mx8mq/
I searched a lot a bout this question and I did not find any clear answer yet.
As you know, AVR microcontrollers e.g. Atmega128 have a Flash memory which can be divided into Bootloader and Application memory. I've adjusted the parameters of each one and loaded my boot and application load. Is there any way (using code or from terminal) to know the exact size of each memory and the available bytes????
Some people may be mention avr-size command. This command give me the size of the whole flash memory. I want to distinguish between boot and application memory.
Thanks in Advance
You have two firmwares, the bootloader and application, each will have its own size.
For each build, add the linker flag to your linking command line -print-memory-usage to make it print how much flash and RAM is used.
(This flag is not supported by every tool-chain, but AVR might support it)
More info: https://stackoverflow.com/a/41389481/2002198
Or, you can get the memory usage with avr-size:
avr-size -C --mcu=atmega168 project.elf
Reference: http://www.avrfreaks.net/forum/know-code-size-and-data-size
There's other detail you have to be aware: Depending the way you are loading your application (flash writing vs bootload loading) you will align the application with FLASH blocks (usually 2 kibs). Depending the way you are doing you will have smaller available flash memory to the application.
Just read the manual:
The actual address of the start of the Boot Flash section is deter-
mined by the BOOTSZ fuses
and you will find your answer.
If you have already built your bootloader then you should be able to tell how big it is either by looking carefully at the steps you performed to build it, or by examining the HEX file for the bootloader. The HEX file says exactly what addresses the code in it are written to.
I am trying to load an ascii file into memory using the command line and I would like to know if there is a command that does it using ARM DS-5 IDE.
I have in the past use the previous ARM tools (RVDS) and been able to perform this task using the readfile command.
Thanks in advance.
The DS-5 loadfile and load commands will annoyingly only work with executable images because they both demand to know an entry point address. Simply putting arbitrary data (such as your text, or a raw binary like a Linux zImage) into the target's memory is done with very-unintuitive-named restore command, with which you still have to add the binary argument to avoid getting the same error as the others about not understanding the file format.
ARM Infocenter: DS-5 File-related commands