JohnDoe_71Rus has quit [Ping timeout: 276 seconds]
<ullbeking>
i'm looking into Rock64 as something more powerful that works on an SBC. Rock64 from Pine64 seems to be the "default choice". But I am used to OPi, so would OPi-RK3399 be a good choice?
<karlp>
what does "used to" mean for you?
[7] has quit [Remote host closed the connection]
TheSeven has joined #linux-sunxi
aloo_shu has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
netlynx has joined #linux-sunxi
Andy-D has joined #linux-sunxi
<pcbBob>
How do one get documentation ressources for Mediatek SoCs?
florian has quit [Ping timeout: 250 seconds]
<ullbeking>
karlp: it's that I know where the forums are, who to ask about OPi, where the eco IS and HOW it behaves, etc
<ullbeking>
also I know Armbian which is the primary OS for Allwinner... but IDK if that has anything to do with RK3399 though
Wizzup has quit [Ping timeout: 276 seconds]
<libv>
ullbeking: linux-sunxi is pretty unique that way
<ullbeking>
libv: unique in what way?
<libv>
in that there is a useful wiki, irc channel, mailing list
<libv>
for other SoCs, your mileage will vary
<ullbeking>
yeah, I see your point, and I agree
<ullbeking>
the wiki, list, channel, etc, have been very helpful and I like the organic nature of it all
<libv>
my starkest example is when i was trying to bring up uac3 on vendor hw, and the others in the project had the hw on site, and we needed remote access on cheap hw, and they went and bought the 64bit rpi as they were in the .uk and they did not know any better
<libv>
after a week, i had to go get involved, as they could not get a recent linux running on it
<libv>
with a manually built kernel, not just some image dled from the vendor website
<ullbeking>
libv: sounds like linux back in the early 90s lol
<libv>
i had to combine 3 different blog entries, each outdated and partial in their own way
<hellsenberg>
uac3?
<libv>
usb audio codec 3
<ullbeking>
hellsenberg: the kerfuffle of it all
Wizzup has joined #linux-sunxi
<libv>
Wizzup is actually one of the guys behind linux-exynos
<libv>
but exynos was only really worked on by samsung employees or odroid
<libv>
and therefore it did not go as far as we would've hoped
<libv>
odroid is/was (are they still around?) pretty typical as well
<hellsenberg>
I can see things about usb audio class, but not many about usb audio codec
<libv>
i remember fixing 32bpp colour for the chipset, a long standing issue that the odroid employee could not fix
<libv>
hellsenberg: yes, class, sorry
<libv>
only to find my 2 fixes mashed together and the author being that odroid employee
<libv>
way to build a community.
<hellsenberg>
:/
<hellsenberg>
I know about USB audio class as of today and I already think it's a cursed thing
<libv>
hellsenberg: hwe room had ruslan bilovol talking last year
<libv>
i spent 3 months fixing vendor crap to get us reliable building of firmware and reliable flashing, etc
<libv>
and after 2.5 months, one of the other two (who could not get an rpi going on mainline) wondered what this usb gadget thing is
<libv>
and then i concluded "if only we had just taken the spec, implemented both sides of usb gadget, we would be done by now"
<libv>
i then pissed off the vendor again with my "complaining" about their code and they wanted me off the project
<libv>
less than a week later, ruslan posted his patches to the alsa mailing list
<libv>
so it was fun to have ruslan talk in the fosdem devroom where i was one of the managers :)
<libv>
with him wondering why the authors of the spec were unwilling to answer his questions, and ignored when he was pointing out issues
<libv>
my answer to him was: you are the spec now.
gaston1980 has joined #linux-sunxi
<libv>
which is part of why noone wanted to talk to him ;)
<libv>
not relevant actually
<libv>
ullbeking: linux-sunxi is pretty unique
<libv>
it was cheap android class hw when it came out, tom cubie from then allwinner had the right idea in that he should sell some hackable devices like the mele a1000, which were pretty affordable
<ullbeking>
libv: yes, indeed. this is why i prefer OPi etc to RPi... there are interested and knowledgable people here
<libv>
then, 2 vendors dropped gpled code
<libv>
as they adhered to the gpl
<libv>
2 device/board makers
<libv>
and then soon thereafter allwinner also dropped some gpled kernel and uboot code
<libv>
finally, .fex provided some form of hw description
<libv>
you could extract the fex file and then use the allwinner kernel to get your hw working
<libv>
which was unheard of in 2012
<libv>
H2 2011 and H1 2012 i was on actual android devices, and i counted myself lucky when naobsd threw some binaries together for the m701-r telechips tablet that was a horrible original ipad ripoff
<libv>
so that i could use LD_PRELOAD, which did not exist in the loader for bionic until android-2.3
gsz has quit [Ping timeout: 240 seconds]
<libv>
so sunxi was a whole new world for everyone
<karlp>
what's naobsd up to these days?
<libv>
he from time to time turns up here
* karlp
ran into them first in rockchip land.
<libv>
but no idea really
<libv>
the mips based one, right?
<libv>
rk28.. 11?
<karlp>
first one I was looking at was 3066,
<libv>
hrm
<libv>
am i getting old, who did the mips tablet?
<libv>
ah, ingenic
<libv>
rk2818/2918
<libv>
that was a popular ipad ripoff as well in the day
<libv>
anyway, sunxi, despite the bitrot in the wiki, is still pretty special
<libv>
which is why we are building our video capture hw for fosdem on it
<libv>
we could buy ready made realtek based hw, but it would take way longer to get the thing working and working stably
<libv>
it's easier to design a lime2 daughterboard to capture hdmi, and even then we are spending 90+% of our time on drivers and software
<ullbeking>
karlp: i was thinking the exact same thing re: nanobsd
<libv>
naobsd.
dddddd has joined #linux-sunxi
<libv>
not nano :)
<hellsenberg>
realtek O_o
<hellsenberg>
openwrt's supported hardware table speaks wonders of realtek SoCs
<hellsenberg>
or rather, should I say, socks.
<libv>
rockchip would not be open if it was not competing directly with allwinner in the tablet space
<libv>
and if google had not picked up the chips for chromebooks
<libv>
mediatek was always in a slightly different space, with their cellphone oriented socs, and they too are pretty bad players
lkcl has joined #linux-sunxi
<libv>
if you look into rockchip, you will quickly see that the upstream support is there only to support those chromebooks and very little else
<libv>
but then, we all are reduced to developer boards today anyway
<ullbeking>
speaking of chrome books I'm looking for an Asus c201 and want to put coreboot on it but the latest cb release notes say "veyron" has been removed....
<ullbeking>
I need to do more work to find out what that really means... there are/were three things called veyron
<ullbeking>
asus c201 is veyron speedy
<libv>
which is a question for #coreboot and #rockchip iirc
<ullbeking>
yes
<libv>
i have one of those too
<libv>
from when i was still planning to do tamil work
<ullbeking>
I want the cheapest Chromebook with >= 4GB RAM and coreboot to give to my 3 yo daughter. then it doesn't matter too much if she trashes it.
<libv>
my 3y old gets an a33 tablet, when i get round to installing it
<hellsenberg>
ullbeking: I still see a rk3288 chromebook called veyron in coreboot master from today
<hellsenberg>
otoh, there was some unfinished allwinner code for a cubieboard that got dropped
<ullbeking>
hellsenberg: yes they are getting strict; unfinished or untested code gets dropped without mercy now
<hellsenberg>
I'd rather say "unmaintained"
lurchi_ is now known as lurchi__
<MoeIcenowy>
ah I don't think anyone wants to re-do works for Allwinner on Coreboot
<MoeIcenowy>
because there're SPL support on U-Boot
<ullbeking>
MoeIcenowy: i would
<ullbeking>
i actually find it weird that nobody would want to, no?
<MoeIcenowy>
ullbeking: ah, then what payload can we use?
<MoeIcenowy>
I think many payloads are x86-only
<MoeIcenowy>
and other payloads are not sunxi-compatible except U-Boot
<ullbeking>
i'll ask around...
<ullbeking>
brb
LordDoskias has joined #linux-sunxi
<LordDoskias>
hello
<LordDoskias>
i'm trying to use 2 pins on the 'r' pincontroller as gpio pin but doesn't seem to work
<LordDoskias>
e.g. gpiodetect works and detects the pins but when i set any of them to 1 my LED doesn't light up, yet the same led, connected to any of the other GPIO banks works
BenG83 has joined #linux-sunxi
<LordDoskias>
looking at the alternative functions there is S_PWM on one of the pins but looking at the device tree in use it doesn't look like this laternative function is enabled
<LordDoskias>
(that's on a A64 chip, running armbian/kernel 4.19.66)
lurchi__ is now known as lurchi_
cnxsoft has quit [Quit: cnxsoft]
embed-3d_ has joined #linux-sunxi
embed-3d has quit [Ping timeout: 240 seconds]
<mru>
does that i/o bank have a separate power supply?
<LordDoskias>
how do i figure that out?
<mru>
by reading the manual
<LordDoskias>
you suspect the pb can be off i.e not powered on ?
<LordDoskias>
s/pb/io bank/
<mru>
I don't know the specifics of that chip
<mru>
on many allwinner chips, some i/o banks have their own power supply
<mru>
if not powered, they don't do anything
<LordDoskias>
there is _some_ power
<LordDoskias>
because as i said when the LED is connected to the PL10 pin it's only ever so slightly turned on, meaning there *is* some electricity
<mru>
that's not what you said
<LordDoskias>
indeed
<mru>
anyway, maybe the voltage is lower on that bank
<mru>
what colour led is it?
<LordDoskias>
it's red
<LordDoskias>
i'm using pine64-lts
<MoeIcenowy>
LordDoskias: you can check debugfs for current PL bank IO voltage
<MoeIcenowy>
check for "vcc-pl" regulator
<LordDoskias>
under /sys/kernel/debug/regulator/vcc-pl/ i have bypass/open/use count?