How does one get working deep/S3 sleep with Ubuntu Focal/5.7 mainline kernel?
#1
I've discovered quite a few ways that don't work...

Starting with the 0.10.12 ayufan arm64 builds, things work sanely, with the exception of deep sleep and sound.

Using the pbp-tools repo (thanks, those scripts are awesome!), I was able to build an updated 5.7 mainline kernel from the Manjaro git repos, which gives support for just about everything.  The postinstall script fixes sound, not that I really care too much about sound these days.

What I can't quite figure out the details for is the deep sleep mode.  It's not critical - I can live without it, but I'd like to have it working if possible, because that's the last step before it's "totally working."  The s2idle sleep mode works fine, but the deep mode doesn't.

I understand this is related to a lack of the binary bsp blobs in the bootloader regions, which on these images seems to be a 4MB partition starting at the standard 32kb offset.  I just don't quite understand where to find the BSP blobs, or how to arrange them in this 4MB region.

Is this documented anywhere?  I've found plenty of references to what to do, but not any specific steps of "You grab these blobs, arrange them this way, and it solves the problem."
#2
Well, I attempted to install the uboot packages from here, after some guidance from IRC.

https://gitlab.manjaro.org/manjaro-arm/p...ob/master/

Flashing them to eMMC, I now have a green power light and nothing else.  Time to pull out the serial adapter...

//EDIT: Actually, it booted.  Just took north of 90 seconds.  The kernel took over 70 seconds after registering HugeTLB and doing the next thing, which was working on cryptd.

//EDIT2: This is related to CONFIG_CRYPTO_RSA per https://forum.pine64.org/showthread.php?tid=8326, which is set to 'y' in the kernel running.  Unclear why this matters at the moment, but may be somehow related to NVMe being supported in the new firmware blobs?  Poking...
#3
So: It works now, as far as deep sleep goes! Sound won't work after sleep/resume, but that's a separate issue. I have deep sleep/resume working Ubuntu 20.04 and the 5.7 kernel from https://gitlab.manjaro.org/tsys/linux-pinebook-pro

Install the auyfan Focal image - I'm using 0.10.12

Using the pbp-tools script, build the 5.7 kernel and install it. Reboot, you should have a 5.7 kernel series, instead of the 5.6 series that the Ubuntu 20.04 image ships with.

Then, using the blobs and flashing script from https://gitlab.manjaro.org/manjaro-arm/p...ookpro-bsp, update the firmware on the eMMC. Yes, it looks like you're writing in the middle of a partition. Yes, you probably are. No, I don't think this is sane, but it does work (just don't put anything on /boot/efi - you might overwrite the firmware if you do that).

sudo dd if=idbloader.img of=/dev/mmcblk2 seek=64 conv=notrunc
sudo dd if=uboot.img of=/dev/mmcblk2 seek=16384 conv=notrunc
sudo dd if=trust.img of=/dev/mmcblk2 seek=24576 conv=notrunc

With this completed, you should be good in terms of deep sleep/wake. My PBP used about 2% battery overnight, and resumed properly in the morning.

Sound still does not work after the resume, though. A reboot seems to fix it, but that's no improvement over not having deep sleep...

//EDIT: The following seems to fix sound. I'll put it in a resume hook: pulseaudio -k && sudo alsa force-reload
#4
Thanks for the sound fix
> Yes, it looks like you're writing in the middle of a partition.
>Yes, you probably are. No, I don't think this is sane, but it does work
Look at fdisk,, user partitions start at 32768,, 16M
64 sectors, 8M, 12M is exactly where idbloader, uboot, trust are supposed to be
You can save remembering 16384 by using bs=1M seek=8 (for uboot),, and it may make more sense
and easier to remember (1024*2*8=16384)
Flash is not really happy writing 512 size chunks, not if there is much to write, bs=256k or larger is better (and faster)
#5
Unfortunately, I'm pretty sure there's a mounted partition in there.

On my install, where I've not messed with fstab/etc:

Code:
Device          Start       End   Sectors  Size Type
/dev/mmcblk2p1     64      8191      8128    4M Linux filesystem
/dev/mmcblk2p2   8192     32767     24576   12M Microsoft basic data
/dev/mmcblk2p3  32768    524287    491520  240M Linux filesystem
/dev/mmcblk2p4 524288 122142686 121618399   58G Linux filesystem

and lsblk:

Code:
mmcblk2      179:0    0  58.2G  0 disk
├─mmcblk2p1  179:1    0     4M  0 part
├─mmcblk2p2  179:2    0    12M  0 part /boot/efi
├─mmcblk2p3  179:3    0   240M  0 part /boot
└─mmcblk2p4  179:4    0    58G  0 part /
mmcblk2boot0 179:32   0     4M  1 disk
mmcblk2boot1 179:64   0     4M  1 disk

Unless I'm reading this badly wrong, the 8MB and 12MB offsets are in the middle of the partition mounted at /boot/efi.

Code:
/dev/mmcblk2p2 on /boot/efi type vfat (rw,relatime,sync,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
#6
OK,, the boot0 and boot1 are artifacts from android, fdisk does not show them,,
so they can be ignored
blk2p1 is where idbloader is located
blk2p2 is where uboot and trust are, but I doubt that is a valid fat filesystem
Just because there is a partition listing, that says nothing about what is on the disk,,
despite the name /boot/efi
Itis odd that it starts at 4M, maybe it is an efi booted system
I suppose it could be the very 1st efi booted arm64 distro, but I doubt it
If it was an ESP, efi system partition, it will have a fat filesystem
Try mounting it, and show a directory listing, it almost certainly will fail to mount
(a fat fs needs a PBR/VBR, 2 fat tables and a / directory, this takes space,
so uboot won't be where the bootrom expects to find it. For that matter,
i doubt that rk3399 can boot in efi mode, not capable of that)

If it was an efi booted system, that should have been noted
Or maybe it's just screwed up, but you say it boots
If I understand right, you did the dd commands in post 3, so that put everything
where it is supposed to be, the bootrom cares nothing about partitions or filesystems
It's just a raw load from locations defined by bootrom
Thinking some more,, it's a screwed-up partition table, that's all
To repeat, just because a partition is defined, that says nothing about what it contains,
can be all zeros, can be random data, can be anything, most often is a filesystem,
but that has to be specifically made, not just defined in fdisk/gdisk
A partition just defines a label to refer to a specific area of the disk
--edit--
This piqued my curiosity, went and checked packages txt
^f returned nothing for efi, there was a uboot package
So, since the bootrom controls where the initialization code is loaded from,
it's just a erroneous partition table
There is experimental efi for u-boot, I don't think this is what is happening here
#7
It's mounted with nothing in it.  I'm certain that if I filled it up, the system would no longer boot.

Code:
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk2p2   12M     0   12M   0% /boot/efi

At exactly 4MB into this partition, I see the uboot.img - exactly as flashed.

As near as I can tell, this is a partition that probably shouldn't have a filesystem header, and definitely shouldn't be mounted at runtime.  It does contain, at 4MB and 8MB into the partition, exactly what should be on the disk at 8MB/12MB (with the partition starting at 4MB).

Not sure where I should file the bug, though.  It's something in ayufan's built image.
#8
So has there been a proper tutorial on how to get deep sleep working on manjaro pbp?

t. complete noob at linux


Possibly Related Threads…
Thread Author Replies Views Last Post
  Kernel panics solostian 3 81 09-14-2021, 04:12 PM
Last Post: jiyong
  reset sound after suspend to memory (deep sleep) Der Geist der Maschine 14 3,851 09-10-2021, 10:15 AM
Last Post: JGkn
  Sound stuttering on Manjaro gnome after latest kernel upgrade? pjsf 1 284 08-27-2021, 06:09 AM
Last Post: bikerlatt1
  WORKING Moonlight with FFMpeg on 5.10.11 ShootTheMoon2 1 498 08-20-2021, 06:40 PM
Last Post: xmixahlx
  Please help...Pinebook Pro Night Color / mode not working :( sushilsharma71@gmail.com 13 1,097 08-16-2021, 05:16 PM
Last Post: sushilsharma71@gmail.com
  External USB C Monitor not working altacus 29 15,645 08-08-2021, 10:19 AM
Last Post: Dendrocalamus64
  Working suspend on Manjaro brzegorz 2 504 07-30-2021, 06:21 AM
Last Post: vssz
  Kernel panic on boot with danielt's Debian installer hjalfi 11 1,773 07-09-2021, 08:52 AM
Last Post: moonwalkers
  Kernel crash on Manjaro ARM mfashby 0 252 07-06-2021, 03:17 PM
Last Post: mfashby
  A true mainline Linux Kernel for the Pinebook Pro tsys 154 103,529 06-20-2021, 09:26 AM
Last Post: linuxad

Forum Jump:


Users browsing this thread: 1 Guest(s)