<qschulz>
I thought you just showed interest about it
<marex>
I think apalos is the chief LMB guru expert here
<apalos>
marex: far from it, just cleaned up a bit
<apalos>
But I havent touched that are tbh
<qschulz>
so far what I can say is that this happens when i load a kernel at address X with TFTP (pxe_addr_r=X) and it's supposed to be loaded into kernel_addr_r at Y
<qschulz>
and X + Sizeof(kernel) > Y so it complains
<qschulz>
the thing I don't understand is why it still works :)
<qschulz>
like, I still boot the kernel image without any issue aside from the flooding
<apalos>
qschulz: there was enough refactoringlately, to make sure we dont overwrite stuff
<qschulz>
apalos: two possible choices, either it does ensure not overwriting and then this message is spurious, or it doesn't guarantee overwriting like we thought it would
<apalos>
So I might have typed that weirdly
<apalos>
We did change stuff to make sure we dont overwrite some EFI memory that we cant
<apalos>
But that seems irrelevant to your message
<qschulz>
marex: I think it'd be nice to have some DT property for specifying if a BL31 cannot receive params (which we need to do for Rockchip's blob)
<qschulz>
apalos: yup, not using EFI
<qschulz>
I haven't investigated much though :)
<apalos>
I dont know how what you see is triggered, but I have on my todo list to clean up lmb a little more
<apalos>
is there an easy way to reprod what you see?
<marex>
qschulz: keep in mind the BL31 load hook is board specific
<marex>
qschulz: that is why it is in boards/ , because every weird fork of TFA has its own weird quirks ... like params
<apalos>
qschulz: looking at it quickly you end up with 2 non adjastent LMB regions, but the first one is bigger than the second
<apalos>
Now why this "cant happen" I dont know unless I manage to reproduce it
<qschulz>
apalos: I would assume setting $kernel_addr_r to something 1MB above $pxefile_addr_r and then calling pxe get; pxe boot would trigger it for a KERNEL property of the selected label?
<qschulz>
apalos: do you have experience with setting up/using PXE?
<apalos>
yes, but that was like in 2000 :)
<qschulz>
apalos: not sure it changed much since :D
<qschulz>
essentially, you need a TFTP server
<apalos>
it hasnt i am pretty sure
<qschulz>
in your TFTP root directory, mkdir pxelinux.cfg
<apalos>
ok
<apalos>
So in theory I can simulate this pxe or not
<apalos>
I'll try and let you know
<qschulz>
cd into it, create a file named 0 (I think? otherwise something like default-somethingomsthing (pxe will tell you which files it's looking for))
<qschulz>
marex: I want the hook to be able to detect if the BL31 in the linux.itb requires to remove params or if I can pass some to it
<qschulz>
marex: it wouldn't make sense to have two flavors of U-Boot depending on the linux.itb you're expecting to load
<qschulz>
marex: however, this can be added later on, as this is currently what we need to do anyway :/
<qschulz>
(which is one of the reason it may not be easy to transition Rockchip boards to upstream TF-A)
<qschulz>
apalos: OoO now, but I'll be available tomorrow after 11am CEST
<qschulz>
apalos: I have chat history so i'll read tomorrow if i don't forget :)
<apalos>
no worries, i'll tryto have a look
<marex>
qschulz: that is the board specific goo I am talking about
<marex>
qschulz: it is the weird board specific special sauce that needs to be there to handle the weird forks of TFA ... sadly ... that is what I add in 3/3 for R-Car Gen4
<apalos>
anyone has arm hardware around to test an interesting security feature for me?
<apalos>
It should be just a case of compiling u-boot for it
<qschulz>
marex: will check what you're doing, but I believe we need properties in the linux.its so that we just read that property and know whether to pass params or not, instead of having SPL_ATF_NO_PLATFORM_PARAM
<qschulz>
marex: this probably means we'll need an ATF_NO_PLATFORM_PARAM symbol for Rockchip :)
<qschulz>
apalos: wdym?
<marex>
qschulz: again, look at 3/3 , seriously
<qschulz>
I have a few Rockchip (aarch64) boards
<marex>
qschulz: if you need no params, then your 3/3 is basically empty
<qschulz>
marex: ack, tmrw
<apalos>
qschulz: I have a branch that setsup the mmu properly
<marex>
qschulz: ltskptshrt
<apalos>
with properly memory mappings and permsssions, I just want to check if it blows up on any hardware