Silly trouble booting the 3.12 kernel due to DTB not being recognized

Robert,

I'm starting with the kernel at
http://github.com/beagleboard/kernel/tree/3.12. I've pushed a patched
version of the tree to http://github.com/beagleboard/linux/tree/3.12.

To build the kernel, I'm using buildroot via
http://github.com/jadonk/buildroot/tree/latest.

make beaglebone_config
make

I'm booting the MLO and u-boot.img that are in the buildroot
output/images. I then try the following:

U-Boot SPL 2013.07 (Oct 30 2013 - 09:44:19)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
reading args
spl: error reading image args, err - -1
reading u-boot.img
reading u-boot.img

U-Boot 2013.07 (Oct 30 2013 - 09:44:19)

I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 0
U-Boot#
U-Boot# run findfdt
U-Boot# setenv bootargs console=${console}
U-Boot# load mmc 0 0x80007fc0 uImage
reading uImage
34759872 bytes read in 3941 ms (8.4 MiB/s)
U-Boot# load mmc 0 0x82ff8000 ${fdtfile}
reading am335x-boneblack.dtb
18465 bytes read in 9 ms (2 MiB/s)
U-Boot# bootm 0x80007fc0 - 0x82ff8000
## Booting kernel from Legacy Image at 80007fc0 ...
   Image Name: Linux-3.12.0
   Image Type: ARM Linux Kernel Image (uncompressed)
   Data Size: 34759808 Bytes = 33.1 MiB
   Load Address: 80008000
   Entry Point: 80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 82ff8000
   Booting using the fdt blob at 0x82ff8000
   XIP Kernel Image ... OK
   Using Device Tree in place at 82ff8000, end 82fff820

Starting kernel ...

Error: unrecognized/unsupported machine ID (r1 = 0x00000e05).

Available machine support:

ID (hex) NAME
ffffffff Generic DT based system
ffffffff Generic OMAP4 (Flattened Device Tree)
ffffffff Generic AM33XX (Flattened Device Tree)
ffffffff Generic OMAP3-GP (Flattened Device Tree)
ffffffff Generic OMAP36xx (Flattened Device Tree)
ffffffff Generic OMAP3 (Flattened Device Tree)
0000060a OMAP3 Beagle Board
00000a9d IGEP OMAP3 module
00000928 IGEP v2 board

Any idea why my .dtb isn't getting picked up?

Robert,

I'm starting with the kernel at
http://github.com/beagleboard/kernel/tree/3.12. I've pushed a patched
version of the tree to http://github.com/beagleboard/linux/tree/3.12.

To build the kernel, I'm using buildroot via
http://github.com/jadonk/buildroot/tree/latest.

make beaglebone_config
make

I'm booting the MLO and u-boot.img that are in the buildroot
output/images. I then try the following:

U-Boot SPL 2013.07 (Oct 30 2013 - 09:44:19)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
reading args
spl: error reading image args, err - -1
reading u-boot.img
reading u-boot.img

U-Boot 2013.07 (Oct 30 2013 - 09:44:19)

I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 0
U-Boot#
U-Boot# run findfdt
U-Boot# setenv bootargs console=${console}
U-Boot# load mmc 0 0x80007fc0 uImage
reading uImage
34759872 bytes read in 3941 ms (8.4 MiB/s)
U-Boot# load mmc 0 0x82ff8000 ${fdtfile}
reading am335x-boneblack.dtb
18465 bytes read in 9 ms (2 MiB/s)
U-Boot# bootm 0x80007fc0 - 0x82ff8000

Hum, I actually haven't tested "bootm" in some time, I'll test it right now...

Here's what i'm seeing with "bootz 0x80200000
0x81000000:${initrd_size} 0x815f0000" (intrd is basically ignored as
it's 3.8.x based..)

http://pastebin.com/LdiemVK3

## Booting kernel from Legacy Image at 80007fc0 ...
   Image Name: Linux-3.12.0
   Image Type: ARM Linux Kernel Image (uncompressed)
   Data Size: 34759808 Bytes = 33.1 MiB
   Load Address: 80008000
   Entry Point: 80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 82ff8000
   Booting using the fdt blob at 0x82ff8000
   XIP Kernel Image ... OK
   Using Device Tree in place at 82ff8000, end 82fff820

Starting kernel ...

Error: unrecognized/unsupported machine ID (r1 = 0x00000e05).

Available machine support:

ID (hex) NAME
ffffffff Generic DT based system
ffffffff Generic OMAP4 (Flattened Device Tree)
ffffffff Generic AM33XX (Flattened Device Tree)
ffffffff Generic OMAP3-GP (Flattened Device Tree)
ffffffff Generic OMAP36xx (Flattened Device Tree)
ffffffff Generic OMAP3 (Flattened Device Tree)
0000060a OMAP3 Beagle Board
00000a9d IGEP OMAP3 module
00000928 IGEP v2 board

