[meta-xilinx] ramdisk format for booti command in u-boot

Giordon Stark kratsg at gmail.com
Fri Jan 12 05:37:35 PST 2018


Hi,

Just a quick update since I think I can answer part of my question.

1) the image format is indeed correct.

Lord Stark:~/gfex-prototype3$ hexdump -n64 -C Image
00000000  4d 5a 00 91 ff 7f 2e 14  00 00 08 00 00 00 00 00
|MZ..............|
00000010  00 70 d3 00 00 00 00 00  0a 00 00 00 00 00 00 00
|.p..............|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
|................|
00000030  00 00 00 00 00 00 00 00  41 52 4d 64 40 00 00 00  |........ARMd@
...|
00000040

I compared this with
http://elixir.free-electrons.com/linux/latest/source/Documentation/arm64/booting.txt
and
this looks correctly built.

2) I'm not sure, but I think the addresses are slightly arbitrary with some
caveats that there's enough space such that booting the kernel doesn't
override the location of these things in memory - at least until such a
time I persist it by writing to the SPI or something more permanent

3) I'm not sure what's going on here. I suspect it's related to SPI flash
issues that I need to work out. I'm not clear on how to get the kernel to
boot from a filesystem that is in my SPI flash. Any pointers on this would
be nice.

Giordon

On Wed, Jan 10, 2018 at 6:22 PM Giordon Stark <kratsg at gmail.com> wrote:

> Hi all,
>
> Initially, I tried the bootm command, and found the Image format to be
> incorrect.. so then I switched to the booti command, and I get this:
>
> > booti 0x200000 0x7000000 0x1000000
> Bad Linux ARM64 Image magic!
>
>
> I do something like the following to set things up:
>
> > setenv ip no
> > setenv autoload no
> > setenv serverip 192.168.1.100
> > dhcp
> > tftpboot 0x200000 Image
> > tftpboot 0x7000000 zynq-base-gfex-prototype3.tar.gz
> > tftpboot 0x1000000 gfex-prototype3.dtb
>
> Three questions:
>
> 1) Is there a different image format I should be using? If so, what is it?
> 2) are the addresses here arbitrary?
> 3) if I run without the initrd (passing '-' as the second parameter
> instead), it gets to a point where it cannot open a root device (we have no
> working SD card):
> https://gist.github.com/kratsg/b5630a23aa3b71161da833fcad07eaaf - how to
> fix this? Having `bootargs=boot=ram0` or something similar did not work.
>
> Thanks,
>
> Giordon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20180112/bf159aee/attachment.html>


More information about the meta-xilinx mailing list