I tried replacing u-boot with mainline... it didn't go well.

[CptSpaceToaster]

Hello there!

I apologize in advance for the wall of text.

Quick :+1: I was running through these wonderful buildscripts, and I am impressed with everything. I'm building for a cubietruck, and the whole system worked out of the box just great!

Context I was interested in compiling from mainline u-boot. I saw that most of the required changes from sunxi's u-boot branch were merged into denx's, however I ran into quite a few troubles, and I'm hoping to get a few pointers on how to continue.

I have sunxi's u-boot branch still in my working directory (this repo), and I additionally pulled denx's u-boot tree (somewhere outside of this repo), and configured for a cubietruck. Using the arm-linux-gnueabihf compiler served to me from apt-get (Ubuntu 12.04) I successfully cross compiled and obtained the u-boot-sunxi-with-spl.bin binary.

I then built the cubieboard's image twice. First, I ran make $BOARD.img with no modifications (I'm referring to this as mirage's image). Then, I replaced the u-boot-sunxi/build-cubietruck/u-boot-sunxi-with-spl.bin with the one I compiled myself, and reran make $BOARD.img to obtain a second image. (referring to this as the mainline image, as it contains u-boot compiled from mainline)

Here's one issue I was able to fix myself: Oddly enough, u-boot starts fine in both cases, but bdinfo reports minor differences Mirage's

sun7i# bdinfo
arch_number = 0x100010BB
boot_params = 0x40000100
DRAM bank   = 0x00000000
-> start    = 0x40000000
-> size     = 0x80000000
eth0name    = dwmac.1c50000
ethaddr     = 02:8b:08:82:f6:3e
current eth = dwmac.1c50000
ip_addr     = <NULL>
baudrate    = 115200 bps
TLB addr    = 0xBF6F0000
relocaddr   = 0xBF64E000
reloc off   = 0x7564E000
irq_sp      = 0xBF22DEF0
sp start    = 0xBF22DEE0
FB base     = 0xBFD00000

Mainline U-boot

sun7i# bdinfo
arch_number = 0x000010BB
boot_params = 0x40000100
DRAM bank   = 0x00000000
-> start    = 0x40000000
-> size     = 0x80000000
eth0name    = dwmac.1c50000
ethaddr     = 02:8b:08:82:f6:3e
current eth = dwmac.1c50000
ip_addr     = <NULL>
baudrate    = 115200 bps
TLB addr    = 0xBFFF0000
relocaddr   = 0xBFF84000
reloc off   = 0x75F84000
irq_sp      = 0xBFB63EF0
sp start    = 0xBFB63EE0

Notice the FB base is completely gone, and some of the values at the end are different.

In Mainline u-boot, the linux-kernel conflicts with u-boot's relocation address (relocaddr). I had to modify the kernel's load address in boot/boot-cubietruck.cmd to a lower value in order to load the kernel successfully. (It otherwise, would attempt to overwrite u-boot while it was running I think)

So, not a terrible issue, but quite annoying to find and debug. Why are these different?

The second issue (The real reason I'm here) The mainline image appears to be partitioned incorrectly, and I can't figure out why that's the case. Is the build.sh not capable of handeling my new binary somehow? That's the ONLY thing I tried to change.

First off, some diagnostic:

# mirage's
$ ls -lh u-boot-sunxi/build-cubietruck/u-boot-sunxi-with-spl.bin 
-rw-rw-r-- 1 usr grp 274K Apr 29 13:01 u-boot-sunxi/build-cubietruck/u-boot-sunxi-with-spl.bin

# mainline
$ ls -lh ../u-boot-truck/u-boot-sunxi-with-spl.bin 
-rw-rw-r-- 1 usr grp 403K Apr 28 16:23 ../u-boot-truck/u-boot-sunxi-with-spl.bin

Note, the mainline u-boot image is significantly larger in filesize.

now, the partitioning schemes:

# with mirage's vanilla image dd'd onto my sd card
$ lsblk
-snip-
sdc                         8:32   1  29.7G  0 disk 
├─sdc1                      8:33   1   128M  0 part /media/usb0
├─sdc2                      8:34   1     3G  0 part /media/usb1
└─sdc3                      8:35   1  26.6G  0 part 
#sdc3 doesn't show up until I boot successfully

# with the mainline image dd'd onto my sd card
$ lsblk
-snip-
sdc                         8:32   1  29.7G  0 disk 
├─sdc1                      8:33   1   128M  0 part /media/usb0
└─sdc2                      8:34   1   1.9G  0 part 
# The second partition isn't picked up by the auto-mount utility.  
# I think I need to debug that further

All that to say, when I actually boot, and the kernel is moved to a location that doesn't cause u-boot to hang......... I get a kernel panic as the system can't mount the root filesystem.

What might be some good next steps? I'm almost certain it's an issue with the second partition somehow, but I don't know how to continue.

log: https://gist.github.com/CptSpaceToaster/002097e6f778b3bf3f9f

Have a nice day :)

[talex5]

Note that the templates/init.d/1st-boot script expands sdc2 and adds the LVM partition on first boot.

[CptSpaceToaster]

Something is going wrong previous to that step.

Before the init.d script has a chance to run, the sdc2 partition is detected by auto-mount. From memory, it looks something a bit like this.

# with mirage's vanilla image dd'd onto my sd card
$ lsblk
-snip-
sdc                         8:32   1  29.7G  0 disk 
├─sdc1                      8:33   1   128M  0 part /media/usb0
└─sdc2                      8:34   1   1.9G  0 part /media/usb1

This doesn't occur on the image that used my self-compiled u-boot.

I haven't had a chance to sit down and figure out what's going wrong with the block devices and partitioning/formatting schemes. Just to be clear, when I made my change, the kernel panic occurs because it can't reach the second partition. So the issue lives around here.

[talex5]

U-Boot got upgraded in #58, so closing this. Please open a new issue if there are still problems with partitions.