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."
06-13-2020, 02:40 PM
(This post was last modified: 06-13-2020, 02:49 PM by Syonyk.)
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...
06-14-2020, 02:31 PM
(This post was last modified: 06-14-2020, 02:50 PM by Syonyk.)
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
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)
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)
06-14-2020, 08:46 PM
(This post was last modified: 06-14-2020, 10:00 PM by wdt.
Edit Reason: trying to make sense out of a very confused situation
)
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
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.
So has there been a proper tutorial on how to get deep sleep working on manjaro pbp?
t. complete noob at linux
|
