Major Refactor of the library

[slamont]

This pull request contains a major refactor of many functions. Some scripts may get broken because of it. I can't test them all.

There is a lot of added benefits and error handling that got added and I believe this PR to be a major improvement, but I would gladly take your comments.

I needed to use those scripts and thought I should put my contribution in.

[RobertCNelson]

Testing on BBB, iot 2016-10-16 image... one quick comment about rsync, one of the reasons i dropped the progress, while the MB transfered is accurate, the % is useless, but i wonder if a quick grep of "df -h" and just echo it to the broadcast would be good enough..

Copying: Current rootfs to /dev/mmcblk1p1
----------------------------------------
==> rsync: / -> /tmp/rootfs
----------------------------------------
        171.47M  98%    3.14MB/s    0:�0:52 (xfr#5941, ir-chk=1035/9388)

[RobertCNelson]

Yeap, I was afraid of that.. Flashing is complete, board/cpu has "halted" but, the power rails haven't been turned off.. So the eMMC is still powered, we found this was not 100% safe, when doing 1000 unit production runs.

-    #To properly shudown, /opt/scripts/boot/am335x_evm.sh is going to call halt:
 -    exec /sbin/init
 +    #Why is /sbin/init used ? This not halting the system at all.
 +    #exec /sbin/init
 +    exec /sbin/shutdown now

So the power rail is controlled by the tps65217, and sadly, only systemd knows how to correctly power if off...

https://github.com/systemd/systemd/blob/master/src/login/70-power-switch.rules#L13

non-systemd/acpid sorta works, but it's hit and miss...

So when the flasher script ends, the device will start bootup, but this init script will detect what happend and call the proper shutdown..

https://github.com/RobertCNelson/boot-scripts/blob/master/boot/generic-startup.sh#L1-L10

I know it's very strange, a better option would be to just call shutdown from the flashing script, but we haven't found a way to tell the tps65217 to power of the rails..

Regards,

[slamont]

About the rsync progress, it is true that the % is completely broken :) I though that at least it would give a "I'm still working" info to the user instead of not showing anything.

I realize that one of the use case of these script is to replace init on the flasher image. I forgot about that, I was always fully booted on the sdcard when I tested.

I'll change the shutdown to put init back.

[RobertCNelson]

you know, if we just grep /proc/cmdline, we tell quickly if we are running as normal user or single user flashing mode.. then do either shutdown prodcedure..

[slamont]

I like the idea of reading the cmdline from /proc, I'll look into it. I'll try to fix the rsync too.

[RobertCNelson]

@slamont so close, one regression:

2016-10-16: jessie: iot: Good 2016-10-16: wheezy: machinekit: Good 2016-05-13: jessie: lxqt: Good

2015-11-12: wheezy: lxqt (last dual partition) Fails..

Preparing drives

----------------------------------------
==> Erasing: /dev/mmcblk1
----------------------------------------
108+0 records in
108+0 records out
113246208 bytes (113 MB) copied, 11.1093 s, 10.2 MB/s
----------------------------------------
108+0 records in
108+0 records out
113246208 bytes (113 MB) copied, 3.24182 s, 34.9 MB/s
----------------------------------------
==> Erasing: /dev/mmcblk1 complete
----------------------------------------

!==> Could not find /boot/SOC.sh, no defaults are loaded

----------------------------------------

