SFOS refactoring project (news thread)

Platform Development
#27

UPDATE #14

Finally, here we are 3 months later my Sony Xperia 10 II arrived. This news is published with a bit of latency because I celebrated the whole afternoon. Also the binary compatibility gap between the CentOS and SailFish OS glibc libraries has been addressed.

  • 26.08.2023, RedFish OS recovery image

    description : the RedFish OS recovery image supports CentOS and SFOS apps running, both.

    status : ready for advanced users adoption, but it is not publicly available.

With this news, the first stage is ended. Is this the right time to start the 2nd stage? Nope!

Now, it is the time to review the work done and to reorganise the ideas collected in the meantime. Because, in the meantime, a lot of things as been learned - not necessarily novelty but details that was not so clear at the beginning. It is normal, it happens in every project to everybody and if it does not happen, it means that the project was so boring that nothing new, even the smallest details, pop-up.

After the review, it is the time to replan the plan. Obviously, otherwise the information acquired was worthless. How big will be the changes? Just few hints:

  • containers are a spectacular technology and they should leveraged much more
  • cross-compiling busybox against musl sounds much better than compile it for CentOS
  • replacing SSHd with dropbear statically linked against musl sounds very interesting

About the first point the novelty is the use of containers within GitHub infrastructure (for me at least, because I never do that before). CentOS or Fedora? Why we should care when musl can fulfill the bill for busybox? Musl. Once the the compatibility gap has a size and it has been addressed, carrying on with sshd is counterproductive compared to a statically linked dropbear single binary with all the features. Again, musl are our friends.

Long path and prosperity, R- :smiling_face_with_three_hearts:

recovery-menu-on-telnet-3
recovery-menu-on-telnet-32032×685 47.8 KB

Shrinking images like there is not tomorrow!

I report here from a post above that I cannot edit anymore the comparison between the animations in term of size and rendering:

#28

CentOS? How comes?
20 chars.

#29

I made my selection among those distributions were using the RPM format. Fedora and CentOS are the two most well-known candidates. In particular Fedora 31 and CentOS 8 shown a kind of binary compatibility also at glibc libraries level.

To upgrade the SFOS to an up-to-day distribution it is required to step from Fedora 31 to 38 or from CentOS 8 to 9. This means that CentOS has a life spawn much longer and more suitable for a long-term business.

Thanks to your question, I added the related sub-section to the RFOS repository and corrected the last news link which was broken (also in my last update in this thread).

You might also find interesting this:

Which is the private git repo log about the recovery image development.

#30

UPDATE #15

I wish to share some facts and stats about the recovery image performances:

A few facts and stats about the RFOS recovery image:

  • boot time since the kernel starts until the init script takes over: 3.12 seconds
  • init time in recovery mode 2.5s included 2s for waiting the USB network raises up
  • power consumption of 101 mAh while untouched with logo and IPv4 telnet banner at half of brightness
  • power consumption drops to 86 mAh when the screen brightness is dimmed to the minimum.

Before the power-saving optimisation was started, the power consumption was always 136 mAh. Moreover, it does:

  • sfter 15 minutes, the display brightness is set to minimum, but the powerkey can raise it to maximum;
  • then, within 60 seconds, the display brightness will be capped to half of the maximum again.

The powerkey-handler.sh is immortal, and start/stop simply enable/disable its action. Ignoring the powerkey event is shown with a text printed in the console and dimming the display brightness to 100% from 10% and back to 50% within about 2 seconds. If the powerkey event is not ignored and happens while the lock is taken, then the RFOS animation starts, and when the lock is released, the shutdown will be executed. The shutdown is presented with a 4 seconds long bar that it is filling, and usually at its half or 2/3 the system is shutdown.

Forcing the device to reboot is always possible by pressing powerkey + volume up + down for a few seconds.

At the beginning of the init script:

  • the CPUs governor is set to conservative;
  • the internal flash disk caching is disabled;
  • the power control of the internal flash disk is set to on.

