-
Notifications
You must be signed in to change notification settings - Fork 24
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
meta-isar: add swupdate support #332
Comments
You can probably generate a hybrid MBR with GPT and legacy DOS table. I just did so for the BeaglePlay which has a similar problem. I can share that prototype later (still WIP for other reasons), and we can discuss how to generalize it (if it isn't yet). |
How does that help? The SPL needs to be loaded from the 8KB offset, but the GPT itself is already 8KB in size (given the mandated 128 entries) and starts at LBA 2. By that, it overlaps with the SPL. In theory, the location of the GPT can also be set to a higher offset (location is specified in the GPT header in LBA 1), but non of the tools to generate the partitioning supports this AFAIK. Anyways, it would help if you could share the prototype. |
Ah, right, forgot about that hard-coded location of the firmware. On the beagleplay, there are real partitions and FAT filesystems involved. Well, if it is possible to create a working layout with GPT and just tools aren't available, we could still fix that with them python scripting I suppose. If there is no possible layout, then GPT is lost, indeed. |
The EFI boot part has been solved and is currently under review on the ISAR ML: https://groups.google.com/g/isar-users/c/W-x06JxvmzM/m/VyYZnog2BgAJ By that, we can use |
Updates of the mtda-isar image on an nanopi-neo board are quite time consuming, as the IO pins block the access to the SD card. By that, you first need to disconnect some IOs before changing the SD card. Especially in mass deployments (test racks) this is a real issue.
I briefly had a look at the boot spec of the sunxi chip. For swupdate via isar-cip-core the simplest way would be to boot EFI and use the provided pattern around efibootguard. However, the chip does not support vanilla GPT partitioned sd cards, as the uboot SPL is loaded from the 8KB offset which overlaps with the GPT default location. As EFI boot requires GPT, we cannot easily make that work. Another option would be to use u-boot directly, but the swupdate+u-boot support in cip-core is quite limited (parts of the integration would need to be written by us).
The text was updated successfully, but these errors were encountered: