Unable to flash old Debian 7.11 image to eMMC on newer Beaglebone Black
356 views
Skip to first unread message
erolbuy...@gmail.com
Feb 9, 2020, 7:20:38 PM2/9/20
to BeagleBoard
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!
Robert Nelson
Feb 9, 2020, 9:39:00 PM2/9/20
to beagl...@googlegroups.com, erolbuy...@gmail.com
On Sun, Feb 9, 2020 at 6:20 PM <erolbuy...@gmail.com> wrote:
>
>
> 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
>
>
> 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.
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: https://gist.github.com/RobertCNelson/39faf80ddc9fcefae74dce2c6ca2eb45
> 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's wget doesn't fully 100% support "https"..
> -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!
>
--
Robert Nelson
https://rcn-ee.com/
Untitled X
Feb 10, 2020, 9:54:06 PM2/10/20
to BeagleBoard
Hi Robert,
3.8.13-bone84 log that "fails" to boot:
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
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 MMC2Loading 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.1I2C: readyDRAM: 512 MiBNo match for driver 'omap_hsmmc'No match for driver 'omap_hsmmc'Some drivers were not foundReset Source: Power-on reset has occurred.RTC 32KCLK Source: External.MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1Loading Environment from EXT4... ** File not found /boot/uboot.env **
** Unable to read "/boot/uboot.env" from mmc0:1 **Board: BeagleBone Black<ethaddr> not set. Validating first E-fuse MACBeagleBone 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 MODEcpsw, usb_etherPress SPACE to abort autoboot in 2 secondsboard_name=[A335BNLT] ...board_rev=[00C0] ...switch to partitions #0, OKmmc0 is current deviceSD/MMC found on device 0switch to partitions #0, OKmmc0 is current deviceScanning mmc 0:1...gpio: pin 56 (gpio 56) value is 0gpio: pin 55 (gpio 55) value is 0gpio: pin 54 (gpio 54) value is 0gpio: pin 53 (gpio 53) value is 1switch to partitions #0, OKmmc0 is current devicegpio: pin 54 (gpio 54) value is 1Checking for: /uEnv.txt ...Checking for: /boot.scr ...Checking for: /boot/boot.scr ...Checking for: /boot/uEnv.txt ...gpio: pin 55 (gpio 55) value is 1533 bytes read in 21 ms (24.4 KiB/s)Loaded environment from /boot/uEnv.txtdebug: [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 1Running 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 deviceLoading, 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 throughsystemd-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: http://elinux.org/BeagleBoardDebian
The IP Address for eth0 is: 192.168.94.127The IP Address for usb0 is: 192.168.7.2SMARCO-0479B7D302B2 login: [ 40.602190] musb-hdrc musb-hdrc.0.auto: otg: usb_otg_register_gadget: device not registered to otg core
U-Boot SPL 2018.09-00002-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)Trying to boot from MMC2Loading 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.1I2C: readyDRAM: 512 MiBNo match for driver 'omap_hsmmc'No match for driver 'omap_hsmmc'Some drivers were not foundReset Source: Power-on reset has occurred.RTC 32KCLK Source: External.MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1Loading Environment from EXT4... ** File not found /boot/uboot.env **
** Unable to read "/boot/uboot.env" from mmc0:1 **Board: BeagleBone Black<ethaddr> not set. Validating first E-fuse MACBeagleBone 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 MODEcpsw, usb_etherPress SPACE to abort autoboot in 2 secondsboard_name=[A335BNLT] ...board_rev=[00C0] ...switch to partitions #0, OKmmc0 is current deviceSD/MMC found on device 0switch to partitions #0, OKmmc0 is current deviceScanning mmc 0:1...gpio: pin 56 (gpio 56) value is 0gpio: pin 55 (gpio 55) value is 0gpio: pin 54 (gpio 54) value is 0gpio: pin 53 (gpio 53) value is 1switch to partitions #0, OKmmc0 is current devicegpio: pin 54 (gpio 54) value is 1Checking for: /uEnv.txt ...Checking for: /boot.scr ...Checking for: /boot/boot.scr ...Checking for: /boot/uEnv.txt ...gpio: pin 55 (gpio 55) value is 1532 bytes read in 23 ms (22.5 KiB/s)Loaded environment from /boot/uEnv.txtdebug: [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 1Running 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 TreeCould not find a valid device treedebug: [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 TreeCould 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, OKmmc1(part 0) is current deviceScanning mmc 1:1...gpio: pin 56 (gpio 56) value is 0gpio: pin 55 (gpio 55) value is 0gpio: pin 54 (gpio 54) value is 0gpio: pin 53 (gpio 53) value is 1switch to partitions #0, OKmmc1(part 0) is current devicegpio: pin 54 (gpio 54) value is 1Checking for: /uEnv.txt ...Checking for: /boot.scr ...Checking for: /boot/boot.scr ...Checking for: /boot/uEnv.txt ...gpio: pin 55 (gpio 55) value is 12041 bytes read in 7 ms (284.2 KiB/s)Loaded environment from /boot/uEnv.txtdebug: [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 1Running 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 TreeCould not find a valid device treedebug: [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 TreeCould 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) foundcpsw Waiting for PHY auto negotiation to complete......... TIMEOUT !using musb-hdrc, OUT ep1out IN ep1in STATUS ep2inMAC 04:79:b7:d3:02:b2HOST MAC de:ad:be:af:00:00RNDIS readyThe remote end did not respond in time.missing environment variable: pxeuuidRetrieving file: pxelinux.cfg/01-04-79-b7-d3-02-b2cpsw Waiting for PHY auto negotiation to complete......... TIMEOUT !using musb-hdrc, OUT ep1out IN ep1in STATUS ep2inMAC 04:79:b7:d3:02:b2HOST MAC de:ad:be:af:00:00RNDIS readyThe remote end did not respond in time.Retrieving file: pxelinux.cfg/C0A80102cpsw Waiting for PHY auto negotiation to complete......... TIMEOUT !using musb-hdrc, OUT ep1out IN ep1in STATUS ep2inMAC 04:79:b7:d3:02:b2HOST MAC de:ad:be:af:00:00RNDIS readyThe remote end did not respond in time.Retrieving file: pxelinux.cfg/C0A8010cpsw Waiting for PHY auto negotiation to complete......... TIMEOUT !using musb-hdrc, OUT ep1out IN ep1in STATUS ep2inMAC 04:79:b7:d3:02:b2HOST MAC de:ad:be:af:00:00RNDIS 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
Hugo van den Brand
Feb 11, 2020, 12:23:03 AM2/11/20
to beagl...@googlegroups.com
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? ...
Op di 11 feb. 2020 03:54 schreef Untitled X <erolbuy...@gmail.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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/763c0000-d3d5-4f25-881f-51b8bb9466dd%40googlegroups.com.
Robert Nelson
Feb 11, 2020, 2:06:47 AM2/11/20
to Beagle Board
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,
Untitled X
Feb 16, 2020, 9:12:45 PM2/16/20
to BeagleBoard
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/
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?
Robert Nelson
Feb 16, 2020, 9:27:41 PM2/16/20
to Beagle Board, erolbuy...@gmail.com
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,
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/088dad82-942d-4100-85fe-1ec667214222%40googlegroups.com.
Robert Nelson
Feb 18, 2020, 11:07:50 AM2/18/20
to Beagle Board, erolbuy...@gmail.com
> 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?
Okay, gist/repo is now updated..
> 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?
https://gist.github.com/RobertCNelson/39faf80ddc9fcefae74dce2c6ca2eb45#file-procedure-3-14-x
https://github.com/RobertCNelson/yakbuild/commit/f69aa1dbf1347cce2dc6b19de33c8bc4f3af3226
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..
Untitled X
Feb 18, 2020, 7:36:47 PM2/18/20
to BeagleBoard
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!
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:
Robert Nelson
Feb 18, 2020, 7:48:25 PM2/18/20
to Beagle Board, erolbuy...@gmail.com
On Tue, Feb 18, 2020 at 6:37 PM Untitled X <erolbuy...@gmail.com> wrote:
>
> 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
Ah crap, so we had a workaround for "3.8.13" to detect this, but it
>
> 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
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..
Untitled X
Feb 19, 2020, 9:10:15 PM2/19/20
to BeagleBoard
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
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
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 tmpOne 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
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.shBefore 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
Reply all
Reply to author
Forward
0 new messages