<f_>
So I need to load the FIP from the SD card somehow
<f_>
since BL1 doesn't load it; it only loads BL2.
<f_>
While at it..anyone interested in my BL1 decompilation as well?
<f_>
if anyone is interested I can push that to a git repo
luka177 has quit [Ping timeout: 248 seconds]
<samueldr>
please do, public info is good info
<f_>
Sure
<samueldr>
people in the future may not be able to answer "yes" right now :)
<f_>
They might :) by sending me an email
<f_>
But I'll create a repo for that, sure.
<f_>
reversing-aml-bl1.git
<f_>
While at it, since BL1 dumps aren't easily accessible on the internet, I might also push the original dumps I made
<f_>
For lepotato,.....sure you could dump it yourself since it's fairly wide-spread in the Amlogic community
<f_>
but for the KII Pro.......doubt anyone on this chat has this board.
<f_>
(except me, of course)
<f_>
but either way, as far as I can tell there isn't much board-specific code in BL1, if at all.
<samueldr>
BL1 is what some other platforms refer to as BootROM, right?
<f_>
BL1 is the bootROM, yes.
<samueldr>
wouldn't it be expected that it's the same on a given SoC, except maybe discounting security fixes later down the line?
<f_>
Some people here refer to it as 'bootROM' while others refer to it as 'BL1'
<samueldr>
yeah, I just wanted to be 100% sure, not 99.99%, for the terminology :)
<f_>
samueldr: should be the same on a given SoC
<samueldr>
but still, do share, since even "common" ones may not be one that someone have on hand to check
<f_>
As far as I know only BL2 and later have board-specific stuff
<f_>
samueldr: I will.
<samueldr>
e.g. I think I have only an S805X, one S922X and two A311D on hand
<samueldr>
it'd be interesting to see if there is a clear "update path" they went with for their BootROM, and trace a more or less direct lineage between revs
<f_>
I used to only have one S905 board (that set-top box) but now I also have lepotato (mentionned before, too) and lafrite
<f_>
samueldr: doubt it
<samueldr>
I wouldn't expect them to restart anew for every SoC
<samueldr>
but it may be hard to guess at a lineage depending on how much there is
<f_>
You're right. They use mostly the same codebase for every BL blob across most of their 64-bit SoCs
<samueldr>
especially since I assume there won't be something like a build date or version right there
<f_>
Fourtunately their blobs rarely change across revisions, with the exception of some gxl BL2 binaries which changed dramatically
<samueldr>
though yeah, those are really raw notes, I have some more in another file (even more raw) for stuff I still needed to look at
<samueldr>
other stuff were pushed onto my stack since :)
<f_>
but yeah, it's a huge mess
<samueldr>
the goal was that until vendor mess can be unmessified, I wanted to understand how much cargo-culting there was vs. actual needed stuff
<f_>
But it seems like most bl2 binaries are interchangable...
<samueldr>
that was indeed sparked by you saying that
<f_>
For instance, my KII Pro works perfectly fine with the WeTek Play2 binaries.
<samueldr>
for example... it's odd how all the ram blobs are basically always added
<f_>
Most board-specific mods are in either bl21 or bl301 or acs
<samueldr>
when also they're always the same
<samueldr>
yeah
<f_>
BL2 also has ACS structures inside already
<samueldr>
one thing you might know from your BL1 shenanigans: is it looking at more than one offset on SD and eMMC?
<f_>
xxd bl2.bin | grep acs__
<samueldr>
if they look at offset 0 for all, there may be something useful that can be done down the line to use GPT
* f_
looks at BL1 decomp.
<samueldr>
I'm not actually hopeful really
<samueldr>
but anything else than LBA1 (offset 512) can help
<f_>
One change between gxbb and gxl is the fact that that gxbb offset issue has been fixed.
<f_>
eMMC offset is 512 too, now.
<samueldr>
yeah, I assumed
<samueldr>
I assume that was because of mmcboot stuff being accidentally conflated into the main storage?
<f_>
Probably not
<samueldr>
[though for emmc we can use mmcboot, so it's more about SD really]
<samueldr>
I mean, they use 512 now(?) on mmcboot too, so I assume they meant it to be installed only to mmcboot, on eMMC
<f_>
No I meant
<f_>
the @AML headers are to be found at offset 512 on eMMC too.
<f_>
What I was talking about is the fact that having the @AML header at offset 0 on eMMC complicated things regarding partitioning.
<f_>
But this was fixed on later SoCs.
<samueldr>
yes
<f_>
Not sure about GPT though
<f_>
but I have no idea how useful GPT could be on SD cards or eMMC..
<samueldr>
I meant that on gxbb, I suspect/assume that they used offset 0 (LBA0) on eMMC because they meant it to be used on mmcboot
<f_>
when running mmcboot?
<samueldr>
the mmcboot hardware partitions
<samueldr>
well, GPT can already be used when the storage media is not "shared" with the os sotrage location
<samueldr>
so it's really only for SD
<f_>
@AML headers are only used by BL2
<f_>
(and BL1)
<samueldr>
yeah, it's the BL1 part that is really problematic here AFAIUI
<f_>
if that's what you meant?
<samueldr>
if post-gxbb looks for them at any additional offset than 512 (LBA1) that would mean there's hope
<samueldr>
but if you don't know, no worries
<f_>
the @AML header offset seems to be fixed, sorry.
<f_>
hardcoded
<samueldr>
aw, some vendors (allwinner, rockchip IIRC too) look at a couple offset for the next stage
<f_>
it's either 512 on eMMC or SD or 0 on the rest (SPI, NAND, ..)
<samueldr>
bummer, if they'd had checked at literally any other location, it would mean that there is a way to control the process from anywhere else, and thus solve it
<samueldr>
but LBA1 is the location where the GPT header is
<samueldr>
at LBA0, the same trick that the bl"1".bin.hardkernel could have been used, and at LBA2 until LBA34 there are "tricks" or actual methods (all in spec) to solve that with GPT
<f_>
Either way, I doubt using GPT on eMMC or SD brings any benefits.
<samueldr>
that's an opinion, though, and really there are in the end, mainly with regard to more "complex" layouts requiring more partitions, extended partitions don't really fit the bill
<samueldr>
but I agree that for many situations, especially simpler ones, there's not much difference
<f_>
I mean, sure, GPT has its benefits...but for most situations there's not much difference.
<f_>
As you said
<f_>
and either way I doubt Amlogic ever cared about GPT
<samueldr>
they have to, due to android, no?
<f_>
no
<f_>
U-Boot supports booting Android
<samueldr>
sure
luka177 has joined #linux-amlogic
<samueldr>
that's orthogonal
<samueldr>
so they're not using a layout that requires more than 4 partitions? (or extended partitions?)
<f_>
No idea
<samueldr>
I haven't had a look at an android image for amlogic
<f_>
Haven't looked much into that
<samueldr>
so, the reason about all that is one of the things I try to do is actually dig into "folklore" knowledge about platforms, and smash myths
<f_>
but looking at what they did for gxbb, and the lsblk output I got while still running Android on my KII Pro, ...
<f_>
Well, first, apart from boot0 and boot1, there were no partitions detected :P
* f_
is an idiot.
<samueldr>
maybe not, but do elaborate
<f_>
I tried to use memmap for the FIP, in TF-A BL2....
<f_>
but, as mentionned above, the FIP doesn't get loaded by BL1, at all
<f_>
and memmap just tries to use whatever's on memory....thing is...well.......there's no FIP loaded to memory!
<f_>
and so I must've used the mmc driver instead..lol
<f_>
to actually load the FIP...
<f_>
so I was actually trying to load images out of ...well...nothing!
<f_>
s/out of/from/
<f_>
That was obvious and yet.....
<f_>
either way..
<f_>
TODO: properly make use of the mmc driver to load the fip header
<f_>
and post BL1 decompilation files
<f_>
Tomorrow
<f_>
Bye!
f_ has quit [Quit: Disconnecting.]
jacobk has quit [Ping timeout: 252 seconds]
luka177 has quit [Ping timeout: 258 seconds]
luka177 has joined #linux-amlogic
f_[xmpp] has quit [Ping timeout: 246 seconds]
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 248 seconds]
JohnnyonFlame has quit [Ping timeout: 246 seconds]