On Fri, Jun 26, 2015 at 8:15 AM, Andrew Wing <andrew.wing@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxx> wrote:
>>>
>>> On Wed, Jun 17, 2015 at 5:57 PM, Andrew Wing <andrew.wing@xxxxxxxxxx>
>>> 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
>>
>>
>
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
