search

GloDroidCommunity / raspberry-pi

Android 14 for the Raspberry PI 4 series based on the GloDroid project
Apache License 2.0
28 stars 5 forks source link

Bump-up the deps #40

Closed rsglobal closed 2 months ago

rsglobal commented 2 months ago

Upgrade:

mikegapinski commented 2 months ago

One side note - when the kernel / firmware is being updated and you OTA from an older build it may end up giving you a headache. Post OTA, I am mounting the bootloader partition to update the overlays/firmware but this should be handled differently. I added my workaround when jumping from 5.15 to 6.1 but it was a quick hotfix, not a decent implementation.

Glodroid has never really supported OTA (since it has no Updater app) but this is the last remaining piece of the puzzle right now

rsglobal commented 2 months ago

You're right.

From an implementation point of view, I suggest having three boot partitions.

  1. Active boot (current)
  2. boot_a (additional)
  3. boot_b (additional)

Once u-boot detects that it needs to swap slots, it copies boot_{a|b} to active boot and reboots the board.

Making this logic fault-resistant seems difficult, but the risk of bricking the board during this process is small enough and can be ignored.

mikegapinski commented 2 months ago

So it’s essentially the setup that I have but on a lower level. Right now I have the files on vendor and they are copied to boot after the update. Sounds like a good idea!

Not exactly perfect in my application since I don’t have the luxury of changing the partition layout on deployed devices but I’ll figure an elegant solution at some point and got with the approach you suggested

Wysyłane z aplikacji Outlook dla systemu iOShttps://aka.ms/o0ukef

Od: rsglobal @.> Wysłane: Sunday, June 23, 2024 10:08:09 PM Do: GloDroidCommunity/raspberry-pi @.> DW: Michał Gapiński @.>; Comment @.> Temat: Re: [GloDroidCommunity/raspberry-pi] Bump-up the deps (PR #40)

You're right.

From an implementation point of view, I suggest having three boot partitions.

  1. Active boot (current)
  2. boot_a (additional)
  3. boot_b (additional)

Once u-boot detects that it needs to swap slots, it copies boot_{a|b} to active boot and reboots the board.

Making this logic fault-resistant seems difficult, but the risk of bricking the board during this process is small enough to ignore.

— Reply to this email directly, view it on GitHubhttps://github.com/GloDroidCommunity/raspberry-pi/pull/40#issuecomment-2185310070, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAHDCB2EPTA7MGUV7XEL4VTZI4TKTAVCNFSM6AAAAABJYUJDJCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBVGMYTAMBXGA. You are receiving this because you commented.Message ID: @.***>

rsglobal commented 2 months ago

since I don’t have the luxury of changing the partition layout on deployed devices

That's a big issue for which I do not see a good solution.

From one end - sticking to some stationary partition layout and boot flow makes it outdated once Google creates the new one.

From another end - changing it on fields requires the customer to manually flash the firmware and probably lose all user data.

.