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

[Dennis Gilmore]

On Wednesday, June 17, 2015 05:57:00 PM Andrew Wing 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.
> 
> 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>

Is there a defined console environment variable? 

assuming that your u-boot is configured correctly you can replace ext2load or 
ext4load with load. ext4load is actually an alias for ext2load. It's all using 
the same code paths under the hood. two suggestions from me. move the kernel 
to somewhere higher, perhaps the decompressor is clobbering the uncompressed 
kernel as it decompresses. make sure that the console is set right. then next 
thing would be to look at the dtb.

Dennis


> 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.
> 
> I do have access to the u-boot source.
> 
> Andrew
> 
> On 17 June 2015 at 11:42, Peter Robinson <pbrobinson at gmail.com> wrote:
> > Hi Andrew,
> > 
> > > It's using a TI AM3352 OMAP family SoC. Overall it looks like a
> > 
> > BeagleBone
> > 
> > > Black, but no EEPROM on i2c, different DDR RAM (and no sd card socket).
> > > 
> > > I do have a device tree. I have full access to all the bits and pieces
> > 
> > put
> > 
> > > together to make this boot under Angstrom, just don't know how to
> > 
> > re-arrange
> > 
> > > them to make it boot under Fedora!
> > 
> > So if you've copied the DT onto the boot partition (partition 1) you
> > should be able do something along the lines of the bits below to get
> > it booting. I'm making the assumption here that it's got eMMC for the
> > onboard flash and it's identified as mmc0, update as appropriate. You
> > might need to swap ext4 for ext2, obviously update the name of the
> > dtb.
> > 
> > setenv bootargs console=${console} root=LABEL=_/ ro rootwait
> > ext4load mmc 0:1 0x80300000 vmlinuz-4.0.4-301.fc22.armv7hl
> > ext4load mmc 0:1 0x81600000 uInitrd-4.0.4-301.fc22.armv7hl
> > ext4load mmc 0:1 0x89300000 blah-blah.dtb
> > bootz 0x80300000 0x81600000 0x89300000
> > 
> > Let me know how you get on.
> > 
> > Do you have access to the u-boot source?
> > 
> > Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/arm/attachments/20150617/60904293/attachment.sig>