It would be nice to start building compressed arm64 kernels for eoan,
but it may have to wait a bit as the core boot-env won't yet handle this
correctly (that doesn't matter for core-16, but core-18 has arm64
images).
--
You received this bug notification because you are a member of Ubuntu
Bugs,
The needed flash-kernel changes landed in 3.98ubuntu2, setting to Fix
Released. Should we start looking into building compressed linux-raspi2
kernels for eoan?
** Changed in: flash-kernel (Ubuntu)
Status: In Progress => Fix Released
--
You received this bug notification because you are a
** Changed in: flash-kernel (Ubuntu)
Status: Confirmed => Fix Committed
** Changed in: flash-kernel (Ubuntu)
Status: Fix Committed => In Progress
** Merge proposal linked:
https://code.launchpad.net/~waveform/ubuntu/+source/flash-kernel/+git/flash-kernel/+merge/368844
**
I've put together an update for flash-kernel that handles booting an
uncompressed image (to support existing arm64 installs), a self-
compressed image (to support existing armhf installs), and a gzip'd
image (to support the proposed format). It assumes the kernel is called
"vmlinuz" in all cases
Thanks Paolo! We'll do that once we have everything in place. For now
Dave (the person responsible for Pi images) will do some tests to make
sure we're able to handle all the upgrade cases. But what we think will
have to happen is that we'd probably ask not to backport this change
into bionic and
On the kernel side, the switch to a compressed kernel is a trivial
change:
diff --git a/debian.raspi2/rules.d/arm64.mk b/debian.raspi2/rules.d/arm64.mk
index ada61b8..9f82433 100644
--- a/debian.raspi2/rules.d/arm64.mk
+++ b/debian.raspi2/rules.d/arm64.mk
@@ -3,7 +3,7 @@ build_arch = arm64
@p-pisati After discussing it with Steve and Dave, we have decided that
we'd like to switch to compressed images by default in linux-raspi2.
Yes, we might break some edge cases here, but in overall we only
officially support our own raspi images which we will be making sure are
still working
** Tags added: id-5c41a9213e4f370442b690db
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1808056
Title:
vmlinuz is very large in arm64 -raspi2
To manage notifications about this bug go to:
** Changed in: linux-raspi2 (Ubuntu)
Assignee: Paolo Pisati (p-pisati) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1808056
Title:
vmlinuz is very large in arm64 -raspi2
To
Yes, arm64 kernels don't have any decompressor build-in (and they'll
never get one) - i'm fine with your idea of compressing / decompressing
kernels upon installation (to avoid regression in corner cases) but i
would like (at some point in the future) to switch to compressed kernels
though (next
Paolo - so last time we talked about this, you mentioned that the arm64
kernel doesn't support decompressing the kernel on boot like the armhf
one. Is that still the case? Since I have marked the linux-raspi2 task
as 'Won't Fix' because of this. If yes, is there any way of having the
same
** Changed in: linux-raspi2 (Ubuntu)
Assignee: (unassigned) => Paolo Pisati (p-pisati)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1808056
Title:
vmlinuz is very large in arm64 -raspi2
To
Can kernel team elaborate on this ticket?
Cause as far as I can tell, we can change flash-kernel / boot.scr in
eoan, and kernels do support compressed images on armhf And rewrite
boot.scr on upgrade to eoan+
Is there something that I'm missing from shipping compressed kernels
here? Something
Armhf is already using zImage (and the kernel decompress itself once we
jump to it), so this is an arm64-only issue and no, there's no reason to
have vmlinuz uncompressed as long as the bootloader can handle it - i'll
send a fix to switch to Image.gz in Eoan.
--
You received this bug
** Tags added: id-5c3498019b64ea2312fd035e
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1808056
Title:
vmlinuz is very large in arm64 -raspi2
To manage notifications about this bug go to:
** Also affects: flash-kernel (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux-raspi2 (Ubuntu)
Status: New => Won't Fix
** Changed in: flash-kernel (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
@mwhudson I think those can get updated by flash-kernel actually. Not
sure if that works though as I did not have any occasion to test that.
But in theory the flash-kernel triggers, besides updating the kernel on
the boot partition, should also update the boot.scr script every time.
That being
** Tags added: id-5c102b896d5be615fa2824ee
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1808056
Title:
vmlinuz is very large in arm64 -raspi2
To manage notifications about this bug go to:
That said we just shipped a bunch of images with the original boot.scr
to a bunch of people and I don't think we have a mechanism for updating
the boot.scr on these images, although I would love to be wrong about
that.
--
You received this bug notification because you are a member of Ubuntu
So it seems after some testing that if one changes the boot.scr to this:
fdt addr ${fdt_addr_r}
fdt get value bootargs /chosen bootargs
setenv kernel_addr_r 0x0100
setenv ramdisk_addr_r 0x0310
fatload mmc 0:1 ${ramdisk_addr_r} vmlinuz
unzip ${ramdisk_addr_r} ${kernel_addr_r} ${filesize}
20 matches
Mail list logo
