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.
Related
I am currently learning how to emulate both mips(el) and arm architecture using Qemu. The images which I used for both architecture is by aurel32 from this website, https://people.debian.org/%7Eaurel32/qemu/
I noticed that the mips images does not have initrd while the arm images have initrd. I am unsure why arm requires initrd when running Qemu but mips does not.
Anyone know why this is the case?
Thanks for the help!
There is no inherent reason -- you can build an Arm kernel with enough devices built-in to not need an initrd, and you can build a MIPS kernel that does require an initrd. You'd have to ask Aurelien why the two sets of images he built had different configs (assuming he even remembers 6 years later!), but I suspect it's just that for MIPS he was able to use the stock Debian kernel whereas for Arm he had to compile his own kernel, and so the configuration choices for the two weren't identical.
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/
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!
I'm using Arm DS-5 and Xilinx SDK for developing programs on Zynq board.
I'm trying to boot Zynq 702 board from Qspi Flash.
What I've done so far is generating FSBL project from Xilinx SDK, and combining it with my application using Bootgen tool in SDK, then program it into the flash.
There are several questions in my mind.
DS-5 produces an .axf file, Bootgen requires an .elf file. Can I use
the .axf file by just changing its extension to .elf or do I require
some more steps?
Is there a tool that shows the inner structure of an .axf file?
Showing what is where?
And how can I debug if I managed to boot from QSPI. For example I want to debug my application from the beginning of FSBL, is it possible? Because in Qspi Boot, When I power on the board, my application would start running and when I connect with JTAG, it would be in somewhere in my application.
An AXF might have some extra ARM-toolchain magic in it (I'm not sure off-hand), but at heart it's an ELF file - the ARM toolchain provides fromelf for poking around inside them, but other tools like readelf and objdump also work.
I'm not familiar with the Zynq platform so I don't know any specific debugger tricks, but a general one is just to put an infinite loop at the start of your code (possibly using volatile or inline asm trickery if necessary to prevent optimisation) - once the debugger's connected and broken into it, you just move the PC past the loop and continue.
You can totally halt QSPI-booted Zynq via JTAG and do whatever you want with it. However, there are some quirks. Sometimes Zynq goes into some kind of lockup, and JTAG doesn't work at all, and you need to power-cycle before retrying. Some not-so-well-written peripherial might die after starting software over JTAG, so you might need to re-load bitstream first. And there are some Vivado-related bugs (like the one where you cannot re-flash the board unless you downgrade to 2017.2 or change MIO2-6 pulls or patch the FSBL) but i'm not sure if they apply in your case.
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.