Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade path #14

Open
benhylau opened this issue Dec 28, 2017 · 3 comments
Open

Upgrade path #14

benhylau opened this issue Dec 28, 2017 · 3 comments

Comments

@benhylau
Copy link
Member

The SD card is a MBR disk containing at least one FAT partition:

  • Some unpartitioned space before the first partition contains uboot and some allwinner stuff
  • The FAT partition contains:
    • conf.d/ (configs)
    • boot/ (everything else)

To upgrade the node software, the user can mount the FAT filesystem on a computer, then drag-and-drop replace:

  • The kernel zImage or other components in boot/
  • Drop custom configs into conf.d/

In the rare case that the bootloader (uboot being not in the FAT filesystem) needs to be upgraded, the user can back-up conf.d then reflash the SD card, and drop the backed up config directory into the new FAT filesystem.

@benhylau
Copy link
Member Author

@hamishcoleman Perhaps you can elaborate on the OTA upgrade addition, and its self-recovery mechanism based on an incrementing counter of failed boots?

@darkdrgn2k
Copy link
Contributor

In the rare case that the bootloader (uboot being not in the FAT filesystem) needs to be upgraded, the user can back-up conf.d then reflash the SD card, and drop the backed up config directory into the new FAT filesystem.

Thought:

Could we create a DD file with just the boot loader and not the root partition. That way the bootloader is seperate from the full flash image. (Kind of like what you see CISCO do with them ROMON boot loader)

That way you just flash the dd to the card and the partition does not get overwritten (as long as the partition tables are not part of that image!

@darkdrgn2k
Copy link
Contributor

From what I learned I think that on ram disk uInitrd holds the root filesystem. Simply replacing it (assuming no kernel modifications etc) would be enough

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants