[fedora-arm] Installation of Fedora 22 on my ARM based board

[Andrew Wing]

Well, I want to use my colleagues nice new device tree source, but all I
have is the sad old Angstrom kernel 3.x toolchain to process it into a dtb
(which I nevertheless had a go with and which didn't get me any further). I
assume I need something to produce a dtb compatible with the shiny Fedora
4.0 kernel? I don't have a Fedora box here (shame on me of course) though
one could be found/created if needed.

Andrew











On 17 June 2015 at 18:09, Peter Robinson <pbrobinson at gmail.com> wrote:

> On Wed, Jun 17, 2015 at 5:57 PM, Andrew Wing <andrew.wing at bgch.co.uk>
> wrote:
> > Thank you again. That's got me a little further.
> >
> > I notice from looking at the sd card it uses ext3 for the boot partition,
> > ext4 for the root file system, so the dd to the mmc must preserve that.
> > Unfortunately the boot loader only has an ext2load and ext4load.
> Consulting
> > with a colleague and Mr google, I shouldn't expect an ext3load to be
> > available but ext2load might well load ext3 with a little bit of luck.
>
> Just use ext4load and it'll all work as expected, in the case of the
> root partition it's never actually touched by u-boot so it doesn't
> actually matter what it is as long as the kernel/initrd has the
> appropriate filesystem support for the rootfs
>
> > I duly proceeded under that assumption and got the following results:
> >
> > U-Boot# setenv bootargs console=${console} root=LABEL=_/ ro rootwait
> > U-Boot# saveenv
> > Saving Environment to MMC...
> > Writing to MMC(1)... done
> > U-Boot# ext2load mmcblk 0:1 0x80300000 vmlinuz-4.0.4-301.fc22.armv7hl
> > mmc_send_cmd: timeout: CTO
> > mmc_send_cmd: timeout: CTO
> > 5645832 bytes read in 660 ms (8.2 MiB/s)
> >
> > <repeated the above because of the timeout>
> >
> > U-Boot# ext2load mmcblk 0:1 0x80300000 vmlinuz-4.0.4-301.fc22.armv7hl
> > 5645832 bytes read in 661 ms (8.1 MiB/s)
> > U-Boot# ext2load mmcblk 0:1 0x81600000 uInitrd-4.0.4-301.fc22.armv7hl
> > 27397171 bytes read in 3184 ms (8.2 MiB/s)
> > U-Boot# ext2load mmcblk 0:1 0x89300000 hub.dtb
> > 31710 bytes read in 14 ms (2.2 MiB/s)
> > U-Boot# bootz 0x80300000 0x81600000 0x89300000
> > ## Loading init Ramdisk from Legacy Image at 81600000 ...
> >    Image Name:   initramfs
> >    Image Type:   ARM Linux RAMDisk Image (uncompressed)
> >    Data Size:    27397107 Bytes = 26.1 MiB
> >    Load Address: 00000000
> >    Entry Point:  00000000
> > ## Flattened Device Tree blob at 89300000
> >    Booting using the fdt blob at 0x89300000
> >    Loading Ramdisk to 9e404000, end 9fe24bf3 ... OK
> >    Using Device Tree in place at 89300000, end 8930abdd
> >
> > Starting kernel ...
> >
> > <then it just HANGS>
> >
> > A colleague who is looking into using another well-known ARM linux distro
> > found that the dtb file used with Angstrom needed some minor modification
> > before it could be with that distro (and would otherwise hang), so  that
> is
> > an area of investigation. I guess it would be good to nail down whether
> I am
> > getting problems because of the ext2/ext3 or get some clues as to where
> it
> > is bombing out.
>
> It's not an issue with the extX side of things, if it was you'd not
> even got as far as loading the kernel/initrd from the card.
>
> I've seen this issue in exactly 3 cases:
> 1) wrong/bad dtb
> 2) serial console isn't supported or it's wrong (unlikely here)
> 3) the kernel/initrd is too large and overwites the dtb in memory.
>
> I'd be going with 1) so I agree with your colleague's assumption. It
> might even be due to changes between the 4.0 kernel Fedora has and
> what ever the version Angstrom uses. Is the .dts published anywhere,
> have you tried the modified one that works with the other distro?
>
> Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/arm/attachments/20150618/69504d87/attachment.html>