Installation of Fedora 22 on my ARM based board

[Andrew Wing]

Hi guys,

I am trying to get Fedora 22 installed on an OEM board something akin to a
beaglebone black but with no SD card support, different memory etc. I also
have my own u-boot, different but no doubt a not so distant relative to the
one provided with Fedora 22 for ARM.

Current thinking was to parallel the advice on installation on the web page
for booting from an SD card by dd ing my own bootloader (MLO/.img) instead
of the default Beaglebone black Fedora 22 versions inside the image. Write
the whole SD card image to my onboard emmc and reboot.

However when I do this,  the boot loader parameters are not set up to start
the fedora kernel image.

My understanding is that at this point we should only be running the
initialisation script to set up a final image, so I'm not quite certain
whether this approach is going to work beyond this stage anyway.

So some obvious questions are:

1) is my current approach plausible or is there a better way of doing this?
2) if I follow through with my current approach, what should I set in the
boot parameters to ensure that the boot loader starts up the Fedora kernel
image? I'm not really finding much info about this sort of area (i.e.
porting to something other than a 'standard' board), is there some useful
source that I'm missing?

Many thanks for any info,

Andrew

[Peter Robinson]

Hi Andrew,

>  I am trying to get Fedora 22 installed on an OEM board something akin
> to a
>  beaglebone black but with no SD card support, different memory etc. I also
>  have my own u-boot, different but no doubt a not so distant relative to the
>  one provided with Fedora 22 for ARM. 
u-boot's vary a lot, it depends a lot on what features are enabled and
what version. You also don't mention the actual SoC the board is
using. Is it the same am33xx as the BBB or something entirely
different.

>  Current thinking was to parallel the advice on installation on the
> web page
>  for booting from an SD card by dd ing my own bootloader (MLO/.img) instead
>  of the default Beaglebone black Fedora 22 versions inside the image. Write
>  the whole SD card image to my onboard emmc and reboot. 
That probably won't work, do you have a device tree for the device?

>  However when I do this,  the boot loader parameters are not set up to
> start
>  the fedora kernel image. 
If your u-boot supports the common boot distro spec in u-boot it
doesn't need parameters and will just auto boot.

>  My understanding is that at this point we should only be running the
>  initialisation script to set up a final image, so I'm not quite certain
>  whether this approach is going to work beyond this stage anyway. 
If we know of the device and it's supportable that is the case, if we
support the SoC and you have an appropriate dtb it might almost be
that easy.

>  So some obvious questions are:
>
>  1) is my current approach plausible or is there a better way of doing this? 
Hard to say as the information you've given above it about the
equivalent of "my car won't start" to a mechanic without providing any
details of the make and model. We can probably fix it with some more
info :-)

Once you have booted it to u-boot and are at the u-boot prompt can you
run "version" and "printenv" and copy the entire contents including
any boot messages to a fpaste (http://fpaste.org/) and reply with the
link to the details.

Peter

[Andrew Wing]

Hi Peter,

thanks for responding.

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!

Here's the link.

http://ur1.ca/munvn

Hopefully I've answered everything asked but do let me know if I haven't!

Thanks again.

Andrew


On 17 June 2015 at 09:25, Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:

>  Hi Andrew,
>
>  > I am trying to get Fedora 22 installed on an OEM board something akin to
>  a
>  > beaglebone black but with no SD card support, different memory etc. I
>  also
>  > have my own u-boot, different but no doubt a not so distant relative to
>  the
>  > one provided with Fedora 22 for ARM.
>
>  u-boot's vary a lot, it depends a lot on what features are enabled and
>  what version. You also don't mention the actual SoC the board is
>  using. Is it the same am33xx as the BBB or something entirely
>  different.
>
>  > Current thinking was to parallel the advice on installation on the web
>  page
>  > for booting from an SD card by dd ing my own bootloader (MLO/.img)
>  instead
>  > of the default Beaglebone black Fedora 22 versions inside the image.
>  Write
>  > the whole SD card image to my onboard emmc and reboot.
>
>  That probably won't work, do you have a device tree for the device?
>
>  > However when I do this,  the boot loader parameters are not set up to
>  start
>  > the fedora kernel image.
>
>  If your u-boot supports the common boot distro spec in u-boot it
>  doesn't need parameters and will just auto boot.
>
>  > My understanding is that at this point we should only be running the
>  > initialisation script to set up a final image, so I'm not quite certain
>  > whether this approach is going to work beyond this stage anyway.
>
>  If we know of the device and it's supportable that is the case, if we
>  support the SoC and you have an appropriate dtb it might almost be
>  that easy.
>
>  > So some obvious questions are:
>  >
>  > 1) is my current approach plausible or is there a better way of doing
>  this?
>
>  Hard to say as the information you've given above it about the
>  equivalent of "my car won't start" to a mechanic without providing any
>  details of the make and model. We can probably fix it with some more
>  info :-)
>
>  Once you have booted it to u-boot and are at the u-boot prompt can you
>  run "version" and "printenv" and copy the entire contents including
>  any boot messages to a fpaste (http://fpaste.org/) and reply with the
>  link to the details.
>
>  Peter
>

[Peter Robinson]

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

[Andrew Wing]

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>

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(a)gmail.com&gt; 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
>

[Peter Robinson]

On Wed, Jun 17, 2015 at 5:57 PM, Andrew Wing <andrew.wing(a)bgch.co.uk&gt; 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

[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(a)gmail.com&gt; wrote:

>  On Wed, Jun 17, 2015 at 5:57 PM, Andrew Wing
> <andrew.wing(a)bgch.co.uk&gt;
>  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
>

[Andrew Wing]

Thanks Peter. It was the blob. With a shiny new device tree blob I am
booting into Fedora just fine.

Andrew

On 18 June 2015 at 12:00, Andrew Wing <andrew.wing(a)bgch.co.uk&gt; 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(a)gmail.com&gt; wrote:
>
> > On Wed, Jun 17, 2015 at 5:57 PM, Andrew Wing <andrew.wing(a)bgch.co.uk&gt;
> > 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
> >
>
>

[Peter Robinson]

On Fri, Jun 26, 2015 at 8:15 AM, Andrew Wing <andrew.wing(a)bgch.co.uk&gt; 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(a)bgch.co.uk&gt;
> 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(a)gmail.com&gt; wrote:
> >>
> >> On Wed, Jun 17, 2015 at 5:57 PM, Andrew Wing <andrew.wing(a)bgch.co.uk&gt;
> >> 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
> >
> >
>

[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(a)gmail.com&gt; 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