Any idea why my .dtb isn't getting picked up?

Regards,

Nope, not that simple..
http://pastebin.com/Ca47zQLE

Let me clone that branch, can you share your execution of make commands...

Regards,

Ah i see now, buildroot.. this may take a bit, 100k bandwidth here.. :wink:

Regards,

Robert,

I'm starting with the kernel at
http://github.com/beagleboard/kernel/tree/3.12. I've pushed a patched
version of the tree to http://github.com/beagleboard/linux/tree/3.12.

To build the kernel, I'm using buildroot via
http://github.com/jadonk/buildroot/tree/latest.

make beaglebone_config
make

I'm booting the MLO and u-boot.img that are in the buildroot
output/images. I then try the following:

U-Boot SPL 2013.07 (Oct 30 2013 - 09:44:19)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
reading args
spl: error reading image args, err - -1
reading u-boot.img
reading u-boot.img

U-Boot 2013.07 (Oct 30 2013 - 09:44:19)

I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 0
U-Boot#
U-Boot# run findfdt
U-Boot# setenv bootargs console=${console}
U-Boot# load mmc 0 0x80007fc0 uImage
reading uImage
34759872 bytes read in 3941 ms (8.4 MiB/s)
U-Boot# load mmc 0 0x82ff8000 ${fdtfile}
reading am335x-boneblack.dtb
18465 bytes read in 9 ms (2 MiB/s)
U-Boot# bootm 0x80007fc0 - 0x82ff8000

Hum, I actually haven't tested "bootm" in some time, I'll test it right now...

Here's what i'm seeing with "bootz 0x80200000
0x81000000:${initrd_size} 0x815f0000" (intrd is basically ignored as
it's 3.8.x based..)

What's the reasoning behind moving to bootz? I'm just looking for
something that is simple and works. I can see some advantage to
skipping the mkimage step, but if the build infrastructure is already
there, why should I go to an extra step to remove it and break some
compatibility with existing scripts, etc.?

bootz/zImage is easier for multi-arch, plus you never have to remember
the mkimage syntax or address. (Luckly TI has for the most part always
used 0x80008000) Some 'other' vendors like to change the address
randomly..

Anywho, it looks to not be a uImage/zImage issue.. I'm just waiting
for buildroot to finish..

Regards,

Weird, it works for me..

git clone https://github.com/jadonk/buildroot.git buildroot-jadonk
cd buildroot-jadonk/
git checkout origin/latest -b latest
make beaglebone_defconfig
make

http://pastebin.com/mLu6Ak5A

maybe it's the load address of 0x80007fc0???

Regards,

Robert,

I'm starting with the kernel at
http://github.com/beagleboard/kernel/tree/3.12. I've pushed a patched
version of the tree to http://github.com/beagleboard/linux/tree/3.12.

To build the kernel, I'm using buildroot via
http://github.com/jadonk/buildroot/tree/latest.

make beaglebone_config
make

I'm booting the MLO and u-boot.img that are in the buildroot
output/images. I then try the following:

U-Boot SPL 2013.07 (Oct 30 2013 - 09:44:19)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
reading args
spl: error reading image args, err - -1
reading u-boot.img
reading u-boot.img

U-Boot 2013.07 (Oct 30 2013 - 09:44:19)

I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 0
U-Boot#
U-Boot# run findfdt
U-Boot# setenv bootargs console=${console}
U-Boot# load mmc 0 0x80007fc0 uImage
reading uImage
34759872 bytes read in 3941 ms (8.4 MiB/s)
U-Boot# load mmc 0 0x82ff8000 ${fdtfile}
reading am335x-boneblack.dtb
18465 bytes read in 9 ms (2 MiB/s)
U-Boot# bootm 0x80007fc0 - 0x82ff8000

Hum, I actually haven't tested "bootm" in some time, I'll test it right now...

Here's what i'm seeing with "bootz 0x80200000
0x81000000:${initrd_size} 0x815f0000" (intrd is basically ignored as
it's 3.8.x based..)

What's the reasoning behind moving to bootz? I'm just looking for
something that is simple and works. I can see some advantage to
skipping the mkimage step, but if the build infrastructure is already
there, why should I go to an extra step to remove it and break some
compatibility with existing scripts, etc.?

bootz/zImage is easier for multi-arch, plus you never have to remember
the mkimage syntax or address. (Luckly TI has for the most part always
used 0x80008000) Some 'other' vendors like to change the address
randomly..

Anywho, it looks to not be a uImage/zImage issue.. I'm just waiting
for buildroot to finish..

Weird, it works for me..

git clone https://github.com/jadonk/buildroot.git buildroot-jadonk
cd buildroot-jadonk/
git checkout origin/latest -b latest
make beaglebone_defconfig
make

