Move to newer kernel and fix suspend/sleep?

[RodBarnes]

Before moving to Breath, I had done a lot of testing of various distros using MrChromeBox's Legacy boot. One notable issue was that I ran into a number of suspend failures in distros that were using less than 5.15. In the distros that were at 5.15 or better, suspend worked as expected. So...

I'm wondering if moving to a 5.15 or better kernel would eliminate the suspend issue in Breath which led to forcing it to S3 instead of S1.

I should add that I don't really know what I am talking about here and haven't researched this. My suspend seems to work fine but I noted you indicated using S3 drained somewhat more power than S1.

[MilkyDeveloper]

There is a ChromeOS fork of kernel 5.15, but no devices are currently using it. I could build a "next" kernel that would be opt-in. My suspend isn't working at all.

[RodBarnes]

It might be interesting to pursue this. I'm willing to test it out. I'm currently researching system sleep states and thinking about playing around with mine via sysfs and the /sys/power files.

[RodBarnes]

In the docs (Bootlock) it states:

"To fix [the issue with not having a signed kernel and not being able to boot] in the Ubuntu rootfs (this has been enabled by default in Breath), the systemd config file for power and sleep had to be overriden to sleep to S3. Sleeping to S3 is slightly less power efficient.

I've been reading System Sleep States which indicates -- on ACPI -- that Suspend-to-RAM is mapped to S3 and Standby is mapped to S1. This seems to contradict what I understand from above; i.e., that suspend to NVRAM was forced to S3. Can you clarify this for me?

[MilkyDeveloper]

The System Sleep States are correct.

[EMLommers]

Running kernel 5.13 (non ChromeOS kernel) also fixes this issue. Had no problems on Apollolake, Tested on Debian, Ubuntu 21 & 22
Everything is working! Some adjustments for sound needed.

[RodBarnes]

@EMLommers Have you tested HDMI audio on your build? I have video but not audio. According to this, USB-C to HDMI audio is working via MrChromebox firmware so it appears it is fundamentally possible.

[RodBarnes]

[MilkyDeveloper]

You could change the contents of the .img file, but that would be massively inefficient. What I would do is run:

bash updatekernel.sh "PATH TO build.sh"

The direct-write method produces the same USB as the ISO method (provided you've ran expand.sh).

[RodBarnes]

Sorry, deleted the original post (because I thought I found a way to mount it) then found you had just replied. :-( I'll try your suggestion. For continuity, I have added my original post, below:

@MilkyDeveloper I'm pursuing this. I attempted to build the kernel following the instructions here using bash build.sh from ./kernel. The script ends by specifying how to extract the modules to the USB. If building the ISO (instead of direct to USB), how do we move the new built kernel modules to the image? So far, attempts to mount the image and update it have not been successful.

[RodBarnes]

I did a test and this seems to work. I ran setup.sh to create an ISO and then flashed it to a USB. I ran build.sh to build the kernel and then ran updatekernel.sh to update the USB. I went through my test suite and results were the same as I found with the original image from the commit. So, this model seems to work fine. Next, I'll try it with a newer version of the kernel.

[EMLommers]

I use build.sh quite very much It is not failsafe.. First build the ISO,  (Yours or iso's , am using iso from hexdump0815,is smaller (50%)(, but roofs is at /dev/sda4) Bun to USB,  rebluild any kernel ..bzImage.signed   dd to fist partition (or mode for hexdump0815) mount USB rootfs at /mnt and copy directory mod/lib/module/* to /mnt/lib/modules/* Some it does not work and modules are not loaded at start and depmod gives errors... reinstalling /building works  On Sat, 2022-04-16 at 11:30 -0700, AdvApp wrote:

…

Sorry, deleted this (because I thought I found a way to mount it) then found you had just replied. :-( I'll try your suggestion. For continuity, I have added my original post, ***@***.*** I'm pursuing this. I attempted to build the kernel following the instructions here using bash build.sh from ./kernel. The script ends by specifying how to extract the modules to the USB. If building the ISO (instead of direct to USB), how do we move the new built kernel modules to the image? So far, attempts to mount the image and update it have not been successful. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: <cb- ***@***.***>

[MilkyDeveloper]

What errors do depmod give? I cannot be able to fix this since this is from a different rootfs. This is not an error with build.sh.

[RodBarnes]

@MilkyDeveloper I was able to clone and build chromiumos from the v5.15.34 tag and then updatekernel.sh of the USB. But, of course, no audio initially. Running apl-sof-setup-audio fixes the audio but as the script downloads a different kernel, it wipes out what I did. So, I modified apl-sof-setup-audio to allow specifying a path to the kernel files on the command line; e.g., located on another USB, etc. Doing this worked: I am running the 5.15.34 kernel with audio working. But I've lost the snazzy "Breath" boot logo. :-(

I haven't figured out how to get the boot logo again. Is it something you've compiled into the bzImage that is downloaded?