1

I have a problem whereby a remote BeagleBone device is taking hours to boot up. When it does, I don't see any problems in the kernel boot logs such as journalctl -b or journalctl -b -1

Without having physical access to the device over the serial interface, we can't see what is happening in the bootloader. Why is it that the U-Boot bootloader logs are not saved to somewhere on the flash memory or even RAM, or somewhere readable from when the kernel takes over? This would be extremely useful.

I understand that the file system is not mounted at that point, but surely there could be a solution? Or am I missing something that makes this procedure very difficult?

Engineer999
  • 161
  • 1
  • 7
  • In embedded systems, bootloaders are generally very small (100kB or less) and specifically designed to check the image and jump to the start. I would be surprised if the bootloader were the issue here unless you have some kind of flash memory issue. Really bootloaders are very simple and there isn't much to log. – Ron Beyer Aug 30 '19 at 21:42
  • 4
    I'm voting to close this question as off-topic because it is a question about using an operating system and is unrelated to computing hardware. – Elliot Alderson Aug 30 '19 at 21:52
  • 2
    This sounds like a *debug* problem, not an operational one. Consider connecting the system to another which will log its serial console output, then request the data back from that. In theory, U-Boot could write to a dedicated log partition. Or it could write to a reserved block of RAM which something on the Linux side could grab and save. But you likely have a *one time problem* and the best way to solve that would be to duplicate the problem system and run it a bit with something else collecting its logs. – Chris Stratton Aug 31 '19 at 00:41
  • 1
    If you really need to do this in the field, maybe you can wire the serial port to one of the Adafruit SAMD-based SD card loggers, and then connect that via USB to the Beagle so that when it does get up you can remote into the Beagle and collect the log... (Beware also the serious but "wontfix" BBB ethernet design error...) – Chris Stratton Aug 31 '19 at 00:43
  • @RonBeyer "Really bootloaders are very simple and there isn't much to log" . Certainly not too simple and there is alot of important stuff to log. So I certainly disagree with this. – Engineer999 Sep 03 '19 at 14:28

1 Answers1

2

Or am I missing something that makes this procedure very difficult?

Yes. The bootloader is what loads your operating system.

There's no drivers but the minimal bit you need to load the operating system.

Uboot indeed is pretty mighty – it can even come (if you compile it with such) with the appropriate flash memory driver (at least read-only, but that's a start for your own patches, right?), and some file system drivers.

The ability to write logs to storage is still a lot of things to implement, which you'd usually leave up to the actual OS. In fact, during the time when the first things the bootloader does are executed and potentially logged to the serial console, your board might not even have working RAM yet, but might be exclusively working from caches or even just the register bank.

So, yeah, you ignore the fact that "writing something to storage" becomes easy once you're a program running under an OS. It's hard when there's no OS, thus no hardware support.

Marcus Müller
  • 88,280
  • 5
  • 131
  • 237
  • 2
    Writing logs to a dedicated partition would be well within the realm of what U-Boot has the fundamentals to accomplish, the issue is more that it wouldn't generally be viewed as a wise use of flash wear cycles. – Chris Stratton Aug 31 '19 at 00:40
  • @ChrisStratton if I were to implement permanent, I'd just have Uboot reserve say 1MB of RAM, and tell the OS it boots to not touch it, but log it to a file, network, whatever. In case the boot goes wrong and the boot loader hangs, there's nothing I could do without physical access any way. – Marcus Müller Aug 31 '19 at 08:49