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
mraynal has quit [Remote host closed the connection]
mraynal has joined #armlinux
dliviu has quit [Quit: Going away]
dliviu has joined #armlinux
heat has quit [Ping timeout: 265 seconds]
alpernebbi has quit [Ping timeout: 276 seconds]
alpernebbi has joined #armlinux
npcomp has joined #armlinux
amitk_ has joined #armlinux
elastic_1 has joined #armlinux
elastic_1 is now known as elastic_dog
iivanov has joined #armlinux
amitk__ has joined #armlinux
guillaume_g has joined #armlinux
amitk_ has quit [Ping timeout: 260 seconds]
viorel_suman has joined #armlinux
tambarus has joined #armlinux
<tambarus> geertu: Hi! Regarding your CFI problem. I assume the CPU bringup code does not use any CFI code from mtd, is my assumption correct?
<tambarus> geertu: Would a deffered probe on CFI help?
cbeznea has joined #armlinux
sszy has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #armlinux
snalty has joined #armlinux
bps has joined #armlinux
bps has joined #armlinux
bps has quit [Changing host]
headless has joined #armlinux
apritzel has joined #armlinux
heat has joined #armlinux
heat has quit [Remote host closed the connection]
heat has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
jclsn has joined #armlinux
jclsn has quit [Client Quit]
jclsn has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
amitk_ has joined #armlinux
prabhakarlad has joined #armlinux
amitk has quit [Ping timeout: 252 seconds]
jclsn has quit [Quit: WeeChat 3.8]
jclsn has joined #armlinux
headless has quit [Quit: Konversation terminated!]
emanuellee has joined #armlinux
emanuellee has left #armlinux [#armlinux]
iivanov has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
iivanov has joined #armlinux
Pali has joined #armlinux
torez has joined #armlinux
monstr has joined #armlinux
luispm has joined #armlinux
amitk__ has quit [Ping timeout: 248 seconds]
biju has joined #armlinux
elastic_1 has joined #armlinux
elastic_dog has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
elastic_1 is now known as elastic_dog
<marex> arnd: ardb: Hi, how would the two of you feel about backporting cfa7ede20f133 ("arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely")
<marex> ?
<marex> basically the problem I have is Linux 4.19.y on ancient hardware with ancient software, which is still kept up to date via LTS
<marex> if I place the aarch64 Image at 0x200000 and try to start it, the kernel fails to boot
<marex> if I place the aarch64 Image at 0x80000 and try to start it, the kernel boots fine
<ardb> can you build with CONFIG_RELOCATABLE?
<marex> if I backport the aforementioned patch, the kernel boots fine
<marex> arnd: $ grep RELOCATA .config
<marex> ardb: ^
<marex> ardb: lemme check where this symbol was added
<ardb> so why don't you place the kernel at 0x80000?
<ardb> that was the requirement when v4.19 was released
headless has joined #armlinux
<marex> because spec Documentation/arm64/booting.rst says, 2 MiB alignment is the requirement
<marex> hence the 0x200000
<ardb> 2 MiB + TEXT_OFFSET is the requirement
<marex> 135 The Image must be placed text_offset bytes from a 2MB aligned base
<ardb> exactly
<marex> ardb: ah, so it is not multiples of 2 MiB , but "above 2 MiB" ?
<ardb> no 2 MiB aligned, + text_offset
<marex> still ... 0x80000 is below 2 MiB, it is 512 kiB
<ardb> 0x0 is 2MiB aligned
<ardb> so 0x0 + 0x80000 meets the requirement
<marex> oh, I see
<ardb> it's a bit silly, so that is why we removed it
<marex> it is confusing all right
<ardb> but bootloaders already take care of this
<ardb> why are you placing the image by hand?
<marex> U-Boot fitImage can place the Image at specified location
<marex> I placed it at the 2 MiB offset and the kernel stopped booting, but it did work fine at 512 kiB offset
<ardb> ah ok
<marex> ardb: but hum ... I would at least like the 4.19.y and 5.10.y to behave the same, so shall I track local backport of that TEXT_BASE=0 ?
<marex> I guess thats the best, since this is really archaic hardware and software stack
<marex> then I can always place the kernel at 2 MiB and it would work with both 4.19.y and 5.10.y and 6.1.y all the same
<ardb> that sounds fine
<ardb> the problem with backporting it is that it will break other loaders that assume TEXT_OFFSET=0x80000 without inspecting the header
<ardb> there were lots of those
<marex> ardb: yup, that is what I expected
<marex> ardb: all right, thank you for the clarification
<ardb> alternatively, you could enable CONFIG_RELOCATABLE, then it doesn't matter where you load it
<ardb> but you will get a warning in the log if you don't boot via EFI in that case
<marex> ardb: thats not in 4.19.y I think
<ardb> it should be, but it may not be user configurable
<ardb> we changed that at some point
<ardb> dd4bc60765873445893037ae73a5f75398a8cd19
<milkylainen> Do all archs support open ended kernel placement (regardless of relocatable)? iirc some powerpcs have a 64M tlb for placement?
<milkylainen> maybe that was removed.
<marex> milkylainen: I think arm32 has some 128 MiB limit
<marex> linusw__: ^ thank you for that
<marex> ardb: RELOCATABLE works too, thank you
<ardb> marex: excellent
<marex> ardb: is there any performance impact if I build the kernel as PIE ?
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<ardb> no but the image size will be larger
<ardb> it will be freed at boot, though, but it is significant
<marex> ardb: ah, thats fine, thanks !
heat has quit [Read error: Connection reset by peer]
heat has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
monstr has quit [Remote host closed the connection]
headless has quit [Quit: Konversation terminated!]
viorel_suman has quit [Quit: WeeChat 3.6]
cbeznea has quit [Quit: Leaving.]
<milkylainen> I was under the impression that PIE always came at some performance cost? Maybe not a relevant one (avg.), but surely it must affect something? Also, with randomization, isn't pie going to lead to slight variability in performance?
<HdkR> PIE is primarily a performance cost on 32-bit x86. On x86-64 and AArch64 it doesn't really matter
<HdkR> I don't recall AArch32 sadly :D
luispm has quit [Quit: Leaving]
<ardb> PIE linking is not the same as PIE codegen
<ardb> the AArch64 ISA is mostly position independent anyway, so we use PIE linking to link ordinary objects
headless has joined #armlinux
<ardb> which means you get the exact same code, the only difference is that statically initialized pointers are populated by the boot code instead of the linker
prabhakarlad has joined #armlinux
cbeznea has joined #armlinux
<milkylainen> hmm. right.
prabhakarlad has quit [Quit: Client closed]
biju has quit [Quit: Konversation terminated!]
<linusw__> marex: thx I was tearing my hair over figuring out how everything works...
prabhakarlad has joined #armlinux
apritzel_ has joined #armlinux
<marex> linusw__: Ive been sharing that and spreading praise on those articles left and right wherever I could , coz, they are truly good
guillaume_g has quit [Quit: Konversation terminated!]
amitk_ has quit [Ping timeout: 265 seconds]
torez has quit [Quit: torez]
apritzel has quit [Ping timeout: 260 seconds]
apritzel_ has quit [Ping timeout: 255 seconds]
headless has quit [Quit: Konversation terminated!]
Pali has left #armlinux [#armlinux]
iivanov_ has joined #armlinux
iivanov has quit [Read error: Connection reset by peer]
cbeznea has quit [Quit: Leaving.]
apritzel_ has joined #armlinux
dormito has joined #armlinux
dougg3 has quit [Ping timeout: 250 seconds]
dougg3 has joined #armlinux