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

[Peter Robinson]

On Fri, Jun 26, 2015 at 8:15 AM, Andrew Wing <andrew.wing at bgch.co.uk> wrote:
> Thanks Peter. It was the blob. With a shiny new device tree blob I am
> booting into Fedora just fine.

Brilliant, thanks for the update.

Peter

> On 18 June 2015 at 12:00, Andrew Wing <andrew.wing at bgch.co.uk> wrote:
>>
>> 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
>>
>>
>