0

I am trying to prepare for an event where i need to update a kernel and device tree file remotely on an embedded Linux device. I know where these objects are saved in storage, but i am not sure if my current approach to update them is optimal or even stable.

Right now the i know that:

  1. The kernel is stored in a FAT32 partition which i can mount and see the kernel file uImage.
  2. The device tree is stored in a section of storage accessible via a block device /dev/mmcblk1boot0 and an offset and span.

So my questions are:

  • Assuming Linux is up and running, is updating the kernel and device tree as simple as overwriting the uImage file (cp new-uImage uImage) and the data at the DTB offset (dd if=new.dtb of=/dev/mmcblk1boot0 seek=<offset>)?
  • Does the Kernel look at these storage location after boot?
  • Are there more common ways to accomplish the same result?
Claudio
  • 10,614
  • 4
  • 31
  • 71
Liam Kelly
  • 3,524
  • 1
  • 17
  • 41
  • You may want to read this : https://stackoverflow.com/questions/6937592/implementing-an-update-upgrade-system-for-embedded-linux-devices – Mali Mar 23 '18 at 14:32
  • Relevant, but the conversation broke down into best practices and ignored core mechanisms. My question is much more scoped to how the kernel image stored on the harddrive is used after boot. – Liam Kelly Mar 23 '18 at 14:47
  • 1
    The kernel and dtb images are only accessed during boot by the boot program. The kernel does not need to access these stored images. You're free to do whatever with the stored images, so long as you're cognizant that you could brick the board. BTW your conflation of *"memory"* and a storage device is confusing and unconventional/wrong. I.E. `/dev/mmcblk1boot0` is neither memory or a *"harddrive"*. – sawdust Mar 23 '18 at 22:37
  • fixed the language, thank you – Liam Kelly Mar 25 '18 at 17:14

0 Answers0