Moreover, when the recovery init procedure is completed:

  • the display brightness is set to half of the maximum;
  • the firmware kernel load is disabled: it stops trying to load the missing firmware.

The telnet service is raised as soon as possible, as well as the sshd. The telnet service offers the menu, while the sshd offers an interactive login shell based on busybox ash in which the recovery functions are pre-loaded into its environments. Mounting and umounting the root filesystem by lvm can be performed on the user’s demand by the telnet recovery menu or by a ssh section using the proper functions lvm_mount and lvm_umount.

In /tmp/bms_current_avg.log is stored the 10s average current absorbtion taken every second, and the showbmscur shows the statistics about it:

=> Current 10s average absorbtion:
  \_ sleep drift: 4121 ppm 865.577 %
  \_ load avg: 2.02 2.03 1.75 1/356 5935
  \_ samples: 1670
  \_ min: 86 mAh
  \_ max: 101 mAh

As you can see sleep 1 can last up to near 9 seconds. Possibly it happens when the CPU working frequency drops and the jiffies rate changes. While sleep 60 is correct with a precision higher that 1:1000.

#31

UPDATE #16

RedFish OS recovery image boots a freshly installed SailFish OS, video in HD resolution:

The video above replace the older one for which the dots are full red but in the video are showing like orange because the over-exposition.

Rationale

When connected to USB data link port, the RFOS boot image starts in recovery (maintenance) and allows to update the boot_a and boot_b partitions and flash the userdata partition plus others activities via telnet menu or SSH shell.

Otherwise it boots normal into the operative system installed on the smartphone. In this case a fresh installation of SailFish OS 4.5.0.21 completed by the RFOS recovery image itself.

Nightly stats

As you can see the average current absorption in around 100 mAh

=> Current 10s average absorption:
  \_ samples: 8859
  \_ min: 99 mAh
  \_ avg: 101 mAh
  \_ max: 107 mAh
=> System report and init log:
  \_ load avg: 2.23 2.05 2.02 1/359 15271
  \_ sleep drift: 4008 ppm 103.199 %
[    3.048092] initrd: 1st line in /init.
[    3.060950] initrd: recovery functions loaded.
[    3.061077] initrd: preparation completed, start.
[    3.069264] initrd: USB data link config, finding...
[    4.692482] initrd: USB data link found at 5* attempt.
[    4.718540] initrd: set display_bright_dim 2 and read 512.
[    4.813341] initrd: current pid 1 current affinity list: 0.
[    4.816395] initrd: telnet/ssh on 10.42.66.66, udhcpd running.
[    5.000343] initrd: hostname 'recovery' init process completed.

While the boot processes has been further optimized by parallelization and it lasts 2 seconds not anymore the 2.5 seconds like before. A small improvements but 20% less.

#32

UPDATE #17

Now, it takes 55 seconds to flash the userdata partition with the SFOS 4.5.0.21 spare image.

Moreover, flashing all the partitions as flash.sh script does, boot_a, dtbo_a, dtbo_b, oem_a, oem_b and userdata using the RFOS recovery image with a single command takes 54 seconds — as long as the longer flashing procedure among all involved because the RFOS image can operate in parallel but not the fastboot command.

recovery-menu-on-telnet-flashing
recovery-menu-on-telnet-flashing375×520 12.6 KB

The menu above is more updated than the one used in the video below.

Flash all partitions but not boot_b, start.

Flashing boot_a, netcat is waiting on 12340 port...
Flashing dtbo_a, netcat is waiting on 12341 port...
Flashing oem_a, netcat is waiting on 12342 port...
Flashing userdata, netcat is waiting on 12349 port...
Uploading: 25 221 677 1180 1602 
Writing: wr wr wr wr wr wr 
Flash userdata completed in 52.451s
Flashing userdata by netcat/simg2img done.
flushing /dev/mmcblk0p86: ok

