X15 SOC.sh truncates u-boot.img??

[William A. Mills]

Hi,

I have BB-X15 RevC with jessie image

/ID.txt:
BeagleBoard.org Debian Image 2017-07-02

debian@BeagleBoard-X15:~$ ls -lh /opt/backup/uboot/u-boot.img
-rw-r--r-- 1 root root 1018K Jul  2 23:44 /opt/backup/uboot/u-boot.img

debian@BeagleBoard-X15:~$ cat /boot/SOC.sh
#!/bin/sh
format=1.0

[..snip..]

dd_uboot_count=2
dd_uboot_seek=1
dd_uboot_conf=notrunc
dd_uboot_bs=384k
dd_uboot_backup=/opt/backup/uboot/u-boot.img

[..snip..]

384k*2=768k

1018K > 768K :(

# save a copy of current u-boot.img from reserved space into home dir

debian@BeagleBoard-X15:~$ sudo dd if=/dev/mmcblk1 of=u-boot.img bs=384k skip=1 count=3
3+0 records in
3+0 records out
1179648 bytes (1.2 MB, 1.1 MiB) copied, 0.0122472 s, 96.3 MB/s

# compare to one in backup dir

debian@BeagleBoard-X15:~$ cmp /opt/backup/uboot/u-boot.img u-boot.img
/opt/backup/uboot/u-boot.img u-boot.img differ: byte 786436, line 3827

786436/1024=768K + 4 bytes

I know my saved images are longer than the actual files, but if this were working correctly I would get EOF on the /opt/backup file.  This is what happens when I compare MLO.

debian@BeagleBoard-X15:~$ sudo dd if=/dev/mmcblk1 of=MLO bs=128k skip=1 count=1
1+0 records in
1+0 records out
131072 bytes (131 kB, 128 KiB) copied, 0.00761566 s, 17.2 MB/s

debian@BeagleBoard-X15:~$ cmp /opt/backup/uboot/MLO MLO
cmp: EOF on /opt/backup/uboot/MLO

# Looking at ~/u-boot.img

debian@BeagleBoard-X15:~$ hd u-boot.img | tail
000bff90  00 00 00 04 00 00 01 20  00 00 00 3d 00 00 00 02  |....... ...=....|
000bffa0  00 00 00 01 61 74 6c 5f  63 6c 6b 69 6e 31 5f 63  |....atl_clkin1_c|
000bffb0  6b 00 00 00 00 00 00 03  00 00 00 04 00 00 02 30  |k..............0|
000bffc0  00 00 00 00 00 00 00 03  00 00 00 12 00 00 00 1b  |................|
000bffd0  74 69 2c 64 72 61 37 2d  61 74 6c 2d 63 6c 6f 63  |ti,dra7-atl-cloc|
000bffe0  6b 00 00 00 00 00 00 03  00 00 00 04 00 00 01 45  |k..............E|
000bfff0  00 00 00 0d 00 00 00 03  00 00 00 04 00 00 01 1a  |................|
000c0000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00120000

# the image is all zeros at 0x000C_0000 and beyond.

# 0x000C_0000 == 768K

** Conclusion (so far)

in SOC.h dd_uboot_count should be 3 (or even 4; what is it going to hurt?)

It does appear the images have used this too small count to write the u-boot.img

It works anyway (really??)

Bill

[Robert Nelson]

Nice William!

Well, "it works" but "doesn't"...

So yeah, "u-boot.img" has gotten fatter over the last few months.. The
Device Tree Binaries get appended to u-boot.img, luckly we really
don't use them, as we just grab the kernel version.. But now i see
why we were having problem with the Rev A3, as that's one of the last
blob's:

0011EA80 61 37 34 00 74 69 2C 64 72 61 37 00 00 00 00 03 00 00
00 04 00 00 00 26 00 00 00 01 00 00 00 03
a74.ti,dra7............&........
0011EAA0 00 00 00 15 00 00 00 37 54 49 20 41 4D 35 37 32 78 20
45 56 4D 20 52 65 76 20 41 33 00 00 00 00 .......7TI AM572x EVM
Rev A3....
0011EAC0 00 00 00 01 61 6C 69 61 73 65 73 00 00 00 00 03 00 00
00 12 00 00 00 3D 2F 6F 63 70 2F 69 32 63
....aliases............=/ocp/i2c
0011EAE0 40 34 38 30 37 30 30 30 30 00 00 00 00 00 00 03 00 00
00 12 00 00 00 42 2F 6F 63 70 2F 69 32 63
@48070000..............B/ocp/i2c
<snip>
0011FF80 64 6D 61 2D 72 6F 75 74 65 72 40 62 37 38 00 00 00 00
00 03 00 00 00 15 00 00 00 1B 74 69 2C 64
dma-router@b78..............ti,d
0011FFA0 72 61 37 2D 64 6D 61 2D 63 72 6F 73 73 62 61 72 00 00
00 00 00 00 00 03 00 00 00 08 00 00 01 16
ra7-dma-crossbar................
0011FFC0 00 00 0B 78 00 00 00 FC 00 00 00 03 00 00 00 04 00 00
02 99 00 00 00 01 00 00 00 03 00 00 00 04
...x............................
0011FFE0 00 00 02 A4 00 00 00 CD 00 00 00 03 00 00 00 04 00 00
02 B1 00 00 00 00 00 00 00 03 00 00 00 04
................................
00120000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00

................................

that perfectly explains this issue i was having:

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/ti-2017.01/0001-beagle_x15-uEnv.txt-bootz-n-fixes.patch#L980-L982

So yes, we need to bump the size, we've been specifying a 4MB hole for
over a year now... Actually in anticipation of this exact issue, but
on the Bone..

sudo dd if=./u-boot/MLO of=${DISK} count=1 seek=1 bs=128k
sudo dd if=./u-boot/u-boot.img of=${DISK} count=2 seek=1 bs=384k

-rw-r--r-- 1 voodoo voodoo 730K Jan 23 2017
u-boot-am57xx_evm_ti-v2017.01-r1.img
-rw-r--r-- 1 voodoo voodoo 841K Feb 16 2017
u-boot-am57xx_evm_ti-v2017.01-r2.img
-rw-r--r-- 1 voodoo voodoo 842K Apr 18 09:13
u-boot-am57xx_evm_ti-v2017.01-r6.img
-rw-r--r-- 1 voodoo voodoo 842K Feb 17 2017
u-boot-am57xx_evm_ti-v2017.01-r3.img
-rw-r--r-- 1 voodoo voodoo 842K Feb 28 2017
u-boot-am57xx_evm_ti-v2017.01-r4.img
-rw-r--r-- 1 voodoo voodoo 842K Mar 9 2017
u-boot-am57xx_evm_ti-v2017.01-r5.img
-rw-r--r-- 1 voodoo voodoo 843K May 3 13:59
u-boot-am57xx_evm_ti-v2017.01-r7.img
#added sndblock
-rw-r--r-- 1 voodoo voodoo 931K May 16 10:55
u-boot-am57xx_evm_ti-v2017.01-r8.img
-rw-r--r-- 1 voodoo voodoo 932K Jun 5 11:30
u-boot-am57xx_evm_ti-v2017.01-r9.img
-rw-r--r-- 1 voodoo voodoo 933K Jun 21 10:07
u-boot-am57xx_evm_ti-v2017.01-r10.img
#added revC
-rw-r--r-- 1 voodoo voodoo 1018K Aug 11 16:15
u-boot-am57xx_evm_ti-v2017.01-r13.img
-rw-r--r-- 1 voodoo voodoo 1018K Jul 6 17:11
u-boot-am57xx_evm_ti-v2017.01-r12.img
-rw-r--r-- 1 voodoo voodoo 1018K Jun 21 11:51
u-boot-am57xx_evm_ti-v2017.01-r11.img

So yeah, let's bump it to 4...

https://github.com/RobertCNelson/omap-image-builder/commit/404228dadbb185f9132dbb1ff3c9e75934491f98

Regards,

--
Robert Nelson
https://rcn-ee.com/

[William A. Mills]

Robert,

On Tue, Sep 12, 2017 at 5:05 PM, Robert Nelson <robert...@gmail.com> wrote:

On Mon, Sep 11, 2017 at 4:25 PM, William A. Mills <wm.a....@gmail.com> wrote:
> ** Conclusion (so far)
> in SOC.h dd_uboot_count should be 3 (or even 4; what is it going to hurt?)
> It does appear the images have used this too small count to write the
> u-boot.img
> It works anyway (really??)

Nice William!

Well, "it works" but "doesn't"...

So yeah, "u-boot.img" has gotten fatter over the last few months.. The
Device Tree Binaries get appended to u-boot.img, luckly we really
don't use them, as we just grab the kernel version..  But now i see
why we were having problem with the Rev A3, as that's one of the last
blob's:

Cool.  I wondered if it was extra dtbs that were getting cut off.

Thanks,

Bill