On Mon, Sep 11, 2017 at 4:25 PM, William A. Mills <wm.a.mi...@gmail.com> wrote: > 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??)
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-rou...@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/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYjFgGU_Bc5zGsN%2B0OzkkTBanptiOt8d9PGsHqa%2BBjNFMA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