http://pastebin.com/mLu6Ak5A

maybe it's the load address of 0x80007fc0???

Interesting. I tried 0x82000000 as a the load address. I'll take a
look at your pastebin for more ideas.

BTW, I posted a build here:
http://beagle.s3.amazonaws.com/buildroot/2013-11-06-19:49:50/index.html

Nah it's the fdtaddress, for some reason "0x82ff8000" is getting
overwritten by the uImage... (22.6MB in size)

This works fine:

run findfdt
setenv bootargs console=${console}
load mmc 0 0x80007fc0 uImage
load mmc 0 0x87ff0000 ${fdtfile}
bootm 0x80007fc0 - 0x87ff0000

But using this might be better long term..

run findfdt
setenv bootargs console=${console}
load mmc 0 ${loadaddr} uImage
load mmc 0 ${fdtaddr} ${fdtfile}
bootm ${loadaddr} - ${fdtaddr}

Regards,

Robert,

I'm starting with the kernel at
http://github.com/beagleboard/kernel/tree/3.12. I've pushed a patched
version of the tree to http://github.com/beagleboard/linux/tree/3.12.

To build the kernel, I'm using buildroot via
http://github.com/jadonk/buildroot/tree/latest.

make beaglebone_config
make

I'm booting the MLO and u-boot.img that are in the buildroot
output/images. I then try the following:

U-Boot SPL 2013.07 (Oct 30 2013 - 09:44:19)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
reading args
spl: error reading image args, err - -1
reading u-boot.img
reading u-boot.img

U-Boot 2013.07 (Oct 30 2013 - 09:44:19)

I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 0
U-Boot#
U-Boot# run findfdt
U-Boot# setenv bootargs console=${console}
U-Boot# load mmc 0 0x80007fc0 uImage
reading uImage
34759872 bytes read in 3941 ms (8.4 MiB/s)
U-Boot# load mmc 0 0x82ff8000 ${fdtfile}
reading am335x-boneblack.dtb
18465 bytes read in 9 ms (2 MiB/s)
U-Boot# bootm 0x80007fc0 - 0x82ff8000

Hum, I actually haven't tested "bootm" in some time, I'll test it right now...

Here's what i'm seeing with "bootz 0x80200000
0x81000000:${initrd_size} 0x815f0000" (intrd is basically ignored as
it's 3.8.x based..)

What's the reasoning behind moving to bootz? I'm just looking for
something that is simple and works. I can see some advantage to
skipping the mkimage step, but if the build infrastructure is already
there, why should I go to an extra step to remove it and break some
compatibility with existing scripts, etc.?

bootz/zImage is easier for multi-arch, plus you never have to remember
the mkimage syntax or address. (Luckly TI has for the most part always
used 0x80008000) Some 'other' vendors like to change the address
randomly..

Anywho, it looks to not be a uImage/zImage issue.. I'm just waiting
for buildroot to finish..

Weird, it works for me..

git clone https://github.com/jadonk/buildroot.git buildroot-jadonk
cd buildroot-jadonk/
git checkout origin/latest -b latest
make beaglebone_defconfig
make

http://pastebin.com/mLu6Ak5A

maybe it's the load address of 0x80007fc0???

Interesting. I tried 0x82000000 as a the load address. I'll take a
look at your pastebin for more ideas.

BTW, I posted a build here:
http://beagle.s3.amazonaws.com/buildroot/2013-11-06-19:49:50/index.html

Ugh. Nevermind. I didn't read my build.log. 's3cmd' isn't reliable and
didn't copy the built uImage. :frowning:

Robert,

I'm starting with the kernel at
http://github.com/beagleboard/kernel/tree/3.12. I've pushed a patched
version of the tree to http://github.com/beagleboard/linux/tree/3.12.

To build the kernel, I'm using buildroot via
http://github.com/jadonk/buildroot/tree/latest.

make beaglebone_config
make

I'm booting the MLO and u-boot.img that are in the buildroot
output/images. I then try the following:

U-Boot SPL 2013.07 (Oct 30 2013 - 09:44:19)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
reading args
spl: error reading image args, err - -1
reading u-boot.img
reading u-boot.img

U-Boot 2013.07 (Oct 30 2013 - 09:44:19)

I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 0
U-Boot#
U-Boot# run findfdt
U-Boot# setenv bootargs console=${console}
U-Boot# load mmc 0 0x80007fc0 uImage
reading uImage
34759872 bytes read in 3941 ms (8.4 MiB/s)
U-Boot# load mmc 0 0x82ff8000 ${fdtfile}
reading am335x-boneblack.dtb
18465 bytes read in 9 ms (2 MiB/s)
U-Boot# bootm 0x80007fc0 - 0x82ff8000

Hum, I actually haven't tested "bootm" in some time, I'll test it right now...

