Thanks Peter. It was the blob. With a shiny new device tree blob I am booting into Fedora just fine.
AndrewOn 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.AndrewOn 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
It's not an issue with the extX side of things, if it was you'd not
> 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.
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
