> > It looks like newer bootloaders support this, but at the time, it wasn't > supported.
At the time when ? USB boot has been possible since the Beaglebone white. But I digress, it depends on what exactly you mean by "boot". If you mean loading the kernel and rootfs from USB. Then yes that is possible. If you mean bootloaders from USB too . . . that's a bit more problematic. But there was a successful GSoC project that did just that( I believe ). On Fri, Aug 26, 2016 at 10:01 AM, Alexander Hayman <[email protected]> wrote: > Nothing is loaded from USB in this particular situation, because nothing > is connected to USB. I was just pointing out that there is a custom > bootloader that is designed to check for a bootable USB and boot from it if > it is there. It looks like newer bootloaders support this, but at the > time, it wasn't supported. > > The bootloader in this case seems to perform it's task correctly, it's > just that the kernel seems unhappy, (4.4.19-bone13). I think my next step > is to try getting rid of some of the kernel options, and see if that > helps. If that fails, I will try a few other kernel versions. And if that > fails, I'll switch to a new image per Robert's suggestion. > > Thanks, > Alex > > On Thursday, August 25, 2016 at 8:41:58 PM UTC-4, William Hermans wrote: >> >> Alexander, >> >> Are you just loading the rootfs and kernel from USB ? If this is the case >> you should not need a custom >> first or second stage bootloader. Granted I have not done this myself >> since 3.8.x kernels, but It should just work, Unless uboot has changed in >> this regard. Don't see why it should have though. >> >> On Thu, Aug 25, 2016 at 3:21 PM, Alexander Hayman <[email protected]> >> wrote: >> >>> U-Boot 2014.10-rc2-00017-ge202aa7-dirty (Aug 25 2016 - 16:36:51) >>> >>> 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, usb_ether >>> Hit any key to stop autoboot: 0 >>> gpio: pin 53 (gpio 53) value is 1 >>> Booting from usb ... >>> (Re)start USB... >>> USB0: Port not available. >>> USB error: all controllers failed lowlevel init >>> USB is stopped. Please issue 'usb start' first. >>> gpio: pin 56 (gpio 56) value is 0 >>> gpio: pin 55 (gpio 55) value is 0 >>> gpio: pin 54 (gpio 54) value is 0 >>> 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 >>> SD/MMC found on device 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 >>> 932 bytes read in 14 ms (64.5 KiB/s) >>> Loaded environment from /boot/uEnv.txt >>> 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.4.19-bone13 ... >>> 7269608 bytes read in 415 ms (16.7 MiB/s) >>> loading /boot/dtbs/4.4.19-bone13/am335x-boneblack.dtb ... >>> 55834 bytes read in 38 ms (1.4 MiB/s) >>> loading /boot/initrd.img-4.4.19-bone13 ... >>> 7498211 bytes read in 432 ms (16.6 MiB/s) >>> debug: [console=ttyO0 splash plymouth.ignore-serial-consoles >>> fbcon=rotate:2 ${optargs} >>> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN >>> capemgr.enable_partno=BB-UART4,BB-BONE-LCD4-01. >>> debug: [bootz 0x82000000 0x88080000:7269e3 0x88000000] ... >>> Kernel image @ 0x82000000 [ 0x000000 - 0x6eece8 ] >>> ## Flattened Device Tree blob at 88000000 >>> Booting using the fdt blob at 0x88000000 >>> Loading Ramdisk to 8f8d9000, end 8ffff9e3 ... OK >>> Loading Device Tree to 8f8c8000, end 8f8d8a19 ... OK >>> >>> Starting kernel ... >>> >>> And then it shutsdown. >>> >>> >>> We are using a custom bootloader that's pretty old. It was only >>> modified to allow for a boot from USB, >>> which explains some of the messages at the top. >>> Maybe some of the kernel options are no longer supported? >>> I guess I should just try a new image, but I'm just curious if you see >>> anything obvious from these logs. >>> >>> Thanks for your time, >>> Alex >>> >>> -- >>> 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/ms >>> gid/beagleboard/e1153433-2492-4cd8-b016-c55d10d72d05%40googlegroups.com >>> <https://groups.google.com/d/msgid/beagleboard/e1153433-2492-4cd8-b016-c55d10d72d05%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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/6dae566a-0192-41cc-a44a-a1e78b6e02c3%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/6dae566a-0192-41cc-a44a-a1e78b6e02c3%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CALHSORpEaBfmj_YPrSdVBBKEwtEtULGUKE1UrHR2C903rpfCgQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