Here's what i'm seeing with "bootz 0x80200000
0x81000000:${initrd_size} 0x815f0000" (intrd is basically ignored as
it's 3.8.x based..)

What's the reasoning behind moving to bootz? I'm just looking for
something that is simple and works. I can see some advantage to
skipping the mkimage step, but if the build infrastructure is already
there, why should I go to an extra step to remove it and break some
compatibility with existing scripts, etc.?

bootz/zImage is easier for multi-arch, plus you never have to remember
the mkimage syntax or address. (Luckly TI has for the most part always
used 0x80008000) Some 'other' vendors like to change the address
randomly..

Anywho, it looks to not be a uImage/zImage issue.. I'm just waiting
for buildroot to finish..

Weird, it works for me..

git clone https://github.com/jadonk/buildroot.git buildroot-jadonk
cd buildroot-jadonk/
git checkout origin/latest -b latest
make beaglebone_defconfig
make

http://pastebin.com/mLu6Ak5A

maybe it's the load address of 0x80007fc0???

Nah it's the fdtaddress, for some reason "0x82ff8000" is getting
overwritten by the uImage... (22.6MB in size)

This works fine:

run findfdt
setenv bootargs console=${console}
load mmc 0 0x80007fc0 uImage
load mmc 0 0x87ff0000 ${fdtfile}
bootm 0x80007fc0 - 0x87ff0000

Yup, worked for me too. Must have simply not been providing enough
space before the fdt?

But using this might be better long term..

run findfdt
setenv bootargs console=${console}
load mmc 0 ${loadaddr} uImage
load mmc 0 ${fdtaddr} ${fdtfile}
bootm ${loadaddr} - ${fdtaddr}

not ${kloadaddr}?

Is ${fdtaddr} really far enough away?

Nah it's the fdtaddress, for some reason "0x82ff8000" is getting
overwritten by the uImage... (22.6MB in size)

This works fine:

run findfdt
setenv bootargs console=${console}
load mmc 0 0x80007fc0 uImage
load mmc 0 0x87ff0000 ${fdtfile}
bootm 0x80007fc0 - 0x87ff0000

Yup, worked for me too. Must have simply not been providing enough
space before the fdt?

But using this might be better long term..

run findfdt
setenv bootargs console=${console}
load mmc 0 ${loadaddr} uImage
load mmc 0 ${fdtaddr} ${fdtfile}
bootm ${loadaddr} - ${fdtaddr}

not ${kloadaddr}?

Environment size: 3870/131068 bytes
U-Boot# echo ${kloadaddr}

U-Boot# echo ${loadaddr}
0x80200000
U-Boot#

That doesn't exist...

loadaddr is used by default in loaduimage

loaduimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}

Is ${fdtaddr} really far enough away?

I think by spec it's either a max of 64Mb or 128Mb away, or the end of
the RAM segment??? Can't find the document at the moment.

Regards,

Nah it's the fdtaddress, for some reason "0x82ff8000" is getting
overwritten by the uImage... (22.6MB in size)

This works fine:

run findfdt
setenv bootargs console=${console}
load mmc 0 0x80007fc0 uImage
load mmc 0 0x87ff0000 ${fdtfile}
bootm 0x80007fc0 - 0x87ff0000

Yup, worked for me too. Must have simply not been providing enough
space before the fdt?

But using this might be better long term..

run findfdt
setenv bootargs console=${console}
load mmc 0 ${loadaddr} uImage
load mmc 0 ${fdtaddr} ${fdtfile}
bootm ${loadaddr} - ${fdtaddr}

not ${kloadaddr}?

Environment size: 3870/131068 bytes
U-Boot# echo ${kloadaddr}

U-Boot# echo ${loadaddr}
0x80200000
U-Boot#

That doesn't exist...

loadaddr is used by default in loaduimage

loaduimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}

k, I see that is the way it is in mainline and that kloadaddr was
something in the Angstrom patches not pushed upstream. I'll think
about if that needs to be pushed upstream.

Is ${fdtaddr} really far enough away?

I think by spec it's either a max of 64Mb or 128Mb away, or the end of
the RAM segment??? Can't find the document at the moment.

K, I see this u-boot has it pretty darn far up out of the way in the
mainline code.

BTW, if anyone does want a link to my build, it is at:
http://beagle.s3.amazonaws.com/buildroot/2013-11-06-21:33:56/index.html

There are a few bugs I need to fix right away. This version builds
with a version of 'node' that doesn't work due to specification of the
floating point mechanism. Also, the .dtbo files don't get built/copied
into /lib/firmware.

uEnv.txt contents below seem to work nicely:
uenvcmd=i2c mw 0x24 1 0x3e;run findfdt;setenv bootargs
console=${console};load mmc 0 0x80007fc0 uImage;load mmc 0 ${fdtaddr}
${fdtfile};bootm 0x80007fc0 - ${fdtaddr}