By the way, I could test with 3 different boards. and A5A, an Element14 RevC, and an BBG.
On Wed, Dec 28, 2016 at 3:04 AM, William Hermans <[email protected]> wrote: > So . . . > > On Fri, Dec 23, 2016 at 3:50 PM, Robert Nelson <[email protected]> > wrote: > >> Okay, i have a version of u-boot with overlays enabled, ready for some >> basic testing.. >> >> *************Background*************************************** >> >> in u-boot we are doing: >> >> dtb= is loaded at ${fdtaddr} >> >> We read /boot/uEnv.txt for (dtb_overlay=<path/file.dtbo>) >> >> then load it, into ${rdaddr} #(no reason that specific address) >> >> Then we must run thru this routine: >> >> fdt addr ${fdtaddr} >> fdt resize; >> fdt apply ${rdaddr} >> fdt resize; >> >> Without the "fdt resize, the jump to kernel bomb's in bootz." >> >> ***************************************************************** >> >> *************Actual testing...*************************************** >> >> Step 1: Do you have a usb serial adapter to monitor the boot process? >> >> no = stop reading now... till you have one in hand... >> yes = please continue >> >> Step 2: Remove /uEnv.txt (i forgot to code that path in this test) >> >> rm /uEnv.txt >> >> Step 3: Update u-boot to v2017.01-rc2 >> >> cd /opt/scripts/tools/developers/ >> git pull >> ./update_bootloader.sh --use-beta-bootloader >> >> On reboot, it should show: >> >> U-Boot SPL 2017.01-rc2-00002-g52b3c56009 (Dec 23 2016 - 16:22:21) >> Trying to boot from MMC1 >> >> U-Boot 2017.01-rc2-00002-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600), >> Build: jenkins-github_Bootloader-Builder-493 >> >> If not, eMMC probably messing with you.. >> >> dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10 >> > > What ?!? > >> >> Step 4: /boot/uEnv.txt >> >> remove "cape_universal=enable" we dont want any false posititves... >> >> dtb_overlay=/lib/firmware/BB-UART2-00A0.dtbo >> >> before: >> kernel: >> root@beaglebone:~# dmesg | grep serial >> [ 2.082007] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158, >> base_baud = 3000000) is a 8250 >> [ 2.096583] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 159, >> base_baud = 3000000) is a 8250 >> [ 20.106023] systemd[1]: Created slice system-serial\x2dgetty.slice. >> >> after: >> U-Boot: >> loading /boot/dtbs/4.4.39-ti-r75/am335x-boneblack-wireless.dtb ... >> 64988 bytes read in 163 ms (388.7 KiB/s) >> debug: [dtb_overlay=/lib/firmware/BB-UART2-00A0.dtbo] ... >> loading /lib/firmware/BB-UART2-00A0.dtbo ... >> 883 bytes read in 276 ms (2.9 KiB/s) >> >> kernel: >> root@beaglebone:~# dmesg | grep serial >> [ 2.081559] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158, >> base_baud = 3000000) is a 8250 >> [ 2.095942] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 159, >> base_baud = 3000000) is a 8250 >> [ 2.096807] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 160, >> base_baud = 3000000) is a 8250 >> [ 20.316939] systemd[1]: Created slice system-serial\x2dgetty.slice. >> >> Step 5: Profit!!! ;) >> >> ***************************************************************** >> >> I know it's a little limited, but something for testing over Christmas. ;) >> >> FAQ: >> >> What does this solve? Lots of random kernel races... (looking at >> video/emmc/etc)... As U-Boot updates the final *.dtb and not the >> kernel... >> >> What about 2+ overlays? Maybe next week, for Christmas you get one.. ;) >> >> Does this replace the current method? No it just improves things.. >> >> What have you tested it on? Just BB-UART2-00A0.dtbo and then i wrote >> this email up and got ready to go home... >> >> Will it read the eeprom and auto load the correct overlay? Sure, >> sometime between next week and the start of the new year... ;) >> >> Will this fix the issue with the painful out of box experience with >> LCD3/LCD4/LCD7? Correct, as long as they have an eeprom. ;) >> >> How do i actually test things? >> >> Easiest, /boot/uEnv.txt >> >> dtb=am335x-boneblack-overlay.dtb >> dtb_overlay=/lib/firmware/xyz.dtbo >> >> > Ok, so I have zero problems testing. But what I do have problems with is > understanding how to get from point A to point B > > Exact steps, with no "mumbo jumbo" in between. > > So first, will this work with the latest "stable" image ? If so, why would > I want to destroy the partition table of the only boot-able partition ? I > would actually want the partition table intact so I can make these changes > while reflecting those same changes.on the boot able "image" / file system. > -- 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/CALHSORri%2Bcxj_NhJ3U6t_zOFE%2BRLbZYeqigauH1qiRuu%3D921RQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
