On Tuesday, 11 February 2020 18:06:47 UTC+11, RobertCNelson wrote: > > > > On Mon, Feb 10, 2020, 8:54 PM Untitled X <[email protected] > <javascript:>> wrote: > >> 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 >> <ethaddr> 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] ... >> > > 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, >
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? -- 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/088dad82-942d-4100-85fe-1ec667214222%40googlegroups.com.
