Unable to flash old Debian 7.11 image to eMMC on newer Beaglebone Black

GoogleGroups
1

Hi guys

I am having an issue where I am unable to flash the eMMC of newer Beaglebone black boards that ship with the Kingston EMMC04G-M627 eMMC (and probably a newer kernel version), with our Debian 7.11 image, that uses kernel 3.14.77-ti-r90. In the past, we have had no issue flashing the older Beaglebone black boards that use Kingston EMMC04G-S100 eMMC with this image/kernel combination and it works quite well for our application.

I have been able to flash other images through the usual method of uncommenting the last line of boot/uEnv.txt (#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh) to use the eMMC flasher, but in this case, it fails since the eMMC can’t be seen.

Putting the image on an SD card and booting off the SD seems to work fine, but unfortunately my bosses will not accept this solution. Additionally, I noticed that when booting this image from the SD card, the eMMC can’t be seen when using the “blkid” command. I am a bit confused since I thought the unrecognized eMMC issue was fixed on June 15, 2016, and kernel 3.14.77 was released after this.

So far, I’ve attempted the following:

-Run the update kernel script found in /opt/scripts/tools/update_kernel.sh, but of course it seems that the release is so old that this no longer works, even with the --no-check-certificate, as detailed in posts made by other members

-Install the kernel 3.8.13-bone84_1wheezy, which can be seen here https://groups.google.com/forum/#!topic/beagleboard/IgnJB-vATTU In this case installing any 3.8.X kernel caused my image to no longer boot, but installing other 3.14.XX kernels listed on http://repos.rcn-ee.net/debian/pool/main/l/linux-upstream/ seemed to boot ok, but this still rendered the eMMC unviewable. I was able to however install kernel 3.8.13-bone84 to a Debian 8.7 image on eMMC (bone-debian-8.7-iot-armhf-2017-03-19-4gb.img.xz), which I got from the official beaglebone download page, which comes with a version 4.X kernel.

https://www.element14.com/community/thread/61956/l/flash-old-debian-79-image-from-usd-to-newer-bbb-debian-83?displayFullThread=true. I do know however that we use a custom cape to run some additional hardware in conjuction with our image, perhaps this is why it doesn’t boot after installing the 3.8.13-bone84 kernel?

Apologies is anything I’m asking is silly, I am still an embedded linux newbie. I do think that if I am able to have the eMMC viewable, when booting off the SD, then I can use something like https://github.com/RobertCNelson/tools/blob/master/scripts/beaglebone-black-copy-microSD-to-eMMC.sh or the command “dd if=/path/to/your_image.img of=/dev/mmcblk0 bs=1M” to copy the SD contents to the eMMC. Or initiate the usual eMMC flasher, etc

Let me know if you guys require any further information!

2

Hi guys

I am having an issue where I am unable to flash the eMMC of newer Beaglebone black boards that ship with the Kingston EMMC04G-M627 eMMC (and probably a newer kernel version), with our Debian 7.11 image, that uses kernel 3.14.77-ti-r90. In the past, we have had no issue flashing the older Beaglebone black boards that use Kingston EMMC04G-S100 eMMC with this image/kernel combination and it works quite well for our application.

I have been able to flash other images through the usual method of uncommenting the last line of boot/uEnv.txt (#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh) to use the eMMC flasher, but in this case, it fails since the eMMC can’t be seen.

Putting the image on an SD card and booting off the SD seems to work fine, but unfortunately my bosses will not accept this solution. Additionally, I noticed that when booting this image from the SD card, the eMMC can’t be seen when using the “blkid” command. I am a bit confused since I thought the unrecognized eMMC issue was fixed on June 15, 2016, and kernel 3.14.77 was released after this.

Sorry, that's not how the kernel development works, just because a
patch was committed to the master branch, does not mean it will be
automatically pushed to the older stable branches. Someone needs to
go thru the effort of testing and requesting to have it back-ported.

So yes, while it was "fixed" before v3.14.77 was released, it was
never back-ported to the v3.14.x branch..

Here is the patch in question:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/mmc/core/mmc.c?h=v3.17

mmc: Allow forward compatibility for eMMC

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/mmc/core/mmc.c?h=v3.17&id=03a59437ef6b6ad7fb0165cb9b96c08d6bf057fc

If you guys are stuck on v3.14.x, do you need me to write up a
procedure similar to what i did for 3.8.x users stuck on ancient
kernels too:

aka like this: eMMC5.1 patch old kernel · GitHub

So far, I’ve attempted the following:

-Run the update kernel script found in /opt/scripts/tools/update_kernel.sh, but of course it seems that the release is so old that this no longer works, even with the --no-check-certificate, as detailed in posts made by other members

Wheezy (with armhf) went EOL on May 31st 2018: LTS - Debian Wiki

Wheezy's wget doesn't fully 100% support "https"..

-Install the kernel 3.8.13-bone84_1wheezy, which can be seen here Redirecting to Google Groups In this case installing any 3.8.X kernel caused my image to no longer boot, but installing other 3.14.XX kernels listed on http://repos.rcn-ee.net/debian/pool/main/l/linux-upstream/ seemed to boot ok, but this still rendered the eMMC unviewable. I was able to however install kernel 3.8.13-bone84 to a Debian 8.7 image on eMMC (bone-debian-8.7-iot-armhf-2017-03-19-4gb.img.xz), which I got from the official beaglebone download page, which comes with a version 4.X kernel.

Show us your "serial" boot log over the J1 connector..

https://www.element14.com/community/thread/61956/l/flash-old-debian-79-image-from-usd-to-newer-bbb-debian-83?displayFullThread=true. I do know however that we use a custom cape to run some additional hardware in conjuction with our image, perhaps this is why it doesn't boot after installing the 3.8.13-bone84 kernel?

Apologies is anything I’m asking is silly, I am still an embedded linux newbie. I do think that if I am able to have the eMMC viewable, when booting off the SD, then I can use something like tools/scripts/beaglebone-black-copy-microSD-to-eMMC.sh at master · RobertCNelson/tools · GitHub or the command "dd if=/path/to/your_image.img of=/dev/mmcblk0 bs=1M" to copy the SD contents to the eMMC. Or initiate the usual eMMC flasher, etc

Let me know if you guys require any further information!

Regards,

3

Hi Robert,
Thank you for taking the time to respond and clarifying things

I’ve obtained serial boot logs via the J1 connector for both the cases where I am able to successfully boot with 3.14.77-ti-r90, as well as the case where I am unable to boot after installing the 3.8.13-bone84 kernel. Note that we have a custom cape, which I can see is spitting out some lines related to gpio’s in these logs. It was not connected when obtaining these boot logs; also both logs were obtained using a newer Beaglebone Black with the newer Kingston EMMC04G-M627 eMMC and were booted off a micro SD

3.14.77-ti-r90 boot log:

`

U-Boot SPL 2018.09-00002-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)
Trying to boot from MMC2
Loading Environment from EXT4… ** File not found /boot/uboot.env **

** Unable to read “/boot/uboot.env” from mmc0:1 **

U-Boot 2018.09-00002-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500), Build: jenkins-github_Bootloader-Builder-65

CPU : AM335X-GP rev 2.1
I2C: ready
DRAM: 512 MiB
No match for driver ‘omap_hsmmc’
No match for driver ‘omap_hsmmc’
Some drivers were not found
Reset Source: Power-on reset has occurred.
RTC 32KCLK Source: External.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from EXT4… ** File not found /boot/uboot.env **

** Unable to read “/boot/uboot.env” from mmc0:1 **
Board: BeagleBone Black
not set. Validating first E-fuse MAC
BeagleBone Black:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net: eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] …
board_rev=[00C0] …
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1…
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 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 …
gpio: pin 55 (gpio 55) value is 1
533 bytes read in 21 ms (24.4 KiB/s)
Loaded environment from /boot/uEnv.txt
debug: [dtb=am335x-boneblack-ttyO1.dtb] …
Using: dtb=am335x-boneblack-ttyO1.dtb …
Checking if uname_r is set in /boot/uEnv.txt…
gpio: pin 56 (gpio 56) value is 1
Running uname_boot …
loading /boot/vmlinuz-3.14.77-ti-r90 …
7283472 bytes read in 501 ms (13.9 MiB/s)
debug: [enable_uboot_overlays=] …
loading /boot/dtbs/3.14.77-ti-r90/am335x-boneblack-ttyO1.dtb …
87061 bytes read in 78 ms (1.1 MiB/s)
uboot_overlays: add [enable_uboot_overlays=1] to /boot/uEnv.txt to enable…
loading /boot/initrd.img-3.14.77-ti-r90 …
3245971 bytes read in 265 ms (11.7 MiB/s)
debug: [console=ttyO0,115200n8 root=UUID=d75e0393-0c50-4660-9179-ad56095af7ec ro rootfstype=ext4 rootwait quiet init=/lib/systemd/systemd] …
debug: [bootz 0x82000000 0x88080000:318793 0x88000000] …

Flattened Device Tree blob at 88000000

Booting using the fdt blob at 0x88000000
Loading Ramdisk to 8fce7000, end 8ffff793 … OK
Loading Device Tree to 8fcce000, end 8fce6414 … OK

Starting kernel …

[ 0.000424] WARNING: Your ‘console=ttyO0’ has been replaced by ‘ttyS0’
[ 0.000432] This ensures that you still see kernel messages. Please
[ 0.000439] update your kernel commandline.
[ 2.776040] musb-hdrc musb-hdrc.0.auto: Failed to request rx1.
[ 2.782003] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
[ 2.855839] musb-hdrc musb-hdrc.1.auto: Failed to request rx1.
[ 2.861793] musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517
[ 2.990197] omap-sham 53100000.sham: initialization failed.
[ 3.020045] cpu cpu0: cpu0 clock notifier not ready, retry
[ 3.030058] Error: Driver ‘tfp410’ is already registered, aborting…
[ 3.037945] slave hdmi: could not get i2c
[ 3.042126] mmc1: unrecognised EXT_CSD revision 8
[ 3.048371] mmc1: error -22 whilst initialising MMC card
[ 3.383383] musb-hdrc musb-hdrc.1.auto: otg: usb_otg_kick_fsm: invalid host/gadget device
Loading, please wait…
[ 4.215341] usb 1-1.4: device vffff p5678 is not supported
[ 4.419728] usb 1-1.3.4: device v0461 p4e04 is not supported
[ 5.238724] sd 0:0:0:0: [sda] No Caching mode page found
[ 5.263419] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 5.277783] sd 0:0:0:0: [sda] No Caching mode page found
[ 5.291565] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 5.310942] sd 0:0:0:0: [sda] No Caching mode page found
[ 5.326574] sd 0:0:0:0: [sda] Assuming drive cache: write through
systemd-fsck[241]: BOOT: clean, 72281/117360 files, 450853/468736 blocks
[ 20.944418] libphy: PHY 4a101000.mdio:01 not found
[ 20.949245] net eth0: phy 4a101000.mdio:01 not found on slave 1

Debian GNU/Linux 7 SMARCO-0479B7D302B2 ttyS0

rcn-ee.net console Debian Image 2015-02-19

Support/FAQ: BeagleBoardDebian - eLinux.org

The IP Address for eth0 is: 192.168.94.127
The IP Address for usb0 is: 192.168.7.2
SMARCO-0479B7D302B2 login: [ 40.602190] musb-hdrc musb-hdrc.0.auto: otg: usb_otg_register_gadget: device not registered to otg core

`

3.8.13-bone84 log that “fails” to boot:

`

U-Boot SPL 2018.09-00002-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)
Trying to boot from MMC2
Loading Environment from EXT4… ** File not found /boot/uboot.env **

** Unable to read “/boot/uboot.env” from mmc0:1 **

U-Boot 2018.09-00002-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500), Build: jenkins-github_Bootloader-Builder-65

CPU : AM335X-GP rev 2.1
I2C: ready
DRAM: 512 MiB
No match for driver ‘omap_hsmmc’
No match for driver ‘omap_hsmmc’
Some drivers were not found
Reset Source: Power-on reset has occurred.
RTC 32KCLK Source: External.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from EXT4… ** File not found /boot/uboot.env **

** Unable to read “/boot/uboot.env” from mmc0:1 **
Board: BeagleBone Black
not set. Validating first E-fuse MAC
BeagleBone Black:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net: eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] …
board_rev=[00C0] …
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1…
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 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 …
gpio: pin 55 (gpio 55) value is 1
532 bytes read in 23 ms (22.5 KiB/s)
Loaded environment from /boot/uEnv.txt
debug: [dtb=am335x-boneblack-ttyO1.dtb] …
Using: dtb=am335x-boneblack-ttyO1.dtb …
Checking if uname_r is set in /boot/uEnv.txt…
gpio: pin 56 (gpio 56) value is 1
Running uname_boot …
loading /boot/vmlinuz-3.8.13-bone84 …
5231056 bytes read in 385 ms (13 MiB/s)
debug: [enable_uboot_overlays=] …

unable to find [dtb=am335x-boneblack-ttyO1.dtb] did you name it correctly? …

FAILSAFE: U-Boot UMS (USB Mass Storage) enabled, media now available over the usb slave port …
Unknown command ‘ums’ - try ‘help’
uboot_overlays: add [enable_uboot_overlays=1] to /boot/uEnv.txt to enable…
loading /boot/initrd.img-3.8.13-bone84 …
2617501 bytes read in 223 ms (11.2 MiB/s)
debug: [console=ttyO0,115200n8 root=UUID=d75e0393-0c50-4660-9179-ad56095af7ec ro rootfstype=ext4 rootwait quiet init=/lib/systemd/systemd] …
debug: [bootz 0x82000000 0x88080000:27f09d 0x88000000] …
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait quiet init=/lib/systemd/systemd] …
debug: [bootz 0x82000000 0x88080000:27f09d 0x88000000] …
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
** Invalid partition 2 **
** Invalid partition 3 **
** Invalid partition 4 **
** Invalid partition 5 **
** Invalid partition 6 **
** Invalid partition 7 **
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1…
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
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 …
gpio: pin 55 (gpio 55) value is 1
2041 bytes read in 7 ms (284.2 KiB/s)
Loaded environment from /boot/uEnv.txt
debug: [dtb=am335x-boneblack-ttyO1.dtb] …
Using: dtb=am335x-boneblack-ttyO1.dtb …
Checking if uname_r is set in /boot/uEnv.txt…
gpio: pin 56 (gpio 56) value is 1
Running uname_boot …
loading /boot/vmlinuz-4.14.71-ti-r80 …
10416640 bytes read in 664 ms (15 MiB/s)
debug: [enable_uboot_overlays=1] …
uboot_overlays: dtb=am335x-boneblack-ttyO1.dtb is set in /boot/uEnv.txt, unable to use [am335x-boneblack-uboot-univ.dtb or am335x-boneblack-uboot.dtb] …
uboot_overlays: disabling [enable_uboot_overlays=1] as dtb=am335x-boneblack-ttyO1.dtb is set in /boot/uEnv.txt …

unable to find [dtb=am335x-boneblack-ttyO1.dtb] did you name it correctly? …

FAILSAFE: U-Boot UMS (USB Mass Storage) enabled, media now available over the usb slave port …
Unknown command ‘ums’ - try ‘help’
uboot_overlays: add [enable_uboot_overlays=1] to /boot/uEnv.txt to enable…
loading /boot/initrd.img-4.14.71-ti-r80 …
4530240 bytes read in 293 ms (14.7 MiB/s)
debug: [console=ttyO0,115200n8 root=UUID=d75e0393-0c50-4660-9179-ad56095af7ec ro rootfstype=ext4 rootwait init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh] …
debug: [bootz 0x82000000 0x88080000:452040 0x88000000] …
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
debug: [console=ttyO0,115200n8 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh] …
debug: [bootz 0x82000000 0x88080000:452040 0x88000000] …
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
** Invalid partition 2 **
** Invalid partition 3 **
** Invalid partition 4 **
** Invalid partition 5 **
** Invalid partition 6 **
** Invalid partition 7 **
starting USB…
USB0: scanning bus 0 for devices… 3 USB Device(s) found
scanning usb for storage devices… 0 Storage Device(s) found
cpsw Waiting for PHY auto negotiation to complete… TIMEOUT !
using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC 04:79:b7:d3:02:b2
HOST MAC de:ad:be:af:00:00
RNDIS ready
The remote end did not respond in time.missing environment variable: pxeuuid
Retrieving file: pxelinux.cfg/01-04-79-b7-d3-02-b2
cpsw Waiting for PHY auto negotiation to complete… TIMEOUT !
using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC 04:79:b7:d3:02:b2
HOST MAC de:ad:be:af:00:00
RNDIS ready
The remote end did not respond in time.Retrieving file: pxelinux.cfg/C0A80102
cpsw Waiting for PHY auto negotiation to complete… TIMEOUT !
using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC 04:79:b7:d3:02:b2
HOST MAC de:ad:be:af:00:00
RNDIS ready
The remote end did not respond in time.Retrieving file: pxelinux.cfg/C0A8010
cpsw Waiting for PHY auto negotiation to complete… TIMEOUT !
using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC 04:79:b7:d3:02:b2
HOST MAC de:ad:be:af:00:00
RNDIS ready

`

If you guys are stuck on v3.14.x, do you need me to write up a
procedure similar to what i did for 3.8.x users stuck on ancient
kernels too:

If you able to do a write up on the correct procedure to follow, that would be much appreciated!

Let me know if theres anything else you need from me

4

Before looking in to anything else.
, you might want to look into the missing device tree blob file. Your log mentions:

unable to find [dtb=am335x-boneblack-ttyO1.dtb] did you name it correctly? …

5

That dtb=‘something’ was a workaround in the v3.14 era to resemble some sorta overlay manager… to do the same in 3.8 is completely different. (Aka load serial 1)

So your 3.8 fails to boot as that file doesn’t exist.

Since your suck on v3.14 the only same solution is to rebuild the kernel with that patch.

Regards,

6

So following the instructions seen here: https://gist.github.com/RobertCNelson/39faf80ddc9fcefae74dce2c6ca2eb45
In my case I’m using Ubuntu 19.10 through a VM, I noticed that after cloning the repo and placing both patches in /yakbuild/patches/local_patches/

and editting recipe.sh to use toolchain “gcc_linaro_gnueabihf_4_8” and kernel_tag=“3.14.77-ti-r90”, then running build_kernel.sh, I noticed the following lines in the terminal:

Applying: mmc: core: Update the ext-csd.rev check for eMMC5.1
error: patch failed: drivers/mmc/core/mmc.c:292
error: drivers/mmc/core/mmc.c: patch does not apply
Patch failed at 0001 mmc: core: Update the ext-csd.rev check for eMMC5.1
hint: Use ‘git am --show-current-patch’ to see the failed patch
When you have resolved this problem, run “git am --continue”.
If you prefer to skip this patch, run “git am --skip” instead.
To restore the original branch and stop patching, run “git am --abort”.
fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
patch.sh ran successfully

In any case the script continues to run for another ~30-40 mins and yielded the following files:
3.14.77-ti-r90.zImage, 3.14.77-ti-r90-dtbs.tar.gz, 3.14.77-ti-r90-firmware.tar.gz, 3.14.77-ti-r90-modules.tar.gz and config-3.14.77-ti-r90

Of course placing the files in their corresponding locations on my BBB, didn’t work. I also attempted the process with other 3.14.x kernel_tags but the same error occured. Just wondering if there’s something I am overlooking?

7

I’ve been on vacation since my last reply, I’ll add more details in around 36 hours or so, depending on airport delays tomorrow.

Regards,

8

So following the instructions seen here: eMMC5.1 patch old kernel · GitHub
In my case I'm using Ubuntu 19.10 through a VM, I noticed that after cloning the repo and placing both patches in /yakbuild/patches/local_patches/

and editting recipe.sh to use toolchain "gcc_linaro_gnueabihf_4_8" and kernel_tag="3.14.77-ti-r90", then running build_kernel.sh, I noticed the following lines in the terminal:

Applying: mmc: core: Update the ext-csd.rev check for eMMC5.1
error: patch failed: drivers/mmc/core/mmc.c:292
error: drivers/mmc/core/mmc.c: patch does not apply
Patch failed at 0001 mmc: core: Update the ext-csd.rev check for eMMC5.1
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
patch.sh ran successfully

In any case the script continues to run for another ~30-40 mins and yielded the following files:
3.14.77-ti-r90.zImage, 3.14.77-ti-r90-dtbs.tar.gz, 3.14.77-ti-r90-firmware.tar.gz, 3.14.77-ti-r90-modules.tar.gz and config-3.14.77-ti-r90

Of course placing the files in their corresponding locations on my BBB, didn't work. I also attempted the process with other 3.14.x kernel_tags but the same error occured. Just wondering if there's something I am overlooking?

Okay, gist/repo is now updated..

Based on your current seria logs, you should just do the
"./build_deb.sh" route, and install the file via dpkg on your microsd
card..

Regards,

9

Hey thanks again Robert for going out of your way to provide a procedure for 3.14.x , and especially for replying while away on your holiday!

Following the procedure for the dpkg method, in which the file “0001-mmc-Allow-forwar-compatibility-for-eMMC.patch” in placed in /yakbuild/patches/local_patches/ and then running ."/build_sh" seems to work ok on my Ubuntu 19.10 VM, it yielded me the following files in the /yakbuild/deploy/

linux-firmware-image-3.14.77-ti-r90_1xross_armfhf.deb
linux-headers-3.14.77-ti-r90_1xross_armhf.deb
linux-image-3.14.77-ti-r90_1xross_armhf.deb
linux-libc-dev_1xross_armhf.deb

Placing the file “linux-image-3.14.77-ti-r90_1xross_armhf.deb” on my BBB attempting to run the command “sudo dpkg -i linux-image-3.14.77-ti-r90_1xross_armhf.deb” however gave me the following error:

dpkg-deb error: archive 'linux-image-3.14.77-ti-r90_1xross_armhf.deb" contains not understood data member control.tar.xz, giving up
dpkg: error processing linux-image-3.14.77-ti-r90_1xross_armhf.deb (–install):
subprocess dpkg-deb --control returned error exit status 2
Errors were encountered while processing:
linux-image-3.14.77-ti-r90_1xross_armhf.deb

Some googling makes me think this is an issue with my version of dpkg on the BBB (although I never recieved any errors when using dpkg, with other 3.14.x linux-image deb files obtained from http://repos.rcn-ee.net/debian/pool/main/l/linux-upstream/)

The most commonly suggested fix was to run the following commands on my BBB
sudo apt-get clean
sudo apt-get update
sudo apt-get install dpkg

But I since Wheezy is EOL, I wasn’t able to update dpkg. I know that the version on my BBB is 1.16.18 (armhf) and apparently since the release of dpkg 1.19.0 control.tar* files will be compressed using xz, as mentioned here:
https://github.com/aptly-dev/aptly/issues/655

10

Ah crap, so we had a workaround for "3.8.13" to detect this, but it
got ignored on "3.14.x"... This should fix it:

https://github.com/RobertCNelson/yakbuild/commit/991c2f18f94d490861776a92424fba2d560660b1

Just run:

git pull ; ./build_deb.sh

and it "should" work this time.. fingers crossed..

Regards,

11

Amazing looks to all be working now! eMMC is viewable when booting off the micro SD and I was able to eventually get my 3.14.X image onto the eMMC of the newer BBB’s

An alternative work around suggested by arno01, for the dpkg-deb error I was having, can be found at the very bottom of the link https://github.com/aptly-dev/aptly/issues/655 can also fix this issue. Run the following commands within your directory that contains the .deb files of interest to gzip the .deb file instead of xz’ing it. Hopefully no one will need it, as Robert has updated the repo

dpkg-deb -R package.deb tmp
rm package.deb
fakeroot dpkg-deb -Zgzip -b tmp package.deb
rm -rf tmp

One final note, for anyone else experiencing issues flashing these 3.14.x patched images, is that I found flashing this image to the eMMC first
https://debian.beagleboard.org/images/bone-debian-7.11-lxde-4gb-armhf-2016-06-15-4gb.img.xz

Then booting into it and uncommenting out the last line of /boot/uEnt.txt to enable the eMMC flasher

##enable BBB: eMMC Flasher:

cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

Before flashing my 3.14.x patched image worked well. This image contains kernel 3.8.13-bone80, which also has the eMMC patch backported to it. When I tried flashing my 3.14.x patched image while an image with say a 4.X version kernel was already on the eMMC, then the contents of my SD card would get erased (instead of the eMMC) during the flashing process