narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki http://linux-meson.com/ - ml linux-amlogic@lists.infradead.org - official channel moved from Freenode - publicly logged on https://libera.irclog.whitequark.org/linux-amlogic
montjoie has quit [Ping timeout: 248 seconds]
montjoie has joined #linux-amlogic
Danct12 has joined #linux-amlogic
luka177 has quit [Ping timeout: 246 seconds]
hexdump0815 has quit [Ping timeout: 256 seconds]
hexdump0815 has joined #linux-amlogic
buzzmarshall has quit [Quit: Konversation terminated!]
Danct12 has quit [Quit: WeeChat 4.0.2]
Danct12 has joined #linux-amlogic
chewitt has joined #linux-amlogic
cornelius has quit [Ping timeout: 246 seconds]
luka177 has joined #linux-amlogic
cornelius has joined #linux-amlogic
luka177 has quit [Ping timeout: 252 seconds]
luka177 has joined #linux-amlogic
f11f12 has joined #linux-amlogic
luka177 has quit [Ping timeout: 246 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 246 seconds]
luka177 has joined #linux-amlogic
ndufresne5 has quit [Quit: Ping timeout (120 seconds)]
ndufresne5 has joined #linux-amlogic
luka177 has quit [Ping timeout: 246 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 245 seconds]
luka177 has joined #linux-amlogic
JohnnyonFlame has quit [Ping timeout: 256 seconds]
luka177 has quit [Ping timeout: 250 seconds]
JohnnyonFlame has joined #linux-amlogic
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 248 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 246 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 258 seconds]
JohnnyonFlame has quit [Ping timeout: 252 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 248 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Read error: Connection reset by peer]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 245 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 245 seconds]
Danct12 has quit [Ping timeout: 248 seconds]
Danct12 has joined #linux-amlogic
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 250 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 246 seconds]
luka177 has joined #linux-amlogic
f_ has joined #linux-amlogic
luka177 has quit [Ping timeout: 246 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 245 seconds]
luka177 has joined #linux-amlogic
naoki has quit [Quit: naoki]
luka177 has quit [Ping timeout: 250 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 246 seconds]
luka177 has joined #linux-amlogic
<f_> Looking at BL1 in Ghidra I see that it does load to 0xD9000000
<f_> but that comment in the BL2 sources tell that 0x1000 bytes is occupied by the header.
<f_> s/tell/tells/
luka177 has quit [Ping timeout: 245 seconds]
luka177 has joined #linux-amlogic
Nik has joined #linux-amlogic
Nik has quit [Client Quit]
luka177 has quit [Read error: Connection reset by peer]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 248 seconds]
Danct12 has quit [Ping timeout: 248 seconds]
Danct12 has joined #linux-amlogic
_whitelogger has joined #linux-amlogic
Danct12 has quit [Client Quit]
luka177 has quit [Ping timeout: 250 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 248 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 245 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 252 seconds]
luka177 has joined #linux-amlogic
f11f12 has quit [Quit: Leaving]
luka177 has quit [Ping timeout: 246 seconds]
<f_> Forget everything I said about the entry point.
<f_> It's indeed 0xD9001000.
<f_> (just wanted to be sure)
<f_> s/entry point/base address/
luka177 has joined #linux-amlogic
<f_> Ah, and for those curious, the base address is unchanged on gxl, so also 0xD9001000.
luka177 has quit [Ping timeout: 246 seconds]
<f_> ^ new gxl decompilation
<f_> While I'll work mostly on gxbb for the time being, I did fiddle around with gxl a bit.
luka177 has joined #linux-amlogic
<f_> Ghidra is such a powerful tool...
<f_> And I'll update my gxbb decomp...
luka177 has quit [Ping timeout: 260 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 250 seconds]
luka177 has joined #linux-amlogic
<f_> Hah!
<f_> gxbb BL2 does check the FIP header!
<f_> For some reason I thought it just hardcoded stuff but it does check the FIP header
JohnnyonFlame has joined #linux-amlogic
brooksytech has quit [Quit: Client closed]
luka177 has quit [Ping timeout: 256 seconds]
luka177 has joined #linux-amlogic
<f_> Sorry for the delay..had to fixup something in Cgit, but look at this
<f_> > if (_DAT_01400000 == -0x559bffff) {
brooksytech has joined #linux-amlogic
<f_> No idea what 0x01400000 is, but -0x559bffff
<f_> '0xaa640001'
<f_> >>> hex(-0x559bffff & 0xffffffff)
<f_> ^ FIP header "signature"
<f_> When I say FIP header I really mean TF-A FIP header.
luka177 has quit [Ping timeout: 246 seconds]
<f_> they read to that address
<f_> (0x1400000)
vagrantc has joined #linux-amlogic
<f_> Load fip header from SD, src: 0x0000c000, des: 0x01400000, size: 0x00004000
<f_> ^ no idea why though.
luka177 has joined #linux-amlogic
<f_> I think the check is just to see if it's the TF-A firmware image packaging being used or their new, proprietary one.
<f_> (gxbb bl2 might have support for the newer one...at least the string 'New fip header' is present in the binary)
<f_> but this alone makes me think that the FIP doesn't actually seem to be loaded by BL1 in the first place...
luka177 has quit [Ping timeout: 256 seconds]
luka177 has joined #linux-amlogic
<f_> Really makes you think
* f_ digs more into BL1 code.
<f_> Let's see...someone here previously said BL1 loaded the first 64K or something
<f_> I have a dump in Ghidra so let's see.
<f_> ret = read(0xd0072000,1,0xd9000000,0xc000);
<f_> narmstrong: BL1 reads the first 48K, so that doesn't include BL2
luka177 has quit [Ping timeout: 246 seconds]
<f_> I think it was you who said that it loaded the first 64K
<f_> Amlogic hardcodes the size of BL2 to 0xC000, so 48K
<f_> s/doesn't include BL2/doesn't include FIP/
<f_> but my BL2 should be considerably smaller...
<f_> -rw-r--r-- 1 thelinuxmacbook thelinuxmacbook 30K Aug 14 19:01 bl2.bin
<f_> 30K
<f_> Now let's look at amlbootsig's output
<f_> 0000c000: 0100 64aa 7856 3412 0000 0000 0000 0000 ..d.xV4.........
<f_> And considering that BL1 only loads from offset 0x200 on SD cards, which means on SD cards the hex dump offset will be off by 0x200...
<f_> it would be at offset 0xbe00, when loading from an SD card.
<f_> .....which was the offset I previously set
<f_> in TF-A BL2
<f_> one mistake though
<f_> ret = read(0xd0072000,1,0xd9000000,0xc000);
<f_> while in practise BL2's base address is 0xd9001000 BL1 actually loads everything to 0xd9000000!
<f_> aka. start of TZRAM
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 245 seconds]
<f_> So the offsets are actually right.
<f_> 0xc000 is where the FIP header resides.
brooksytech has quit [Quit: Client closed]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 244 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 245 seconds]
luka177 has joined #linux-amlogic
<f_> hmm
<f_> I should see `src += 512` but I don't...
* f_ looks at LibreELEC repo to see if the binary wasn't patched for the offset.
<f_> s/for the offset//
<f_> IIRC the binary is patched when building, only...
<f_> https://github.com/LibreELEC/amlogic-boot-fip/commits/master/wetek-play2/bl2.bin and this didn't get changed since...it was added....
<f_> Either way.
<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
zkrx has quit [Ping timeout: 246 seconds]
<f_> (some gxl BL2 binaries target AArch64 while others target AArch32...not sure why)
<samueldr> yeah, for the on-device ones I had started taking a lookg
<f_> you mean BL2?
<samueldr> (give me a sec, I'll gist something)
<f_> Sure.
chewitt has quit [Quit: Zzz..]
<f_> samueldr: https://moin.vitali64.duckdns.org/AmlogicBL2/GXL/Differences I documented that arch change here
<samueldr> I took a black box approach to start looking at things, to guesstimate stuff
<samueldr> using the LibreELEC repo of blobs
<f_> samueldr: aml_chksum is libre software: https://github.com/LibreELEC/aml_chksum
zkrx has joined #linux-amlogic
<samueldr> it was mostly a who's who, no judgement
<f_> bl1.bin.hardkernel is actually BL2 for the ODROID C2. it's used to patch gxbb BL2
<samueldr> to patch?
<f_> Yeah, gxbb bl2 uses a 512 offset for the header only for the SD card
<f_> and thus on eMMC that would override the MBR structure
<f_> Indeed.
<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]
JohnnyonFlame has joined #linux-amlogic