================================================================================
Writing bootloader to [/dev/mmcblk1]
----------------------------------------
==> Figuring out options for SPL U-Boot copy ...
===> Will use : 
==> Figuring out options for U-Boot copy ...
===> Will use : 
==> Copying SPL U-Boot with dd if= of=/dev/mmcblk1 
------------------------------------------------------------
dd: opening `': No such file or directory
Traceback (last called is first):
     _dd_bootloader() in /opt/scripts/tools/eMMC/functions.sh:541
     prepare_drive() in /opt/scripts/tools/eMMC/functions.sh:957
     main() in /opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh:40
The command dd if=${dd_spl_uboot_backup} of=${destination} ${dd_spl_uboot} exited with exit code 1.
================================================================================
Tearing Down script environment
==> Unmounting /tmp
==> Unmounting /boot
==> Stopping Cylon LEDs ...
==> Setting LEDs to none
==> Force writeback of eMMC buffers by Syncing: /dev/mmcblk1
/opt/scripts/tools/eMMC/functions.sh: line 150:   288 Terminated              cylon_leds
----------------------------------------
100000+0 records in
100000+0 records out
51200000 bytes (51 MB) copied, 1.47232 s, 34.8 MB/s
----------------------------------------
===> Syncing: /dev/mmcblk1 complete
==> This script took 32 seconds to run
================================================================================
==> Setting LEDs to default-on
[   37.000239] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[   37.000239] 
[   37.014518] [<c00114f1>] (unwind_backtrace+0x1/0x9c) from [<c04d0add>] (panic+0x59/0x15c)
[   37.025486] [<c04d0add>] (panic+0x59/0x15c) from [<c0033a8f>] (do_exit+0x5ff/0x68c)
[   37.035885] [<c0033a8f>] (do_exit+0x5ff/0x68c) from [<c0033b5f>] (do_group_exit+0x27/0x6c)
[   37.046918] [<c0033b5f>] (do_group_exit+0x27/0x6c) from [<c0033baf>] (sys_exit_group+0xb/0xc)
[   37.058215] [<c0033baf>] (sys_exit_group+0xb/0xc) from [<c000c841>] (ret_fast_syscall+0x1/0x46)
[   37.069710] drm_kms_helper: panic occurred, switching back to text console

/boot/SOC.sh is found on the rootfs, 2nd partition in this case..

cat /media/voodoo/rootfs/boot/SOC.sh 
#!/bin/sh
format=1.0

board=am335x_evm

bootloader_location=dd_spl_uboot_boot
bootrom_gpt=

dd_spl_uboot_count=1
dd_spl_uboot_seek=1
dd_spl_uboot_conf=notrunc
dd_spl_uboot_bs=128k
dd_spl_uboot_backup=/opt/backup/uboot/MLO

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

boot_fstype=fat
conf_boot_startmb=1
conf_boot_endmb=96
sfdisk_fstype=0xE

boot_label=BEAGLEBONE
rootfs_label=rootfs

#Kernel
dtb=
serial_tty=ttyO0
usbnet_mem=

Regards,

[RobertCNelson]

This looks why:

mmcblk0      179:0    0  14.9G  0 disk 
|-mmcblk0p1  179:1    0    96M  0 part /boot
`-mmcblk0p2  179:2    0   3.2G  0 part /

here's the change:

if [ ! "x${boot_drive}" = "x${root_drive}" ] ; then echo_broadcast "====> The Boot and Root drives are identified to be different." echo_broadcast "====> Mounting ${boot_drive} Read Only over /boot" mount ${boot_drive} /boot -o ro fi

this "needs" to be "mount ${boot_drive} /boot/uboot -o ro" on dual partition systems.

https://github.com/slamont/boot-scripts/blob/master/tools/eMMC/functions.sh#L123

Regards,

[RobertCNelson]

I've got the regression fixed up locall, just running another eMMC run, then i'll pull and commit the 4 line fix. ;)

[slamont]

Good, I'm curious to see the fix :) But I'm not quite sure I understand what is going with the boot partition.

When we start, shouldn't part1 /boot replace part2 /boot when mounted over it in a dual partitions setup? Also, I guess we need to put uEnv.txt in part1 /boot if we want to be able to boot from u-boot using this partition.

The current situation seems to be that u-boot will boot from part2 even with /boot on part1 :-/

It's getting me a little confuse there

[RobertCNelson]

and the fix is here: https://github.com/RobertCNelson/boot-scripts/commit/7eaee2ccd514b41e0e1193e6d2faf19e8d587711

Think of /boot/uboot/ as a minimized /boot/*, in the normal debian world, the size of /boot/ can get big (bigger then the 12/64/96MB sizes we've spec'ed in the past) in the normal day-to-day kernel upgrades..

In our case, when you install a linux-image-*.deb, we have a postinstall script to manually update the files under /boot/uboot/ when present:

https://github.com/rcn-ee/repos/blob/master/bb-bb-customizations/suite/jessie/debian/zz-uenv_txt

Regards,

[slamont]

Thank you for explaining !