<josch>
f_: and the first 528 bytes are not really "random", no?
<f_>
oh yeah offset 0-0x200 are completly random
<f_>
The same @AML header is used for each image IIRC
<josch>
so i could as well zero those out and it would continue to work fine?
<f_>
which is why there's another diff in 0x78200..
<f_>
josch: Should work fine.
<josch>
oh wow
<josch>
what is the difference at 0x78200?
<f_>
also random bytes.
<josch>
XD
<f_>
if it's not part of any binary and just before @AML then it's random XD
<josch>
vkoskiv: would you be willing to try an u-boot with me having zeroed-out those bits? :)
<f_>
Normally with these zeroed out it should still work.
<josch>
i could just LD_PRELOAD something that lets /dev/random just return NULL when running the proprietary blob then
<f_>
the random bytes before offset 0x200 can be zeroed out for sure.
<f_>
josch: or..you could use something else :D
<f_>
Or..
<f_>
in the U-Boot docs you're supposed to write using dd and skipping everything before offset 0x200
<josch>
oh true, i totally forgot that we use dd bs=512 skip=1 to flash it
<josch>
then it doesn't matter anyways
<f_>
the diff in 0x78200 is written though
<josch>
so weird that somebody went through the trouble of actually filling those bytes with binary data instead of zero bytes XD
<f_>
¯\_(ツ)_/¯
<f_>
so weird that amlogic decided to implement a proprietary firmware packaging format for no reason
<josch>
f_: thanks a lot for your input -- i'll do more tests :)
<josch>
well... vkoskiv will do more test if they want to
<f_>
and implementing segfaulting utils for that..
<josch>
i'm just writing the scripts here :)
<f_>
remember:
<f_>
$ ./aml_encrypt_gxb
<f_>
Segmentation fault
<josch>
o0
<f_>
Seems like they fixed this in newer 'versions'
<josch>
i love tools without source...
<f_>
but I would use gxlimg anyway..
<josch>
yes, i'll see what happens when using gxlimg as well :)
<f_>
thanks to repk_ and many others who made gxlimg!
<josch>
one less binary blob in the stack is already an improvement :)
<f_>
Am working on replacing that BL2 blob BTW
<f_>
finally replaced it on gxbb/S905, now working on gxl/S905X
<f_>
Replacing it with U-Boot SPL :D
<f_>
one of the advantages is the fact that you only need one @AML header at the top for the bootROM to blindly run SPL..then you can use FIT for everything else.
<f_>
(that's probably about 1-2% of gxlimg?)
<f_>
As soon as it works on gxl I'll repeat for g12b and sm1 too (includes your A311D MNT Reform)
<josch>
thanks a lot for all you people's work -- it's so sad that it's necessary in the first place but thank you for putting your free time there!
<f_>
Np.
<f_>
Also thank many others who helped along the way!
* josch
spreads the good wishes to the rest of the crew
<f_>
gxlimg and others are good but they only try to fix some symptoms of proprietary boot firmware..
<narmstrong>
Yep spl as bl2 is the real solution
<f_>
On a side note..nice to see more happy A311D MNT Reform owners
<f_>
narmstrong: It's not. It's part of the solution.
<f_>
The other part of the solution would be reversing the SCP fw as well.
<f_>
and the last part of reversing BL31 was already done.
<narmstrong>
Yep bits and pieces are slowly coming together
<f_>
When before you thought a fully libre TF-A boot chain wouldn't be possible :D
* narmstrong
needs to send the uboot PR…
<f_>
Which U-Boot PR?
<f_>
ah that
<f_>
The usual u-boot-amlogic PR to master..
<narmstrong>
I didn’t thought it was even remotely possible
<narmstrong>
Yep this one, now ci passed
<f_>
Nic
<f_>
Nice
<f_>
Once I'm done with gxl I'll clean up the mess, test, and send patches upstream.
<f_>
Then I can work on g12b and sm1..
<f_>
oh forgot one last step before sending upstream
<f_>
Actually implement all of the DRAM init..so LPDDR support and DDR4 support need to be implemented
<f_>
Not sure if I have a board w/ LPDDR..DDR4 probably lafrite
<narmstrong>
it could be iterative, first support DDR3 on some socs/board then added the LPDD & DDR4
<f_>
I want SPL to boot on each amlogic board on my desk :D
<f_>
but yeah sure.
<narmstrong>
it's a nice goal !
<f_>
:D
<f_>
document it all in doc/board/amlogic/spl.rst or something like that
<f_>
Link to it in some pages..list the current known issues.
<narmstrong>
yep, good
<f_>
I also feel like someone should unify all the board pages
<f_>
there's too much duplication
<f_>
Have one page for signing and in the board page have a notice like: "Then refer to <signing page here>"
<narmstrong>
feel free to do this :-p
<f_>
Gotta do it myself
<narmstrong>
chewitt already did a good cleanup already, but yeah it would be great to cleanup
<f_>
>aml-s905x-cc: disable external vref and ddr print
<f_>
Aha.
<f_>
so no vref
<f_>
*external vref
<f_>
narmstrong: BTW is PXP an internal Amlogic thing?
<f_>
IIRC it's an emulator somehow.
psydroid has joined #linux-amlogic
psydroid has quit [Quit: Leaving]
psydroid has joined #linux-amlogic
<narmstrong>
Yes I think it’s their fpga based emulator
<f_>
sure
<f_>
But not sure why they include support for it in all BL2 binaries though
JohnnyonFlame has joined #linux-amlogic
buzzmarshall has joined #linux-amlogic
<narmstrong>
Laziness ?
<f_>
¯\_(ツ)_/¯
vagrantc has joined #linux-amlogic
f_|bnc has joined #linux-amlogic
f_|bnc has quit [Remote host closed the connection]
f_|bnc has joined #linux-amlogic
f_ has quit [Quit: zzz]
<f_|bnc>
<- new bouncer
<f_|bnc>
(for context)
f_|bnc is now known as f_
ldevulder has quit [Ping timeout: 240 seconds]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #linux-amlogic
<eery>
so I don't know much about analogue signals, but I'm getting this weird error on the A311D when displaying over HDMI: "Fatal Error, invalid HDMI vclk freq 593406"
<eery>
from what I can tell, it should be using the round number 594000 - is this an EDID problem?
<josch>
f_: overwriting the random bytes with zeroes indeed kept everything bootable
<josch>
seems i worried for nothing!
psydroid has quit [Ping timeout: 240 seconds]
psydroid has joined #linux-amlogic
psydroid has quit [Remote host closed the connection]