PinePhone image 2023-04-06 (wifi, software-add tab, Jitsi preset)

[ttcoder at netcourrier.com]

> It is interesting that the download of the index worked for you (so 
> network connectivity works on principle) but the actual packages didn't. 
> That's strange because both rely in the same infrastructure and tools 
> (same server, same fetchurl program, same TCP/IP stack, same signature key).
> 
> To investigate this issue further, we will ultimately need a way to 
> inspect the log without depending on a preset (such as the system 
> shell). I'll have to ponder a bit how to achieve that on target.
> 
> Do you happen to own the UART cable for the PinePhone? If yes, I could 
> prepare an image that directs all of Sculpt's log output to the serial.

I don't
Though back when making the purchase, I remember seeing the cable in the pine64 web shop and... actually thinking
of the reverse use (debugging my laptop by plugging the phone into its serial port to retrieve the Genode LOG).
Might not make as much sense though!

Alternatively, down the road when more prioritary features are done, I guess Sculpt could
write the log to an ext2fs partition (main or secondary) on the SD card, which could then be removed from
the phone and read on a computer. Not sure if that fits in with how it all works,  i.e. is it "easy said, easy done" like with an HDD.

> 
> But I'm just guessing. Down the road, we will for sure need to collect 
> such error conditions and reflect them to the user, letting the user 
> decide about retrying failed downloads instead of repeatedly running 
> against the wall.
> 
> > That's with a PinePhone 2 GB, and 16 GB SD card. Hope this helps somewhat,
> 
> The 2 GiB may indeed be a problem because the image assumes a 3 GiB 
> model. I'm noting down [1] that we should at least detect the PinePhone 
> version at boot time and limit the RAM allocations depending on the used 
> variant. The 2 GiB model might not be able to host the heaviest presets 
> but you could at least play with the simple ones without the risk of 
> accessing RAM that isn't there.
> 
> [1] https://github.com/genodelabs/genode-allwinner/issues/18
> 
> Cheers
> Norman

I could imagine the 2 GB aspect being the culprit, playing a role somewhat, something like : downloading the app index
just means getting a text file, so it stays within existing quotas, but downloading a package means downloading a
file *and* setting up a PD/RM/RAM quota to actually run the executable inside the package, and the extended
quota fails as the request is a little greedy and assumes 3 GB are available... Or something like that.
Well come to think of it, Genode would just issue a warning, "requested quota not available in full, reducing to max available", hmmm.

Anyway that tidbit should not be a distraction from testing on the more common phones, 2 GB support can be debugged down the road :^)

cd