28860416 bytes (27.5MB) copied, 3.101750 seconds, 8.9MB/s
flushing /dev/mmcblk0p42: ok

279063 bytes (272.5KB) copied, 3.159021 seconds, 86.3KB/s
25165824 bytes (24.0MB) copied, 0.289088 seconds, 83.0MB/s
flushing /dev/mmcblk0p79: ok
flushing /dev/mmcblk0p80: ok

419430400 bytes (400.0MB) copied, 11.970527 seconds, 33.4MB/s
419430400 bytes (400.0MB) copied, 4.078934 seconds, 98.1MB/s
flushing /dev/mmcblk0p83: ok
flushing /dev/mmcblk0p84: ok

Flash all completed in 54.514s.

After having flashed the userdata partition, it is possible to prepare it for being used by SFOS and the default root partition size is no longer 5GB but 8GB.

Opportunities

A smartphone delivered with the RedFish OS recovery image installed in boot_a or in boot_b can deliver the complete flashing procedure for SailFish OS without the use of fastboot or any other tool at all. Just connect to the USB laptop/PC port, reboot, telnet, press U, press F, and then start on the laptop/PC the script that upload the images.

Here below a video in which the SFOS is installed via the RedFish OS recovery image telnet menu:

It is possible to further simplify this process by opening the browser, selecting the folder that contains the images, and pressing OK to flash the smartphone completely. Potentially, the browser can download all the files that are not present in the folder and use the folder as storage instead.

3 Likes
#33

UPDATE #18

This thread started on August 1st, and the tasks related to it (stage1) have been completed by August 31st. Today, I took some time to raise the httpd and give it a demo page.

redfishos-httpd-animation

Once upon a time, I was also used to writing websites with a text editor. I did the same today just to celebrate the old-gold days. The GIF animation shows some simple effects on the button.

The html page does not use images: everything is made with HTML and CSS.

I am thinking to give it a cgi-bin example with an Easter-egg joke. Pressing the button, 1/6 chance to start a cgi-bin that shows some internals of values about the running OS like free memory, average load, network configuration, etc.

The chance 1/6 is taken by the roulette-russe (also known as Russian roulette¹).

:information_source: Note

Russian roulette (Русская рулетка, Russkaya ruletka) is a potentially lethal game of chance in which a player places a single round in a revolver, spins the cylinder, places the muzzle against the head or body (of the opponent or themselves), and pulls the trigger. If the loaded chamber aligns with the barrel, the weapon will fire, killing or severely injuring the player. Russian refers to the supposed country of origin, and roulette to the element of risk-taking and the spinning of the revolver’s cylinder, which is evocative of a roulette wheel.

Source: wikipedia

#34

UPDATE #19

Because elegance is a matter of style!

redfishos-httpd-animation-u-press
Dress me, Undress me.

Change the style but stay elegant… :blush:

post scriptum

If you like to play with it:

this is the link but you have to clone the git repository or download the www folder content.

roulette russe

The copyright notice is a link to the COPYRIGHT file, and the button works with a JavaScript embedded into the index.html dressing up the page with a background tile randomly chosen among those available. Moreover, after the first three buttons pressures, starts a roulette russe with a traditional 1/6 chance to display the copyright notice and hide the button in such a way that the page should be reloaded or left fixed. A very simple game, but amusing. An Easter egg will be added in the future because an Easter egg should not be left behind.

Stay tuned!

#35

UPDATE #20

The 1st stage of the project has been completed at the end of August. In the meantime I thinking about how to proceed, I decided to work a little on the yamui v1.0.6 because it the last that has not d-bus and initd support which brings a lot of dependencies and the d-bus or the initd are not useful in the recovery image.

rfos-nuovo-banner
rfos-nuovo-banner3992×4032 461 KB

The photo is the result of these commands

yamui rfos-logo -x 500 -y 600 -v -60 -m 3 \
    -t "RFOS RECOVERY MODE" -t "TELNET VIA USB CABLE" \
        -t "IP: $LOCAL_IP"

