ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
wolfshappen has quit [Ping timeout: 260 seconds]
wolfshappen has joined #armlinux
bochenchen has quit [Remote host closed the connection]
Nact has quit [Quit: Konversation terminated!]
amitk has joined #armlinux
Misotauros has quit [Read error: Connection reset by peer]
plappermaul has joined #armlinux
plappermaul has quit [Client Quit]
plappermaul has joined #armlinux
iivanov has joined #armlinux
iivanov has quit [Client Quit]
Misotauros has joined #armlinux
tre has joined #armlinux
cbeznea has joined #armlinux
iivanov has joined #armlinux
hanetzer has quit [Quit: WeeChat 3.5]
iivanov has quit [Quit: Leaving...]
iivanov has joined #armlinux
hanetzer has joined #armlinux
m5zs7k has quit [Ping timeout: 252 seconds]
iivanov has quit [Quit: Leaving...]
m5zs7k has joined #armlinux
viorel_suman has joined #armlinux
jn_ is now known as jn
mcoquelin has joined #armlinux
prabhakarlad has joined #armlinux
iivanov has joined #armlinux
Pali has joined #armlinux
apritzel has joined #armlinux
viorel_suman has quit [Ping timeout: 268 seconds]
viorel_suman has joined #armlinux
<mripard>
arnd: cmarinas: is there any restriction on the kernel size for arm64?
<mripard>
defconfig + mod2yesconfig is at 63MB, and with DYNAMIC_DEBUG it's at 66MB
<mripard>
so we're crossing the 64MB boundary, and it's a bit suspicious :)
<arnd>
mripard: I think it's usually a problem with where the boot loader places the kernel/initramfs/dtb, not with the kernel itself, though I'm sure there is a limit as well
<arnd>
roxell has been testing allmodconfig kernels for a while and managed to run into all kinds of limits with that
<arnd>
mripard: this is the built-in boot loader of the r-pi, not u-boot, right?
mupuf has joined #armlinux
<mripard>
I tested with the RPi bootloader, but I think Martin was testing with U-Boot
<arnd>
I'm sure we can boot kernels much larger than 64MB on other machines
<mupuf>
heya, Martin here.
<mupuf>
All the tests mentioned in the email were done on the RPi bootloader
<mripard>
ok, so I misunderstood what you were saying then :)
<mripard>
sorry
<mupuf>
np, I just decided to move on with my project and get u-boot EFI + iPXE working... because I did not suffer-enough
<mripard>
I wasn't using an initramfs, so I guess we can rule that out
<mupuf>
I was using the compressed image though, and you said you weren't
<arnd>
mupuf: I don't understand yet. Do you mean the problem goes away with u-boot EFI or you did you get u-boot to work at all?
<mripard>
and given that the machine model and RAM is properly detected in the logs, I think the DTB is properly found and parsed?
<mupuf>
arnd: Sorry for the confusion. Ignore anything involving u-boot
<mupuf>
(I did manage to boot a kernel with u-boot, but i needed to slim it down even more)
<arnd>
my point is that trying u-boot would be my first suggestion, to see if that has the same problem or not
<geertu>
With some versions you can fix it by changing the load addresses, with other versions you are out of luck
<mupuf>
I see. U-boot by default seems to only accepts kernels up to 36 MB, as per a comment in rpi.h
<arnd>
I would think that u-boot+grub EFI boot should avoid this, because grub is supposed to properly allocate non-overlapping memory areas. I have not tried this myself though
<geertu>
Make sure the load addrss is aligned to 2 MiB, and doesn't end in ...080000
<mupuf>
geertu: that's the logs I got from u-boot:
<mupuf>
Moving Image from 0x80000 to 0x200000, end=3240000
<mupuf>
ERROR: RD image overlaps OS image (OS=0x200000..0x3240000)
<geertu>
(The ...08000 found in may places was obsoleted by commit a2c1d73b94ed49f5 ("arm64: Update the Image header") in 2014)
<geertu>
s/may/many/
<mupuf>
I see :)
<mupuf>
I'll have to leave soon for a ~3h, then I'll try to figure things out. Knowing this may be related to overlapping segments is definitely helpful
<geertu>
mupuf: If you load at a multiple of 2 MiB, that move should be skipped
<geertu>
A while ago, I spent lots of time investigating what was being copied (and overwritten) by who, and when
<geertu>
That involved prefilling memory with a pattern from U-Boot, and looking into memory from U-Boot after a crash...
<mupuf>
right, reverse engineering firmwares do be like that... I feel your pain :s
rvalue has quit [Ping timeout: 255 seconds]
<geertu>
If DTB is too close after the kernel, the early kernel code to clear the BSS might clear the DTB, too
<mupuf>
any suggestion as to how close I should set it? I guess I should set it as close to the end of the address space as possible, right?
<mupuf>
as per a comment in rpi.h, it seems like u-boot is using only the first 128MB of RAM
<geertu>
If not all RAM is mapped, you indeed have a problem.
<geertu>
Beware putting it above 32-bit space, too
<mupuf>
sure :)
rvalue has joined #armlinux
<geertu>
I also ran into a case when U-Boot moved not only the kernel, but also the DTB, after which it could no longer find the DTB anymore
<mupuf>
would you advice me to use a compressed initramfs or uncompressed?
<mupuf>
my kernel is like 68MB, and my initramfs is about the same
<geertu>
Separate, or built into the kernel?
<mupuf>
separate
<geertu>
I'd say, the smaller the better
<geertu>
But all of that cannot fit in 128 MiB for sure?
<mupuf>
indeed, but isn't it the kernel decompressing the initramfs?
<mupuf>
compressed, it is 20MB
<geertu>
yes, the kernel decompresses it
<mripard>
on ARM it used to be the case, for arm64 it's the bootloader that decompresses it iirc
<geertu>
OK, 68 + 20 < 128
<geertu>
mripard: Possibly. I always embed mine in the kernel, if I use one
* mupuf
gotta go
<mupuf>
see you in a couple of hours
<mripard>
oh, I misread I thought you were talking about the kernel
cmarinas has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
cmarinas has joined #armlinux
nsaenz_ has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
wolfshappen has quit [Ping timeout: 244 seconds]
wolfshappen has joined #armlinux
dok has quit [Ping timeout: 255 seconds]
nsaenz has joined #armlinux
cbeznea has quit [Ping timeout: 244 seconds]
cbeznea has joined #armlinux
viorel_suman has quit [Ping timeout: 268 seconds]
iivanov has quit [Quit: Leaving...]
tre has quit [Remote host closed the connection]
dok has joined #armlinux
Misotauros has quit [Ping timeout: 244 seconds]
Amit_T has joined #armlinux
Misotauros has joined #armlinux
Nact has joined #armlinux
biju has joined #armlinux
cbeznea has quit [Quit: Leaving.]
guillaume has quit [Quit: Konversation terminated!]
nsaenz has quit [Quit: Leaving]
robmur01 has quit [Remote host closed the connection]
robmur01 has joined #armlinux
hanetzer has quit [Ping timeout: 268 seconds]
hanetzer has joined #armlinux
krzk has quit [Ping timeout: 255 seconds]
krzk has joined #armlinux
zx2c4 has quit [*.net *.split]
ide12 has quit [*.net *.split]
shoragan has quit [*.net *.split]
marshmallow has quit [*.net *.split]
Crofton has quit [*.net *.split]
steev has quit [*.net *.split]
robher has quit [*.net *.split]
robclark has quit [*.net *.split]
shoragan has joined #armlinux
Crofton has joined #armlinux
krzk has quit [Ping timeout: 252 seconds]
steev has joined #armlinux
robclark has joined #armlinux
robher has joined #armlinux
zx2c4 has joined #armlinux
marshmallow has joined #armlinux
ide12 has joined #armlinux
Misotauros has quit [Ping timeout: 240 seconds]
prabhakarlad has quit [Quit: Client closed]
headless has joined #armlinux
apritzel has quit [Ping timeout: 252 seconds]
Misotauros has joined #armlinux
biju has quit [Quit: Client closed]
plappermaul has quit [Quit: Client closed]
plappermaul has joined #armlinux
krzk has joined #armlinux
plappermaul has quit [Quit: Client closed]
Amit_T has quit [Quit: Leaving]
apritzel has joined #armlinux
mcoquelin has quit [Quit: Leaving]
headless has quit [Quit: Konversation terminated!]
amitk has quit [Ping timeout: 252 seconds]
sakman has quit [Remote host closed the connection]