<phh>
latest commit seem to say it's being used on Pixel 5?
<narmstrong>
phh: with a vendor v4l2 m2m driver and a custom gralloc and allocator :-)
<narmstrong>
pretty sure their pixel 5 v4l2 m2m driver doesn't pass the v4l2 compliance
<phh>
i see, thanks
kaspter has quit [Quit: kaspter]
vagrantc has joined #linux-amlogic
<damex>
is there now a way to boot amlogic board without binary blobs (at reduced functionality or something?) or we still stuck with blobs and there is no way around?
* vagrantc
is also curious about this question, having recently come up in debian-arm
<damex>
i manage to make builds for sunxi/rockchip boards just fine but amlogic is just pain to deal with
<damex>
all i am interested in is running headless debian on that amlogic board(s)
<chewitt>
there are blobs needed for early boot stages, but these are available for likely all of the board devices you'd be interested in supporting
<chewitt>
and the u-boot signing recipe is well understood
<damex>
so there is still no workaround exist that let you to -not-use-early-stage-blobs- ?
<adema>
You can build ATF for s905x (potato)
<adema>
but for the stages before ATF, you still need some blobs to setup the RAM etc
<chewitt>
IIRC there is support in ATF for GXL devices now, but the bl2 code is closed source so one way or another you still need some bits from the fip sources (as I understand it)
<damex>
chewitt: is there some kind of patch available based on fip sources that could be used or something?
<chewitt>
to do what?
<damex>
to do early init with bl2 without relying on vendor blobs
<damex>
bl1 is closed source and in soc (bootrom) -> bl2 is a platform init and is closed source (blob from vendor), bl31 is atf and is opensource and and bl33 is uboot and is opensource. what exactly is bl30/bl301?
<repk>
damex that is right. BL30/BL301 are firmware for the SCP
<repk>
usually a cortex-M processor that control power/frequency etc
<repk>
and bl32 is TEE (e.g. OPTEE).
<damex>
do we really need that cortex-M3 ?
<damex>
as far as i see it is supposed to be just <power management>
<damex>
repk: we don't really need bl32, aren't we?
<repk>
damex: no bl32 is not mandatory
<repk>
damex I think bl30 is mandatory, IIRC there is a security that prevents bl33 boot if bl2 is not present (I may be wrong here), also I think a lot of clock, boost/buck, etc are controlled by SCP.
CyberManifest has joined #linux-amlogic
<damex>
and bl30 is closed source too?
chewitt has left #linux-amlogic ["Adios!"]
chewitt has joined #linux-amlogic
<repk>
damex: yes but it is likely based on https://github.com/ARM-software/SCP-firmware. Also you need it to have frequency scaling and booting other CPUs (at boot time only one CPU is booted)
<repk>
besides that I think you can easily tweak bl31 to not boot it, don't know how usable the system will be though
<narmstrong>
It would need Linux support for DVFS and bl31 support for cluster enablement, not sure if we would be able to power up the clusters without the m3
<narmstrong>
The m3 handles all this
<narmstrong>
For bl2 it would need to reverse all the ddr setup, this is a huge task since the hw support a large range of ddr memories automatically
<chewitt>
I suspect they kept the bl2 code static, which is why we have separate firmware blobs in the fip sources
<chewitt>
blobs within the blob
<narmstrong>
bl2 is for the soc (they also provide some variant for some customers), the bl2 is "configured" with the acs binary containing a table to configure the ddr and system plls
<narmstrong>
the bl30 is fixed for soc and loaded in the m3, the bl30 can be extended with the bl301 which is open source and handles the system suspend
<narmstrong>
bl31 is fixed for the soc, and we have an open source implentation on upstrean tf-a
<narmstrong>
we can mix the closed source bl2 and open source bl31 because they use the standard tf-a interface
<narmstrong>
same for the optional bl32, we can either use the amlogic close source optee fork of the upstream optee, they conform to the tf-a bl32 loading interface and the standard kernel interface
<narmstrong>
I'll speak about most of this on my tommorow ELC-E talk :-)
<vagrantc>
a table with all the various parts mapped out would be useful, i think
CyberManifest has quit [Quit: Leaving...]
<cottsay>
narmstrong: Just wanted to take a moment to say thank you for giving the wiki page some love today. I know that kind of documentation can be tedious, but I really appreciate the per-release summaries and feature tables on there, and I'm sure I'm not alone.
<narmstrong>
cottsay: thx for seeing it !
<narmstrong>
xdarklight: used to fill the kernel update but he has a lot of day work recently
<narmstrong>
I need to update the graph up to 5.10
<cottsay>
Well I appreciate both of your efforts :)
<chewitt>
all we need is more people helping with the to-do list!
sputnik__ has joined #linux-amlogic
sputnik__ has quit [Ping timeout: 272 seconds]
sputnik__ has joined #linux-amlogic
<lvrp16>
chewitt: who is working on rtl8822cs again? I don't want to duplicate work.
drieschel has joined #linux-amlogic
drieschel has quit [Client Quit]
drieschel has joined #linux-amlogic
drieschel has quit [Quit: drieschel]
drieschel has joined #linux-amlogic
<narmstrong>
lvrp16: it’s xdarklight
<narmstrong>
Another good news, I managed to reverse engineer the G12 usb boot protocol and I did a refresh of pyamlboot readme https://github.com/superna9999/pyamlboot
<narmstrong>
Sadly it’s less flexible than before, we can’t load u-boot+kernel+rootfs at the same time, we need to load kernel+rootfs from Linux