yamui rfos-logo -x 500 -y 600 -v -60 -m 3 \
    -t "SYSTEM REBOOT" -p 2000

A combination of a PNG image (logo) with a progress bar and a text with the font multiplied 3x times and centered on x-axis and slightly below (5%) the center of the y-axis because at that high there is the progress bar. Probably, I will use the -m 4 because it seems to small the text.

redfishos:~ # yamui -h

  yamui - tool to display progress bar, logo, or small animation on UI

  USAGE: yamui [OPTIONS] [IMAGE(s)]

    DIR        - the folder path in which the images are searched or
                 by default /res/images
    IMAGE(s)   - images in PNG format with .png extention which file
                 names can be found in DIR without the .png extension.
                 The maximum of 32 pictures is supported.
    STRING(s)  - text strings composed by printable chars, 32 max rows

    OPTIONS:

  --animate=PERIOD, -a PERIOD
         Show IMAGEs (at least 2) in rotation over PERIOD ms
  --imagesdir=DIR, -i DIR
         Load IMAGE(s) from DIR, /res/images by default
  --progressbar=TIME, -p TIME
         Show a progess bar over TIME milliseconds
  --stopafter=TIME, -s TIME
         Stop showing the IMAGE(s) after TIME milliseconds
  --text=STRING, -t STRING
         Show STRING on the screen, multiple times for each row
  --fontmultipl=FACTOR, -m FACTOR
         Increase the font size by a factor between 1 and 16
  --xpos=THOUSANDTHS, -x THOUSANDTHS
         Set the text horizontal center to x/1000 of the screen width
  --ypos=THOUSANDTHS, -y THOUSANDTHS
         Set the text vertical origin to y/1000 of the screen height
  --vshift=THOUSANDTHS, -v THOUSANDTHS
         Set the vertical shift to v/1000 of the screen height
  --cleanup, -k
         Exit closing and freeing resources but the kernel does it
  --help, -h
         Print this help

These are the options that I used and their meaning.

The sources are available in the github forked project.

Post Scriptum

The power consumption drop from 105 mAh to 46 mAh on average. Four CPUs have been put off-line but those change did not affected the stand-by current absorption, obviously. Putting 4 CPUs off-line and set the other to work at 300MHz is just a trick to deliver a system that works smoothly at its bare minimum. This means that it will be good enough also on older/slower devices and on the same system clog by activities.

#36

Updated the update above: yamui with extended feature using the drm display and draw multiple line of text in any position of the screen and with font size variable between 1 (original) and 16x (16 time wider and 16 times higher, therefore 256 times bigger).

#37

UPDATE #21

Using the RedFish OS recovery image as a dumb-phone, aesthetic proof-of-concept:

It is just a demonstration use of a customized yamui version. The support for SIM and WiFi has not been added in the recovery image but the touchscreen works (disabled by default).

#38

UPDATE #22

First of all, I confirm that the current consumption is stable on 45mAh (80h of stand-by) with the smartphone in stand-by (Xperia 10 mark 2). I managed to speed-up yamui of 15%. Initializing the drm frame-buffer subsystem and displaying the RFOS logo and the telnet IPv4 banner (tre line of text at 3x of the original font size) has been reduced from 0.85s to 0.75s without even intervene in the drm sub-system initialization that it takes 0.38s.

yamui rfos-logo -x 500 -y 600 -v -60 -m 3 \
    -t "RFOS RECOVERY MODE" -t "TELNET VIA USB CABLE" \
        -t "IP: $LOCAL_IP"

Instead, the yamui-screensaver now it is not triggered anymore by any event but just the power-key as it should be. In fact, every time that I was touching the display to move the smartphone that was enough to awake the system and rise-up the current consumption up to 105mAh. Now, this issue is solved and I did it using the code found in the yamui-powerkey.

