On 11/4/2013 6:46 AM, Stefan Kalkowski wrote:
With respect to your question, on how to build a corresponding image to boot it via u-boot, I recommend to have a deeper look at the run tool
Thanks for the pointer, that's a good starting point.
...
In your case, it will be sufficient to add an argument to the "RUN_OPT" environment variable, which is interpreted by the run tool. Just add:
RUN_OPT = --target uboot
into the 'etc/build.conf' file of your build directory, or invoke 'make' like the following:
RUN_OPT="--target uboot" make run/[run_script_you_want_to_build]
The run tool will produce a ready to use u-boot image containing all necessary files, including the kernel, core etc., at 'var/run/[run_script_name]/uImage' in your build directory. You can either copy that uImage to a SD-card, or load it via TFTP to the target board. Just mind to load the uImage to a different memory area than its defined load address.
This is the information I was looking for! I'm familiar with uboot, I just needed to know how to get the image built. It seems I underestimated your build system, it's more powerful than I thought.
After you've loaded the uImage to memory, you can invoke u-boot's 'bootm' command together with the memory address you put the uImage at. U-boot will look at the header of the uImage in memory, copy the contents to the load address that is specified in there, and jump to the entry point defined. If you want to read the uImage details, like the load address, you can use the u-boot tool 'mkimage' in combination with the '-l' argument. Also be aware to not load the uImage to the memory area u-boot resides in, and leave the first physical page free. Typically u-boot doesn't warn, if it fails to load an image to memory, because of a memory region clash.
That's no problem, I know the memory layout of the board.
In your position, I would start with a very simple test scenario, like the 'base/run/printf.run' script. It includes: the kernel, core, init, and a simple test-printf program.
I agree, I just want to see the kernel running, then patch it to start all 8 cores, or at least the 4 A15's in the board, then I'll work on drivers (although most of the arndale drivers should work).
Debug output is printed using a in-kernel debug printing feature. An additional UART driver isn't needed here, mostly the kernel builtin UART driver is sufficient. As you can see in the mentioned run script, the 'build_boot_image' command is given a list of all binaries that should be incorporated into the the target image (in your case uImage). The corresponding kernel is integrated automatically. All binaries, inside such a boot image, are accessible via core's ROM service. If you don't want to integrate all binaries, you want to execute in a scenario, into the boot image, e.g. to minimize u-boot's load time, you might load binaries on demand, e.g. from a SD card. Of course, that implies to first enable the regarding drivers for your target platform.
That's the idea. Load a kernel with a UART driver, SD driver and a file system from a minimal image. Then the rest can be loaded from the SD card. But that's for later, once the kernel and drivers are working.
... Don't hesitate to ask these questions. They are more than welcome. We would be glad, if you help us to improve the documentation fo new users, and developers.
I certainly will, I already received feedback from users interested in my port, so I'll be posting my progress here for others.
Thanks a lot for your help, that initial "push" was very much appreciated.
Claudio