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/
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 running an ARM full system simulation in gem5 and the configurations I'm using in the commandline is:
./build/ARM/gem5.perf configs/example/arm/fs_bigLITTLE.py
--kernel=/home/ting-bazinga/gem5/linux-arm-gem5/vmlinux
--caches
--disk /home/ting-bazinga/gem5/fs_imgs/disks/aarch64-ubuntu-trusty-headless.img
--bootscript /home/ting-bazinga/gem5/fs_imgs/test.rcS
From the post Using perf_event with the ARM PMU inside gem5 I presume obtaining PMU events in gem5 is possible. However I didn't found the exact method for how to do that.
perf can be used to obtain PMU information, on my local machine I can just download the linux-tools-common in my terminal to use that tool. But I can't do the same with the simulation. There isn't a perf binary that I can just find online (or maybe anyone can give a hint of how to write this kind of binary?) And I also tried downloading the linux-tools-common package, copying it into the disk image then using the makefile to compile it. But somehow the makefile does not work in the simulated system.
Or can the PMU events be abtained using C code? In the post I mentioned above someone used C code to count the number of mispredicted branches by the branch predictor unit during a specific task. And I can use perf_event_open to obtain number of instruction during an execution. However running the perf_event_open code requires root, but I cannot use sudo in the simulated system.
Can anybody give me some instructions on how to obtain PMU events in gem5? Many thanks.
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!
How can we boot independent bare board binary(not standalone binary which runs using U-Boot environment and not linux kernel) from U-Boot. My requirement is to reinitialize the board and drivers using my binary...
I can replace the U-Boot in the boot medium(here NOR Flash) with my binary but my requirement is to not removing the U-boot from NOR flash and I should load my binary from LAN network using "tftp" command.
Thanks and Regards,
Veerendranath
How to boot bare board binary from U-Boot?
Use U-Boot's go command to execute any kind of standalone program.
How can we boot independent bare board binary(not standalone binary which runs using U-Boot environment and not linux kernel) from U-Boot.
Use U-Boot's go command to execute any kind of standalone program.
... I should load my binary from LAN network using "tftp" command.
Use U-Boot's tftpboot and go commands to execute any kind of standalone program. (The abbreviated tftp command has been deprecated now that there's also a tftpput command.)
Here problem is when I use go command my program has to use U-Boot service functions(I mean standalone binaries will run in U-Boot environment)...
You're misinformed, there is no requirement that you have to "use U-Boot service functions".
Build your standalone program independently of U-Boot, and it will execute completely independent of U-Boot.
But I can't boot using bootm or any other boot commands provided by U-Boot as my binary is not in kernel format.
There is no "kernel format"; that's why U-Boot uses the mkimage wrapper to identify binaries.
The bootm command is designed specifically for the booting requirements of OSes such as the Linux kernel (e.g. a buffer containing the command line parameters) by specifying the characteristics of the binary.
Use U-Boot's go command to execute any kind of simple, standalone program.
If you have issues executing your binary when using the go command, then the problem lies with your program, e.g. taking control of the processor and initializing its C environment.
ADDENDUM
When I use the term standalone program, I'm referring to the generic definition (aka bare-metal), and not the U-Boot-specific definition related to its examples/ directory.
FWIW I have used the go command for both kinds of "standalone" programs.
U-Boot describes its "standalone" as
* "Standalone Programs" are directly runnable in the environment
* provided by U-Boot; it is expected that (if they behave
* well) you can continue to work in U-Boot after return from
* the Standalone Program.
Note that the use of the U-Boot environment is optional.
A standalone program is not required to use the U-Boot environment, especially if there is no intention of returning back to U-Boot.
There is nothing in U-Boot to detect or restrict the behavior of a standalone program.
If you cannot get your standalone program to work with the go command, then the problem lies with your program, and not the go command.
The go command merely transfers control (i.e. a branch instruction to the specified memory location), and places no restrictions or requirements whatsoever on that code (other than what is sensible for operation of the system).
Use an in-circuit emulator (ICE) or JTAG debugger to resolve problems with your code, especially when your program does not use the existing stack.
ADDENDUM 2
Instead of the ambiguous go command, the mkimage wrapper does provide for the standalone image-type for use with the bootm command.
See Creating a bare metal boot image, but don't expect different results from a go command.
The advantages of using a wrapper and bootm over go is that the downloaded image (a uImage file) can be:
identified/verified with the iminfo command,
compressed (e.g. gzip, bzip2, lzo) or uncompressed.
You can create the boot.bin with fsbl, bitstream, uboot.elf and you applications. Then flash in the QSPI flash and choose to boot from it.
Or you can boot from TFTP. Here you need to create the boot.bin just with fsb, bitstream, and uboot.elf. You need the change the uboot header file to force it boot from tftp like tftpboot 0x0 hello.elf. Once booted it will grab the elf/bin file with tftp and boot the board with bootelf or go command.
The same you can boot from SD card if there is one.
I'm new on OpenOCD, has anyone attempted to use Olimex OpenOCD to actually flash program hex file (from Kiel say) into ARM CORTEX M0 (generic).
What do I need to setup script file to take each word of the hex file to performs mww (memory write word) within the MCU flash?, can anyone provide an example. I use python.
I open for suggestion.
I use Window PC.
All Cortex M0 that I know of have no JTAG, but only SWD support. SWD is not yet available in OpenOCD - it is still in development.
Another note: The method for writing the flash memory is specific for each vendor/chip.
Sure, what platform in particular? some googling will find the exact sequence. flash unlock, erase, program, etc.
Section 6 of this page for example.
http://pygmy.utoh.org/riscy/cortex/led-lpc17xx.html
I am trying to figure out what board I did it on but those were pretty much the commands I followed and it worked just fine. It may have been the leaflabs maple mini. The steps are the same. To avoid the steps or scripting it, etc. what I ended up doing was writing a few lines of bootloader that said if ram+0 = 0x12345678, and ram+4 = 0x87654321 then branch to ram+8 else infinite loop. then it was trivial to use the jtag to load a program into ram with the two words and an entry point at 0x08 bytes into ram, press reset and run the program. On a cold power up it just hits the infinite loop. I spend my day on a bigger arm based system loading everything into ram using jtag so it made it quite comfortable. You could just script it in openocd and simply type the openocd command have the flash load happen.
Update for people stopping by...
You do not have to use mww, if you're just trying to flash-program (eg. upload your own code) to your microcontroller.
Some time ago, OpenOCD got a ("built-in") convenience-script, that you can use for programming, this "command" is called "program".
Here's an example from the documentation on the "program" command:
openocd -f interface/ftdi/jtag-lock-pick_tiny_2.cfg -f board/stm32f3discovery.cfg -c "program filename.elf verify reset"
-Replace "stm32f3discovery" by your board. If you use a different adapter, replace the interface with the appropriate configuration file.