Now, there are some possible tasks to face:

  • trying to rewrite the drm initialization procedure in order to speed-up it.

  • provide yamui with a fifo that allows to send it commands without the need of restarting every time which would be a similar functionality provided by the d-bus / initd support added after v1.0.6 but much simpler and more powerful considering the new options added. Another fifo can be used to integrate yamui with yamui-powerkey and yamui-screensaverd in a single binary which will serve as server: one fifo for receiving commands and another fifo to read until the 3s power-key event arrive (an this is supposed will reduce the uncompressed footprint by 1/3 bringing down the size from 77Kb to 48Kb which is an estimation by now).

  • load the WiFi firmware, install the WLAN binaries and connect to a hotspot and this will open the chance to use internet but also brings in all the related tasks like how to deal with the domain name resolution and raise up a firewall.

  • understand why the I2C fail to connect with the battery and the /proc can provide the current value during the draining and charging times but not the level of energy stored into the battery which can be read just at the boot time but not later!

Everyone, that wish to provide information about these tasks is welcome. I remember you that the enhanced yamui included mstime to collect timing with ms, us and ns resolutions is available under the same license that the authors of Android decided for it.

Therefore all the improvements added are universally available for those want to use it.

The future is here

I know that your enthusiasm will not going to be triggered until I will integrate into the RedFish OS recovery image a small AI engine capable of interpreting vocal commands with minimal or no personal voice training (even if the voice-print would be a nice feature in order to let the bot recognize the master by the voice and not accepting commands by others):

- RedFish
- Yes Master
- Arp scan the WLAN
- Yes Master, WLAN arp-scan started
- ... gingle of clockwork gears, just for the show ...
- Master 19 clients found, 12 android smartphones, two iphone, three windows and 2 linux
- RedFish
- Yes Master
- Scan all open ports of the android smartphones found
- Yes Master, port scanning started
- ... gingle of clockwork gears, just for the show ...
- Master, 32 open ports found on 12 android smartphones scanned
- RedFish
- Yes Master
- Check for available root-access vulnerabilities on the open-ports stacks found
- Yes Master, penetration test started
- ... gingle of clockwork gears, just for the show ...

Just a tip: the code to do this work just exists and works but it has not the voice support, not yet… :face_with_hand_over_mouth:

With the voice command bot, we will be able to continue hacking the neighborhood even when we are busy in making sex with our partner! :rofl:

Clock work soundtrack

Here a couple of examples of clockwork soundtracks:

Luxury mechanical clockwork watch makers can be accepted as sponsor for extra contents available for the VIP customer$ only!

#39

UPDATE #23

I have managed to bring down the current consumption to 23 mAh on average in a whole night included 15 minutes at 81 mAh when the system is keeping itself ready for the next human interaction, then go to sleep.

=> Current 10s average absorption:
  \_ samples: 4061
  \_ min: 22 mAh
  \_ avg: 23 mAh in [23, 81] mAh
  \_ max: 81 mAh

With a full charged battery of 3600 mAh of capacity, this means a standby time of 156 hours.

Improving the a bit more the power saving (21.4 mAh on average while the current minimum is 22 mAh) and the system will be able to stand by for a whole week.

Welcome back Nokia 3310! :face_with_hand_over_mouth:

Punkt MP01 virtual clone

yamui punkt-mp01 -m 3 -t "TEXT FROM SUSANNA" \
    -t " " -t "Hi, Rob" -t "what are you doing?" -x -140 -y 80

1920×2560 520 KB

#40

UPDATE #24

I have used the super partition, the 12GB left behind (free) for the Android updates and I have installed CentOS 8 Stream on it. Now, it is possible to compile and build RPM packages doing a chroot on that partition.

The size of CentOS installation required to compile the RFOS yamui is 642MB uncompressed. Compiled and running with the native CentOS 8 libraries the yamui seems being 3% more faster which does not surprise me.

At this point also the SFOS container is not anymore necessary for RFOS and the installation can be transformed into a container in such a way it could also compile and build RPM directly on RFOS ported command-line applications.

