<Xogium>
sorry for yesterday, disease acted up again and it all went to hell
<Xogium>
and my beyerdynamic headphones finally died after almost 10 years
<peterm6881>
dont apologise, you have nothing to apologise for
<peterm6881>
oh no, disaster
<peterm6881>
whats the problem with the Beyers?
<Xogium>
yeah these headphones are absolutely awesome… but there's one major flaw… The non detachable cable
<peterm6881>
I could probably replace that
<peterm6881>
stick em in the box with the other thing
<peterm6881>
ok I think I can cheer you up, a BIT
<Xogium>
like they can be fitted with new earpads, with a new headband, you can even replace the sound drivers
<Xogium>
just… not the cable
<peterm6881>
I have some good news
<peterm6881>
dont throw them away, i could probably solder a new cable
<peterm6881>
we figured out why the audio doesnt work on the HATs
<Xogium>
nice
<Xogium>
why was that?
<peterm6881>
Pin 1 is a Shut Down pin labelled SD, you tie it to ground to turn the amplifer off, like when muting or during boot to prevent pops and bangs
<Xogium>
ah yeah
<Xogium>
like some reset gpio?
<peterm6881>
well, what the datasheet DOESN'T tell you is you cant leave it floating
<Xogium>
woops
<peterm6881>
it has to be tied high for the amplifier to work
<Xogium>
I knew jlcpcb wasn't dumb enough to fuck up your audio every time while putting your hats together
<peterm6881>
its nobodys fault, it just wasnt made clear in the Shut Down section of the datasheet, and the Typical Application circuit we used doesnt show anything connected to it
<Xogium>
right
<peterm6881>
so id say it was bad documentation. I got Arslan to compare the HAT that Nisal Dinuke designed for me, witht eh USB GPS, and in which the audio worked, to see if he could spot a difference
<Xogium>
well the good thing is that at least now you know
<peterm6881>
obviously that was it
<Xogium>
yeah
<peterm6881>
with the *
<peterm6881>
the PCB speaker works great, very clear
<peterm6881>
ok I have other news
<Xogium>
so is this something you could fix at home or will you need to do another batch?
<peterm6881>
Yeah I can fix the existing boards with a 10k resistor between Pin 1 and the 3.3 V supply
<Xogium>
coolness
<peterm6881>
boom, up it comes
<Xogium>
no crackly audio?
<peterm6881>
ive only modified one of the interim boards so far, with the weedy audio, its only 1 Wattt
<peterm6881>
the new board has the 2.5 Watt amplifer so we should be able to drop the DAC Master volume, which will get rid of the crackles
<peterm6881>
Watt
<Xogium>
ah good
<peterm6881>
the crackles only came in because we had to crank up the Line Out and DAC volume to maxuimum
<peterm6881>
maximum
<Xogium>
yeah I remember that
<peterm6881>
it was never an issue when we used the OEP3W amplifier modules
<Xogium>
yeah like that speedsaver you sent me
<Xogium>
I think I have the first one you had made, with the louder amp
<peterm6881>
and the newer HAT uses the same PAM8302A 2.5 Watt mono amplifier chip
<peterm6881>
exactly
<peterm6881>
louder amp, plus a far and away better speaker
<Xogium>
oh yeah it can get very very loud lol
<peterm6881>
:)
<peterm6881>
i have more news
<Xogium>
I remember when we had the alarm sound at bootup, I went all the way at the other end of the flat to get something once, and I heard the alarm very clearly
<peterm6881>
still not an external tree, but thats progress right? ;)
<Xogium>
yeah sure
<Xogium>
that is already much better
<peterm6881>
Ok I took another look at the unframework issue
<peterm6881>
I dont think its a problem of whether uart ports are enabled or not, or which one is selected
<Xogium>
well .ike I said the mangpi dts has uart1 enabled
<Xogium>
the nano has uart0 enabled
<peterm6881>
if you look at that MangoPi board/widora/mangopi/r3/devicetree/linux/devicetree.dts its all ttyS0
<Xogium>
that doesn't mean that uart1 can't be ttyS0
<peterm6881>
ahh yeah ...
<Xogium>
it would be ttyS1 if uart0 was also enabled
<peterm6881>
can you fix that?
<Xogium>
yeah, probably doable
<Xogium>
I mean I don't see why not but I might do a totally different board so that tree would work for both lichee nano and mangopi
<peterm6881>
I closed the issue because I though I found the problem, I copied MangoPi's menuconfig settings for System configuration > Run a getty (login prompt) after boot
<peterm6881>
but it didnt make any difference
<Xogium>
no it wouldn't
<Xogium>
like I say, this item config is just for *after* boot, actually. You have to know in advance which port your serial console is on
<peterm6881>
if I reopen the issue, what should I tell unframework he needs to do if he wanted to make his repo compatible with both?
<Xogium>
but if your device tree says uart0 while the uart bridge is connected to uart1 which isn't enabled
<peterm6881>
by the way florpor's repo that unframework based his on is based on 2020.02.1, whereas unframworks is based on 2020.02
<peterm6881>
unframework's *
<Xogium>
yep they are both lts, and both just as dead
<peterm6881>
also, florpor's builds an image that is 69 MB, whereas unframework's image is 19 MB, so there's way more stuff in there
<Xogium>
the difference with unframeworks is that it's just an external tree, and you can just use mainline buildroot with it
<peterm6881>
i tried building unframeworks with the latest LTS, but it failed, i think a version number just needs updated or something
<Xogium>
nah its more likely you've got legacy options in your config
<peterm6881>
no im familar with that
<Xogium>
that's the only stuff I've had to fix in my case, when I built with 2021.02.8
<peterm6881>
ahh ok, if it worked for you thats interesting......
<Xogium>
that and the fact the post-image script or post-build don't recall which, was not executable
<peterm6881>
so, wheres the low hanging fruit here
<peterm6881>
I know mangopi's build is based on a dead LTS, but it works
<peterm6881>
and its from the vendor
<peterm6881>
and hes responding
<peterm6881>
is THAT the low hanging fruit at this point in time
<Xogium>
probably yes
<Xogium>
until mainline gets better
<peterm6881>
good, we have a pathway then
<Xogium>
yeah I'll just need to patch u-boot to fix this error on gcc >= 10
<Xogium>
but beyond that
<peterm6881>
are you feeling up to it?
<Xogium>
yeah sure
<Xogium>
how fast did it boot, anyway?
<peterm6881>
let me check
<peterm6881>
wait
<Xogium>
like from the momment you plug power in to the login prompt, how much would you say
<peterm6881>
just a sec, need to re burn the sd, it still has unframeworks image
<peterm6881>
109 MB in there...so all the toys
<peterm6881>
12 seconds
<peterm6881>
from power up to login prompt
<peterm6881>
well, from rst to login prompt
<Xogium>
that isn't bad at all
<peterm6881>
since the bridge is built in
<peterm6881>
yeah, 12 - 12.5 seconds
<Xogium>
not bad at all considering the low performance of the board
<Xogium>
it might be even faster with systemd
<Xogium>
because currently I reckon it has busybox in
<Xogium>
mist probably
<Xogium>
*most probably
<Xogium>
systemd can launch services in parallel. Busybox can't
<peterm6881>
I sent you the entire boot log in a dm
<peterm6881>
if you wanna save it
<peterm6881>
i should be able to log in and format that GigaDevice nand
<Xogium>
possibly… but the best way is to do it over dfu
<Xogium>
or well fel mode
<peterm6881>
login is root, no password by the way
<Xogium>
yeah makes sense
<peterm6881>
by the way if you were thinking of forking an external BR tree for licheepi nano, I would use florpor's
<peterm6881>
its SLIGHTLY more up to date and has more stuff in it
<Xogium>
oh by the way your wifi dongle saved me again
<Xogium>
the wifi chip on the st dev kit is broadcrap
<Xogium>
er broadcom
<Xogium>
and it misbehaves with my AP
<Xogium>
all my broadcom chips don't like my AP
<peterm6881>
:)
<Xogium>
plugged in the rtl dongle, not one single disconnect in 2 days
<peterm6881>
nice
<peterm6881>
its ralink right?
<Xogium>
no realtek
<Xogium>
requires an out of tree kernel driver
<peterm6881>
ok ive ordered 100 10k 0.125 Watt metal filem resistors to fix these hats
<peterm6881>
im rebuilding from florpors licheepi-nano repo, with the getty set to console, to match mangopi's
<peterm6881>
who knows, maybe florpor enabled all the uarts
<peterm6881>
what do you think?
<peterm6881>
69 MB v 19 MB
<peterm6881>
ahhh this is so annoying lol
<peterm6881>
unframework based his BR on 2020.02, but his u-boot is based on 2021.01 and his Linux kernel is based on 5.11
<peterm6881>
florpor based BR on 2020.02.1, but u-boot 2020.01 and kernel 5.4.36, but with definitely way more stuff enabled...
<peterm6881>
forget what I said about using florpors repo. Given its an external tree, the BR version is less relevant, and the u-boot and kernel are way older. I should just shut up :)
<peterm6881>
meh I'll let it carry on building in a fresh 2021.02.8 directory, who knows maybe it will work, which would be progress of sorts
<Xogium>
I kinda doubt it they probably use the same dt
<peterm6881>
can i modify the device tree?
<Xogium>
yep sure, clone the kernel git repo they use, modify the dt and make a patch
<peterm6881>
thats a no lol
<peterm6881>
ok can i make a suggestion
<peterm6881>
should we fork unframeworks repo at this point?
<Xogium>
well, the vendor one is already working
<Xogium>
as crappy as it is
<peterm6881>
yeah but no external tree, and even more out of date than unframework
<peterm6881>
what do YOU want to do
* Xogium
shrugs
<Xogium>
whatever works best
<peterm6881>
by the way this is what happens when you try to build unframework / florpor in the latest BR directory
<peterm6881>
Incorrect selection of kernel headers: expected 5.10.x, got 5.4.x
<Xogium>
hmm maybe he committed since I cloned
<peterm6881>
that was florpor, unframework was something similar, whatever version he was using
<peterm6881>
na the example i gave was florpor
<peterm6881>
hmm...his kernel is 5.11
<Xogium>
yeah
<peterm6881>
hes ahead of br lts?
<Xogium>
I believe so
<peterm6881>
fuck sake lol
<Xogium>
but I'm surprised they don't even select kernel headers same version as kernel being built
<Xogium>
that would solve all problems
<peterm6881>
by the way in answer to your point about whichever one works
<peterm6881>
would you rather work on MangoPi's stuff, or fork unframework. I'm easy
<Xogium>
well it depends which one works without too much hassle
<peterm6881>
given you know whats wrong with unframeworks repo, and you know how to fix it, and it ticks a lot of box's in terms of later versions and having an external tree, that would be my instinct. But its your call
<Xogium>
it doesn't have all the peripherals though
<peterm6881>
im gonna put the next message in all upper case, ok, cover your ears