buzzmarshall has quit [Quit: Konversation terminated!]
GNUtoo has quit [Ping timeout: 255 seconds]
GNUtoo has joined #linux-amlogic
chewitt has joined #linux-amlogic
JohnnyonFlame has quit [Read error: Connection reset by peer]
jelly has quit [Remote host closed the connection]
<chewitt>
jbrunet: I have noticed the following patch in numerous downstream repos and am wondering if it's something I should pick to my branches or ignore?
<chewitt>
(used by LE, Armbian and a few other distros)
<chewitt>
there is currently zero upstream linux support for A311D2 and in-part due to the boot regime Amlogic is now using, that's unlikely to change anytime soon
<chewitt>
there are significant differences between A311D (well supported) and A311D2 (zero support)
<chewitt>
and since upstream linux support generally needs to come before upstream u-boot support, there's zero A311D2 support there too
<chewitt>
everything you can find for A311D2 in Khadas repos is based on their downstream fork of Amlogic's downstream fork
<chewitt>
Amlogic's fork is their 3.10 BSP forward ported to 3.14 forward ported to 4.9 forward ported to 5.4; with a massive cull of support for older hardware between 4.9/5.4
anessen97 has joined #linux-amlogic
<rah>
*facepalm*
<rah>
ffs
<rah>
chewitt: so S922X/A311D also require signed u-boot binaries?
<chewitt>
"all Amlogic hardware since at least Meson8 (c.2012) requires some form of signed u-boot binary"
<chewitt>
to be fair on Amlogic .. most ARM SoC using boards require some form of vendor signing or firmware in the boot process
<chewitt>
so they are hardly unique in the requirement
<phh>
hello, i have a nit bug in mainline, not sure if that's the right place: ticking "amlogic meson g12a ao cec driver" but not "amlogic meson ao cec driver" has the same as not ticking it, because drivers/media/cec/platform/makefile includes the subfolder only if the later is ticked, not the former
<rah>
chewitt: when were the S922X or A311D released?
<rah>
chewitt: most Arm boards requiring binary blobs to boot is news to me
<chewitt>
2018/2019 IIRC
<narmstrong>
rah: nop the binaries aren't signed, there's a signature added by closed source tools to permit booting, but there's open source tools who does the same signature
<narmstrong>
phh: indeed, can you send a fix for that ?
naoki has quit [Quit: naoki]
<rah>
narmstrong: OK but it sounds like the binary blobs are still required?
<narmstrong>
rah: yep, there's no open source version of the BL2 which setups the DDR, neither the SCP co-processor firmwares
<rah>
:-/
<narmstrong>
rah: I welcome you to reverse-engineer those !
<rah>
I'm sure you do :-)
<rah>
I bought an Orange Pi 5 with an RK3588 and third generation Valhall Mali GPU, only to find out that the third generation Valhall introduces a new proprietary firmware; so I bought a VIM4 because it uses the earlier generation Mali GPU with no need for proprietary firmware.. only to find out that it needs proprietary firmware in order to just *boot*
<rah>
what a nightmare
<rah>
anyone want to buy a VIM4? :-)
<narmstrong>
and vim4 is very far from beeing supported by mainline linux or u-boot
<narmstrong>
I have 2 in my closet, will probably be never used
<rah>
I could live with only the expectation of mainline support but proprietary blobs are a show stopper
<rah>
looks like RK3399 is my best bet
<narmstrong>
well, I'm exactly the opposite :-p
<rah>
to each his own :-)
<narmstrong>
you can't really erradicate firmware, it's a lure, but we can build proper system support for thos socs
<jbrunet>
chewitt: The patch mentioned is certainly something I would nack as is. The issue mentioned is with HDMI. There is no reason to restrict FRDDR caps based on HDMI needs. Either patch the HDMI codec or the synopsys hdmi. It is Alsa's job to deal with the contraints of all the elements in the pipeline. Plus it patches the axg, which has no HDMI ...
<chewitt>
jbrunet: thanks .. I'll ignore it for now
<chewitt>
jbrunet: do you have any examples of mixer settings for toacodec/headphone output on a g12b board?
<chewitt>
hdmi is working fine
<chewitt>
but the config for the headphone socket is eluding me
<jbrunet>
It is exactly the same as tohdmi, then you have to unmute and turn on the volume of the codec
Terry137322934 has quit [Ping timeout: 260 seconds]
f_ has joined #linux-amlogic
<f_>
Hello!
<f_>
Is there specific kernel configurations to do for successfully loading a Linux kernel on an Amlogic S905D SoC?
<f_>
s/Is/Are/
<f_>
Are there specific kernel configurations to do for successfully loading a Linux kernel on an Amlogic S905D SoC?
<f_>
I'm trying to port postmarketOS ( https://postmarketos.org ) on a KII Pro TV Box which has support in mainline.
<f_>
Ok first.
<f_>
How do I compile U-Boot for it to boot up properly on it?
shoragan has quit [Read error: Connection reset by peer]
shoragan has joined #linux-amlogic
<narmstrong>
f_: KII Pro TV Box isn't supported in u-boot , you may boot the kernel directly from the flashed uboot
<narmstrong>
f_: concerning the config, arm64 defconfig should work
<f_>
After all, it's quite a lot like the P201 reference board I guess.
<narmstrong>
yes
<f_>
As in, very similar specs.
<f_>
Also Armbian has working U-Boot images, however there are no instructions for reproducing those images.
<rah>
narmstrong: eradicating "firmware" is one thing; running a system with an empty /lib/firmware is something else, and doable with an RK3399 it would seem
<f_>
Also, speaking about the kernel, Alpine's linux-edge uses the arm64 defconfig right?
<rah>
presuming you don't want to use a DisplayPort controller
<narmstrong>
rah: empty /lib/firmware is possible on amlogic socs if you don't want hw accelerate video decode
<f_>
Oh wait hardware acceleration is supported?
<f_>
Awesome!
<narmstrong>
there's a lot of rough edges, but it works for most usescases
<f_>
Sure.
<f_>
I'll have to take a look at Alpine's linux-edge APKBUILD to see if they use the arm64 defconfig for their kernel though.
<rah>
narmstrong: OK, let me rephrase: eradicating "firmware" is one thing; running a system with an empty /lib/firmware and no binary blobs in u-boot is something else, and doable with an RK3399 it would seem :-)
<narmstrong>
rah: well it's great then!
<f_>
narmstrong: When I try loading the linux kernel the TV Box bootloops. Did I miss something?
<narmstrong>
f_: do you have the uart log ?
<f_>
And when I'm using Armbian's U-Boot image I see there's an error.
<f_>
narmstrong: Nope. But I do get meaningful logs out of Armbian's U-Boot image.
<f_>
Honestly I might have missed something.
<narmstrong>
yep probably
* f_
checks notes
<narmstrong>
check the changed added to build the armbian image, perhaps some changes that weren't upstreamed
<f_>
I get a synchronous abort when starting the kernel.
<narmstrong>
oh yeah, do you use the plain Image or an uImage ?
<f_>
I use the uImage generated by pmbootstrap.
<narmstrong>
hmm so it should be ok then
<f_>
I can try regenerating one though.
<f_>
Maybe pmbootstrap didn't generate it correctly?
<f_>
So the KII Pro uses U-Boot as its bootloader?
vagrantc has joined #linux-amlogic
<chewitt>
all Amlogic TV boxes use u-boot .. the only thing that changes over time is the vintage and hacking the vendor did
<chewitt>
all s905d boxes will be using ye olde Amlogic 2015 u-boot
<chewitt>
the vendor 100% fiddled with things like ddr timing (to match ram chip binning) which makes it tricky to recreate all the bits needed for upstream u-boot support
<chewitt>
although ISTR that hexdump hs some instructions/notes on that in his repo
<chewitt>
if you are not scared at the idea of shorting pins on the emmc storage you can build u-boot using the p200 or p201 recipe and substituting the right dts for your box
<chewitt>
shorting will allow you to disable emmc and thus force the box to boot from an SD card
<chewitt>
or .. you do what LE does and just hook the vendor u-boot to run your kernel
<f_>
Yeah I'll just hook the vendor u-boot. That's much easier.
* f_
puts that in notes
<f_>
So:
<f_>
* Build U-Boot
<f_>
* Sign U-Boot using the FIP sources
<f_>
* Yay
<f_>
Right?
<chewitt>
nope
<chewitt>
I would borrow the precompiled boot scripts from Armbian, which should have the same kernel packaging as postmarketOS
<chewitt>
(not knowing pOS at all, but likely the same)
<chewitt>
then you avoid anything to do with u-boot
<f_>
Sure.
<chewitt>
in all cases you don't need to sign anything because you aren't booting upstream u-boot
<chewitt>
LE also has scripts, but our kernel packaging is a little different (nitramfs compiled in)
<f_>
Sure.
<f_>
postmarketOS still bootloops.
<f_>
Weird.
vagrantc has quit [Quit: leaving]
vagrantc has joined #linux-amlogic
hexdump0815 has joined #linux-amlogic
<hexdump0815>
i think i heared my name from the distance :)
<hexdump0815>
first thing to keep in mind regarding s905: its boot blocks are not very partition table friendly on the emmc, so better do not try to partition the emmc
<chewitt>
I'm able to boot S905 from emmc using upstream u-boot these days (all possible with the right FIP sources)
<chewitt>
(coexisting with the usual fat boot partition, etc.)
<hexdump0815>
chewitt: i remember there was something meanwhile :) ... just that i prefer arm chromebooks over arm tv boxes these days - musch better and more reliable hardware :)
<chewitt>
more eyeballs and resources supporting them for sure
<hexdump0815>
iirc it was not that easy for the older boards
<hexdump0815>
i experimented with mainline u-boot on quite a few gxl, gxm, g12a and sm1 boxes and it mostly worked for all of them - some even with mainline atf, but most with extracted legacy atf
<chewitt>
with tv boxes you need to preserve power-on via IR stuff which generally means sticking to legacy atf bits
<hexdump0815>
but its always a risk to brick the box - it always good to find the emmc clock pin before experimenting and that hdmi dongle thingy from narmstrong helps in some situations as well :)
<hexdump0815>
i'm not using the boxes with remote, so power-on is power plug in and power-off is power plug out :)
<hexdump0815>
but for most types there is no real mainline atf - i think only for gxl and g12a i think
<chewitt>
maybe. it's not a priority for me to investigate
<hexdump0815>
chewitt: that pull request is really nice - so maybe i should pull out my nice old rx01 box with s905 with 32g emmc and give it a try
<hexdump0815>
... one day when i get too bored
<chewitt>
if you have the FIP sources for it .. sure
<chewitt>
the p200/p201 sources in the FIP repo don't seem to work on many boxes (based on anecdotal reports)
<chewitt>
box vendors always end up fiddling with ram timing in acs.bin
<hexdump0815>
oh - got it - i was thinking that the patching was done in the binary - but of course this would maybe break the signing and not be possible with crypted boot
<hexdump0815>
maybe its time to give those old boxes a rest - its still posibble to simply boot from sd card and use the emmc partially unpartitioned
elastic_dog has joined #linux-amlogic
elastic_dog is now known as Guest218
<chewitt>
yeah
<chewitt>
anyway.. time for Zzz here, it's late
<hexdump0815>
good night
<f_>
Sure
<f_>
:)
f_ has quit [Quit: Lost terminal]
ldevulder has quit [Remote host closed the connection]