The developers menu

Instead of making longer and longer the main menu, I split it in few specialized sections:

recovery-menu-on-telnet-all
recovery-menu-on-telnet-all990×522 26.7 KB

I also moved the rootfs options to developers menu just to keep it short enough.

Sleeping USB subsystem

Notice that the first rendering of the recovery menu takes 461 ms, and in the past it was about 360 ms. This is because the USB is set to sleep, like many other components.

Obviously, the awake process introduced a latency of about 100 ms, but the current consumption dropped to 23 mAh from 46 mAh on average. It has been halved, and the overall advantage is pretty clear.

#41

UPDATE #25

The average current consumption has been reduced to 22 mAh on average and the Sailors menu has been added to deal with major SailFish OS tasks like backup and restore:

Screenshot from 2023-09-26 17-31-28
Screenshot from 2023-09-26 17-31-28440×590 52.1 KB

Do the root filesystem back-up immediately after installation takes near 122 seconds and to restore it, takes 68 seconds. The back-up can be seriously speed up using 8 processors for pigz instead of the 4 enabled at this time. Just matter of writing two functions:

  • cpus_full_power() for 8 cores with schedutil as scheduler
  • cpus_half_power() for 4 cores with conservative as scheduler

Obviously, also taskset -pc 0-4 $$ for the first and taskset -pc 0-7 $$. The cose is just ready to support the different hardware configurations 4:4 for mark2 and 2:6 for mark3.

With all the CPU working and set with schedutil as scheduler, timings are:

  • backup 122s → 75s
  • restore 68s → 45s

The Factory reset option is not still operative but listed as TODO.

#42

UPDATE #26

Punkt. puts a like on my MP01 clone post on LinkedIn.

Screenshot from 2023-09-29 19-37-15
Screenshot from 2023-09-29 19-37-15807×255 46.5 KB

link: Roberto A. Foglietta on LinkedIn: WELCOME BACK NOKIA 3310 Inspired by Punkt. MP01, I have decided to adapt…

I presume that my educated guess about cross-branding and cross-marketing as a benefit for both parties has been positively understood.

Are they going to sue me because I used their phone layout as background image? I do not think so. The two products do not completely overlap on the market and therefore, it is a cross-product (or cross-branding) marketing. Both enjoy the co-competition and my virtual terminal is a spot for their product: we copy the best.

link: Where to go after Sailfish? - #272 by robang74

After all, who tries the virtual clone is much more keen to buy the real device and who has bought the real device is happy to know that the smartphone is going to buy is offering a virtual clone because it confirms that s/he bought a valuable product.

How much the virtual clone will imitate the real device, is a matter of a commercial deal among the parties { vendors, distributors, professional modders } vs Punkt. Those prefer to go with the cheaper but iconic 3310 will find a deal with Nokia. All the others can have an unbranded virtual phone or their own customized terminal.

What RedFish OS should provide is just a reasonable easy way to customize that terminal in such a way the { vendors, distributors, professional modders } can adapt it to their own business model as long as they are not going to have a deal for delivering a ready-to-go iconic or branded template.

In the books this is called the DIY dilemma: buy it ready to go or do it by yourself. Nothing new.

#43

UPDATE #27

Look to my coming on the first light of the fifth day, at dawn look to the east.

The smartphone was left sleeping but not completely untouched for 5 near 6 days

redfishos:~ # uptime
 09:07:23 up 5 days, 21:03,  0 users,  load average: 1.40, 1.22, 1.14

It started the challenge with a fully charged battery (3600 mAh by official specification)

=> Status battery: 100%, not charging n/a good

and I got it a bit before it was completely gone:

=> Status battery: 1%, charging fast good,

The average current confirm that the smartphone which never had been connected to an USB port, nevertheless had some interaction in these days:

=> Current 10s average absorption:
  \_ samples: 5964
  \_ min: 22 mAh
  \_ avg: 26 mAh in [26, 72] mAh
  \_ max: 72 mAh

