Deploy genode on arndale

[Claudio L.]

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