Search code examples
linux-kernelcross-compilingbootbeagleboneblackbeagleboard

Not able to boot after building kernel for BBG (using microSD)


My aim is to cross compile a new Linux Kernel for a BeagleBone Green. I've successfully completed all the steps that were needed to build the kernel and deploy it.

Using the following tutorial https://embedjournal.com/kernel-compilation-beaglebone-black/

I have a microSD card with rootfs and BOOT partition. rootfs has the kernel modules and BOOT has MLO, u-boot.img, uImage and uEnv.txt.

After putting the SD card into the BBG and pressing the S2 button, LEDs don't blink. But when I press the Power button, LEDs start blinking but BBG doesn't boot with that.

So my question here is that do I need to have an OS already flashed to the BBG internal eMMC and then insert a SD card which has the built kernel?

Or is it fine to have nothing into the BBG and then by just inserting the prepared SD card I can boot into it.

My second question - Is it necessary to have a USB to serial cable here? I am not using a USB to serial cable.


Solution

  • It's important to understand how the "S2" button changes the behaviour of Beaglebone type AM335x boards:

    When power is applied, the AM335x SoC "looks" at a few of its connection pins, one of them is going through the button labeled "S2". It only does this once and behaviour remains fixed until power is removed.

    • If "S2" is pressed when powering on, then it will first look at the micro-SD slot. More accurately it will try the following things: SPI, micro-SD, USB, UART.
    • If "S2" is not pressed when powering on, then it will first look at the eMMC. More accurately it will try the following things: eMMC, micro-SD, UART, USB

    [Please note that "USB" is a special device mode and does not imply capability to boot directly from USB mass storage!]

    But what does it mean "it looks at X"?

    It means that the internal minimal boot code looks for a source of bootloader. This is often referred to as MLO or SPL or X-Loader. It's a first stage that then loads the main bootloader, in this case U-Boot.

    There are many ways to provide the SPL. The AM335x Technical Reference Manual (revision P) Chapter 26.1.2 "Architecture", Figure 26-1 shows this as the underlying HW (hardware) layer. I will only cover MMC and SD, for further details, please read the TRM.

    But why does it boot from SD if I don't press the button on power up?
    or: U-Boot also makes choices.

    It's complicated. There are many ways™.

    1. Foremost it will first check the eMMC, if it finds a SPL at some magic locations, it will execute it and then that will execute U-Boot
    2. If it didn't find anything on the eMMC, then it checks for an inserted SD card and proceeds as above. If it doesn't find a SPL on a SD, it will try USB mode and UART0 too.
    3. Once U-Boot takes over it follows its own logic, possibly modified by a uEnv.txt. This sounds innocent, but what it means is that even if U-Boot was loaded from eMMC (priority!) it can still decide that there is an SD card inserted and it will load the Linux kernel from there! most likely what happened to @shreeya-patel

    Answer 1: eMMC can be blank

    To avoid such easily confusing situations it often helps to wipe the eMMC to reduce the number of variables that can mess with things. The easiest way to do this is boot a recent beagleboard.org image from SD card and execute sudo blkdiscard /dev/mmcblk1. This will erase everything from eMMC. The result is that for the average user the behaviour is reduced to: It will always try to read everything from SD-card. If something is wrong with SPL, U-Boot or the kernel, then booting will fail reproducibly.

    I've allowed myself for some simplifications and minor omissions. Feel free to ask, but also consider reading up about those topics.

    Do I need a USB-to-serial adapter?

    Not if you get everything 100% right and the system boots perfectly fine to at least a point where you can interact with it either over USB, Ethernet or WiFi.

    If booting fails at any step due to the most minute detail, you will most likely have no way to find out what happened! And this was the reason for this question.

    Personally, I mark days where I created something from scratch and it worked the first time red in my calendar. I think I might have 2 such marked days by now, in many years and even then there were other failures on those days.

    That is why I consider a USB-to-serial adapter an essential tool.

    Also the price for the cheapest types of adapters on eBay or on one of the shopping platforms like Aliexpress or Banggood has dropped below 1€/1US$. I always have a couple of spares and for devices that I work with more often I will leave the debug UART adapter attached permanently for sheer convenience.

    The amount of simple, yet incredibly valuable introspection makes it essential. It will alow you you to understand things much better, progress faster and design more reliable systems.