Set image-max-size from custom config ?
Closed this issue · 14 comments
Hi,
i'm using a custom partition map on a speedy veyron, and need to override the default set in boards.ini.
However I didn't find how to change that in /etc/depthcharge-tools/config.d/speedy, this doesn't work:
[boards/arm/rk3288/veyron/speedy]
image-max-size = 33554432
(i changed the boards.ini file but am not happy with that).
Otherwise, I am very happy with depthcharge-tools.
There are still several patches needed to boot a c201, but once the linux-image deb is ready,
it makes installation seamless.
never mind, i'm full of $?!#
i'm using a custom partition map on a speedy veyron, and need to override the default set in boards.ini.
The size of the partition itself doesn't matter, the limit is due to depthcharge copying the contents from disk to a fixed-size memory buffer. Its size is set by a compile-time CONFIG_KERNEL_SIZE. Changing the value here won't help you unless you are using custom firmware or my best guess was wrong.
There are still several patches needed to boot a c201, but once the linux-image deb is ready,
it makes installation seamless.
Do you mean you need to use a custom kernel, or do I need to change something here? AFAIK, C201 shoud work nicely with mainline linux and therefore linux-image-armmp, but maybe needs some configs and initramfs module stuff...
Otherwise, I am very happy with depthcharge-tools.
I'm glad to hear that, thanks!
i'm using a custom partition map on a speedy veyron, and need to override the default set in boards.ini.
The size of the partition itself doesn't matter, the limit is due to depthcharge copying the contents from disk to a fixed-size memory buffer. Its size is set by a compile-time
CONFIG_KERNEL_SIZE. Changing the value here won't help you unless you are using custom firmware or my best guess was wrong.
I'm using libreboot. Maybe the difference comes from there.
There are still several patches needed to boot a c201, but once the linux-image deb is ready,
it makes installation seamless.Do you mean you need to use a custom kernel, or do I need to change something here? AFAIK, C201 shoud work nicely with mainline linux and therefore linux-image-armmp, but maybe needs some configs and initramfs module stuff...
Besides blacklist btsdio,
mainline kernel won't boot on several c201 without this patch.
Also cgpt is broken in debian/bookworm somewhere after version 0.88 which works.
For a similar reason: it fails to ignore first defective GPT header, and doesn't consider the backup.
I am currently trying other patches (from cadmium or prawnos) revolving around emmc issues and hdmi features, but I'm not sure they actually solve anything.
I'm using libreboot. Maybe the difference comes from there.
Yeah, libreboot r20160907 seems to use a newer version of depthcharge where the default limit was increased to 32MiB.
Also cgpt is broken in debian/bookworm somewhere after version 0.88 which works.
For a similar reason: it fails to ignore first defective GPT header, and doesn't consider the backup.
Oh wow, it looks like the start of eMMC is write-protected, and the first defective GPT cannot be fixed at all. I'll have to take a closer look at this because I call cgpt in depthcharge-tools to do some of the partition management stuff.
I added a warning about relying on the board.ini section names in 3c3a832. You should instead do something like:
[depthchargectl]
board = custom-speedy
[boards/custom/speedy]
arch = arm
codename = custom-speedy
dt-compatible = google,veyron-speedy
image-format = fit
image-max-size = 33554432
name = ASUS Chromebook C201PA (Libreboot r20160907)I'll continue with the cgpt stuff on the other issue.
I found out stock veyron Depthcharge doesn't tell Linux about the ramdisk in the FIT image unlike Libreboot. That made me think a bit, and I decided to add it to boards.ini instead of asking people to update configs every time something changes. Custom board sections should only be necessary for firmware development, not for published firmware/boards.
As far as I can tell, the HWID would be the same both in Libreboot and stock firmware, but flashing Libreboot would override the firmware ID. I tried to use that to detect it and use a Libreboot-specific config, but I'm not sure if that's correct.
Can you check a few things on the Librebooted veyron?
crossystem hwidshould return a real HWID, not something likeSPEEDY TEST 1-1crossystem fwidandcrossystem ro_fwidshould returnlibreboot-r20160907
And maybe test the master branch to see if anything else is broken if you have time for it?
Here it is
$ crossystem hwid
SPEEDY G2P-V6B-XXX-XXX (anonymized)
$ crossystem fwid
libreboot-r20160907
$ crossystem ro_fwid
libreboot-r20160907
yes, going to test master.
What custom config should I remove, to test it correctly:
/etc/depthcharge-tools/config.d/veyron
[boards/arm/rk3288/veyron/speedy]
image-max-size = 33554432
in cmdline I have:
[depthchargectl]
#board = <codename>
kernel-cmdline = gpt rootwait splash
that's all I had.
You can remove /etc/depthcharge-tools/config.d/veyron (should work fine with or without it), the cmdline is fine. Check depthchargectl config board to see if it detects the board as speedy-libreboot.
Ok, removed. And it does detect the board as speedy-libreboot.
update-initramfs -u worked perfectly, without anything unusual.
That's really cool. Note that debian will freeze in winter, so it might be a good idea to upload your package if you think it's ready ?
update-initramfs -uworked perfectly
sudo depthchargectl ends up falling back to the system installation for me, please double check that with sudo depthchargectl --version vs depthchargectl --version. What I usually do is:
$ depthchargectl() { sudo PYTHONPATH=/path/to/depthcharge-tools python3 -m depthcharge_tools.depthchargectl "$@"; }
$ depthchargectl list -v
$ depthchargectl write -v
# etc.
Note that debian will freeze in winter, so it might be a good idea to upload your package if you think it's ready ?
Yeah. I think I just need to update man pages, shell completions, then do a bit more testing.
The output looks right, thanks for testing!