Hi all,
I performed the test as suggested with a much shorter ground wire instead of the longer one I was using. Here is a picture of the setup: <https://lh3.googleusercontent.com/-lW68r-YefYI/V4w9TVQhqoI/AAAAAAAAAL0/C_x6xweA39Q49c5eee6JiTqUQ7f09Z6hgCLcB/s1600/DSC_0535.JPG> Since then, I cannot reproduce the same magnitude of noise - this is the worst I could find: <https://lh3.googleusercontent.com/-8iDqIgiCNRY/V4w9imu588I/AAAAAAAAAL4/mFTMmZ8VB_0D9AaZsLwGijAV5UQXFTi0ACLcB/s1600/PSSupply%2B-%2BSYS5V%2B-%2B11-07-2016%2B1_51_34%2BPM.941.bmp> Thank you for pointing out the issue John - I hadn't realised the probes could pick up so much noise - this isn't a welding workshop.... So, I'm not sure whether the small spike shown would be enough to cause problems with the eMMC- the only power supply tolerance specification I could find was a small reference in the reference manual to requiring the input power to be 5VDC +/-.25V. However, the graph shown is actually for the regulated 5V on the board. Thanks, Joshua Collins On Friday, 1 July 2016 21:46:39 UTC+10, Joshua Collins wrote: > > Hi, > > So I'm working with a modified version of Robert Nelson's flasher script ( > https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/bbb-eMMC-flasher-eewiki-ext4.sh). > > I am flashing debian, but I'm having issues with corrupt results. > > The main differences are: > > - It does some things specific to my application, like performing a few > web requests. > - Instead of just creating one partition, it creates the root/boot > partition, and a second read-write partition. > > The partition table looks like this: > > Formatting: /dev/mmcblk1 > > Disk /dev/mmcblk1: 119808 cylinders, 4 heads, 16 sectors/track > Old situation: > New situation: > Units: 1MiB = 1024*1024 bytes, blocks of 1024 bytes, counting from 0 > > Device Boot Start End MiB #blocks Id System > /dev/mmcblk1p1 * 1 1500 1500 1536000 83 Linux > /dev/mmcblk1p2 1501 3743 2243 2296832 83 Linux > /dev/mmcblk1p3 0 - 0 0 0 Empty > /dev/mmcblk1p4 0 - 0 0 0 Empty > Successfully wrote the new partition table > > Re-reading the partition table ... > > - It was originally based on an older version of the script, however, some > parts have been updated. The EEPROM flashing for instance, has been > upgraded to the current version of RCN's script. > > > The program flow of dd_bootloader -> sfdisk -> format -> rsync is still > the same as in RCN's script. > > The problem: > Sometimes (only sometimes, and not with a predictable pattern that I can > discern), the flashing will fail and produce an unbootable image. > When the flasher will produce a corrupt image, errors in rsync's attempts > to copy over files to the root file system occur, just after the ext4 > filesystems for both partitions have been created. > > Here is an example: > Copying: /dev/mmcblk0p1 -> /dev/mmcblk1p1 > mount /dev/mmcblk1p1 /tmp/rootfs/ -o async,noatime > rsync: / -> /tmp/rootfs/ > [ 432.938083] EXT4-fs error (device mmcblk1p1): > ext4_mb_generate_buddy:757: group 0, block bitmap and bg descriptor > inconsistent: 32768 vs 23112 free clusters > [ 432.953982] EXT4-fs error (device mmcblk1p1): ext4_find_dest_de:1829: > inode #2: block 6119: comm rsync: bad entry in directory: rec_len is > smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0 > [ 432.984704] EXT4-fs error (device mmcblk1p1): ext4_find_dest_de:1829: > inode #2: block 6119: comm rsync: bad entry in directory: rec_len is > smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0 > [ 433.011220] EXT4-fs error (device mmcblk1p1): ext4_find_dest_de:1829: > inode #2: block 6119: comm rsync: bad entry in directory: rec_len is > smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0 > [ 433.041931] EXT4-fs error (device mmcblk1p1): ext4_find_dest_de:1829: > inode #2: block 6119: comm rsync: bad entry in directory: rec_len is > smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0 > [ 433.064714] EXT4-fs error (device mmcblk1p1): ext4_find_dest_de:1829: > inode #2: block 6119: comm rsync: bad entry in directory: rec_len is > smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0 > [ 433.087946] EXT4-fs error (device mmcblk1p1): ext4_find_dest_de:1829: > inode #2: block 6119: comm rsync: bad entry in directory: rec_len is > smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0 > [ 433.109954] EXT4-fs error (device mmcblk1p1): ext4_find_dest_de:1829: > inode #2: block 6119: comm rsync: bad entry in directory: rec_len is > smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0 > [ 433.131633] EXT4-fs error (device mmcblk1p1): ext4_find_dest_de:1829: > inode #2: block 6119: comm rsync: bad entry in directory: rec_len is > smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0 > [ 433.153583] EXT4-fs error (device mmcblk1p1): ext4_find_dest_de:1829: > inode #2: block 6119: comm rsync: bad entry in directory: rec_len is > smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0 > writing to [/dev/mmcblk1] failed... > > On boot after letting it finish* (write_failure/inf_loop doesn't behave as > expected), the following output occurs - U-Boot is unable to boot from the > root partition and starts resorting to desperate measures... > > U-Boot SPL 2015.04-dirty (Apr 14 2015 - 10:12:34) > U-Boot 2015.04-dirty (Apr 14 2015 - 10:12:34) > > Watchdog enabled > I2C: ready > DRAM: 512 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Using default environment > > Net: <ethaddr> not set. Validating first E-fuse MAC > cpsw > Hit any key to stop autoboot: 0 > gpio: pin 53 (gpio 53) value is 1 > Card did not respond to voltage select! > Card did not respond to voltage select! > gpio: pin 56 (gpio 56) value is 0 > gpio: pin 55 (gpio 55) value is 0 > gpio: pin 54 (gpio 54) value is 0 > switch to partitions #0, OK > mmc1(part 0) is current device > gpio: pin 54 (gpio 54) value is 1 > Checking for: /uEnv.txt ... > Checking for: /boot.scr ... > Checking for: /boot/boot.scr ... > Checking for: /boot/uEnv.txt ... > ** Invalid partition 3 ** > ** Invalid partition 4 ** > ** Invalid partition 5 ** > ** Invalid partition 6 ** > ** Invalid partition 7 ** > > FAILSAFE: U-Boot UMS (USB Mass Storage) enabled, media now available over > the usb slave port ... > UMS: disk start sector: 0x0, count: 0x750000 > \ > > It appears that somehow the root partition is being corrupted. Attempting > to mount that partition on the eMMC, while booted from a non-flasher SD > card gives the following results: > > root@arm:~# lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > mmcblk1boot0 179:16 0 1M 1 disk > mmcblk1boot1 179:24 0 1M 1 disk > mmcblk0 179:0 0 7.4G 0 disk > └─mmcblk0p1 179:1 0 7.4G 0 part / > mmcblk1 179:8 0 3.7G 0 disk > ├─mmcblk1p1 179:9 0 1.5G 0 part > └─mmcblk1p2 179:10 0 2.2G 0 part > root@arm:~# mount /dev/mmcblk1p1 /media > [ 4127.908991] EXT4-fs (mmcblk1p1): no journal found > mount: wrong fs type, bad option, bad superblock on /dev/mmcblk1p1, > missing codepage or helper program, or other error > > In some cases useful info is found in syslog - try > dmesg | tail or so. > root@arm:~# mount /dev/mmcblk1p2 /media > root@arm:~# ls /media > etc logs lost+found photos var > > mmcblk1 is the eMMC in this situation. As can be seen, it's not possible > to mount the boot partition, but it is possible to mount the second > partition produced. This is consistently the case. > > The sfdisk command the flasher runs is: > LC_ALL=C sfdisk --force --in-order --Linux --unit M "${destination}" > <<-__EOF__ > ${conf_boot_startmb},${root_part_size},${sfdisk_fstype},* > ,,${sfdisk_fstype} > __EOF__ > > where startmb=1, root_part_size=1500, sfdisk_fstype=0x83 (linux partition). > and the second line describes the second partition which fills all > remaining space. > > I have tried: > > I have tried checking the power supply to the beaglebone (the beaglebone > is powered by a daughterboard) with an oscilloscope, and it appears to be > stable. > Different SD cards - they still fail > > Different Beaglebones > > Adding more sync/flush_cache operations around everything in > partition_drive and copy_rootfs > > I also added this (unexplained code in RCNs script which claims to flush > the eMMC buffers - anyone know why this works?) > > # > https://github.com/beagleboard/meta-beagleboard/blob/master/contrib/bone-flash-tool/emmc.sh#L > > 158-L159 > # force writeback of eMMC buffers > flush_cache > dd if=${destination} of=/dev/null count=100000 > sync > in many places around the script. > > > Does anyone have any suggestions on what might be causing these ext4 > errors or what I might be doing incorrectly with setting up the partition > table? > I noticed that RCN's script only uses dd to wipe the first 108MB - should > it be wiping the whole image? Why 108MB? > > Thanks for making it this far :) > Joshua Collins > > > Important version numbers: > Kernel: 4.1.17-bone19 > Debian: 8.3-minimal-armhf-2016-01-25 > MLO: > http://rcn-ee.com/repos/bootloader/am335x_evm/MLO-am335x_evm-v2015.01-r7 > U-Boot: > http://rcn-ee.com/repos/bootloader/am335x_evm/u-boot-am335x_evm-v2015.01-r7.img > > > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5d912772-b91d-4d21-9d4c-cb73ab0eb1e5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