Even if the average presented is over-rated compared the reality, in fact:

  • 26 x ((24 x 5) + 21) = 3.666 mAh

  • (3600 x 0.99) / 141 = 25.28 mAh

  • 25.51 x 141 / 0.99 = 3633 mAh

However, a 1% of tolerance into the battery capacity or a small rounding error could explain pretty well the deviation observed. On the other hand, this also means that the numbers we are looking at, are real at 99%, at least, which is a great news.

#44

UPDATE #28

Today, I have added a feature about a permanent storage for some configuration parameters.

First of all, it is important to clarify that a recovery image for its nature SHOULD NOT rely on any kind of persistent data otherwise its mission to be ALWAYS available and ALWAYS identical in its features among services different boots would be gone and moreover a persistent data can break it.

However, because the RedFish OS can be also used for assisting developers, modders and debuggers. It make sense that they can save some persistent data somewhere which is strictly associated with the bootable recovery image like the WLAN name and password, for example.

This can be acceptable as far as and as long as that data can be used just after the boot and by a manual procedure like a specific menu. The functions are:

redfishos:~ # rflist boot_perm
boot_perm_umount
boot_perm_is_mounted
boot_perm_device
boot_perm_loopdev
boot_perm_setup
boot_perm_mkfs
boot_perm_mount
boot_perm_free

redfishos:~ # boot_perm_mount; df -h $PERMCFS
Filesystem  Size  Used Available Use% Mounted on
/dev/loop0  3.9M   512      3.9M   0% /perm

To activate the permanent area the function boot_perm_setup() and boot_perm_mkfs() will provide the necessary features. I choose the VFAT in order to maximize the free space because it is just 4MB and the EXT4 or even the EXT2 filesystem would have took too much space. The size is purposely small to prevent and to disincentive its misuse.

How does it work?

The main idea is that apart the RedFish OS recovery image everything else is compromised or potentially unreliable. Possibly, also the RedFish OS recovery image could be broken but with a single fastboot upload the recovery image can be easily restored.

The script that generates the recovery image prevent the image to be bigger than 60MB and thus 4MB are always left free at the end of the boot_a partition. The last 4MB are left free and unwritten by the fastboot command and this grants the persistence among uploads.

The same happens for the boot_b partition, obviously.

The system knows on which partition is booted from and it will uses the related last 4MB. A menu voice that allows to copy the persistence area from boot_a and boot_b will be added but not the viceversa because it is dangerous supporting the idea that the user can arbitrary choose to boot from boot_b rather than boot_a. Because the boot_b can also contains something completely different like an emergency phone or an hidden system/data.

Everything else is just a set of functions in shell scripting.

Persistence menu

The persistence menu is a contextual one:

persistence-menu
persistence-menu940×480 17.1 KB

Depending the state of the persistence, it shows some options rather than others.

#45

UPDATE #29

Minimum current absorption reached the 18mAh, the average is unchanged but it depends on the interactions: every power button press brings awake the smartphone for 15 minutes. It is reasonable to reduce the average reducing it to 5 minutes. With this trick, I managed to reach 21.36 mAh on average which is a milestone because 21.4 mAh means 7 full days (a week) of stand-by.

#46

UPDATE #30

BEYOND GOOGLE & APPLE DUOPOLY
FOSS alternatives for digital mobility

StatsCounter tells us that in May '23, the market share for smartphone OSes is split in this way:

  • Android/Google 67.6%
  • iOS/Apple 31.6%

Which means the remaining is less than 1%. Today we are speaking about that 1%: available alternatives, future outlook, and, most importantly, why we have to care about that 1%.

Spoiler: because a study by the University of Edinburgh and Trinity College Dublin published in Q4/2021 proves what all we know – our smartphones leak our personal data and meta-data constantly.

SFScon_TwitterPost_1024x512_Speak
SFScon_TwitterPost_1024x512_Speak1024×512 18.6 KB

1 Like