ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
<qpla>
HI there, I'm new to arm devices, I have an rg35xx+ that uses an allwinner h700 chip
<qpla>
I've managed to get root access over uart and then gone from there to use x11 forwarding to get access to an xfce4 environment
<qpla>
just a shame it's all so closed-source I guess
<qpla>
I can't remember if I had a question or not but it's running ubuntu 18.04.06 LTS
<CounterPillow>
It's probably running some vendor bsp kernel with an ubuntu 18.04.06 userland smashed on top
<qpla>
I see! Is there any way I can verify that?
<qpla>
I was actually wondering about getting the mali gpu working, but apparently there's no way because it's X11 and arm arent supporting mali bifrost gpu drivers, or something to that effect
<qpla>
it's all a bit confusing for a beginner
<CounterPillow>
I don't see any allwinner h700 device trees in mainline so that's how I know it's in all likelihood running a vendor bsp
<CounterPillow>
Mainline supports Mali bifrost GPUs through the panfrost driver and mesa userspace library, but your vendor bsp is most likely using Arm's proprietary stack for this
<CounterPillow>
(Panfrost also does not care about X11 support fwiw, nobody in this day and age does)
<Xogium>
allwinner... Yuck
<qpla>
Alright
<qpla>
Yeah there's little to no documentation.
<qpla>
It's just a little handheld gaming device with an h700 and 1GB DDR4
<CounterPillow>
If you have a question about Allwinner's vendor fork you should ask them, not the upstream kernel community. Chances are they won't even provide you with a source because Chinese handheld manufacturers love violating the GPL.
<qpla>
oh, sorry if I'm bothering you.
<qpla>
Yeah, I realise that chinese handhelds are pretty gross with GPL.
<qpla>
Nobody in the dev community gets source for anything.
<Xogium>
especially not with allwinner
<qpla>
their previous iteration used Actions, which is probably worse
<Xogium>
even when you use their own bsp ;p I once had to interact with sochip and they said, hey, here's your patch to migrate from the EOL SoC to the now low power variant we made ! Yeah a patch. I was surprised. Then I realized we didn't have the same definition of patch. They gave me binaries without explaining what they were for
<Xogium>
sochip being the official allwinner distributor
<qpla>
I think I probably picked a bad SoC to start my linux journey on... haha.
<Xogium>
:D
<qpla>
Just feels like banging my head against a wall.
<Xogium>
I know that feeling
<Xogium>
I had something similar with the marvell armada 3720
<Xogium>
no darn doc at all. Marvell had shutdown their documentation server by the time I got the board using this SoC, so you coldn't even get access to the doc anymore
<qpla>
Damn.
<Xogium>
so guess it was reverse engineered pretty much
<qpla>
well, supposedly this chip isn't *too* different from the h618, which there is *some* documentation for...
<qpla>
but it's all beyond me assomeone just starting out anyway.
<Xogium>
I spent literally 6 months trying to compile my own bootloader and didn't understand why it was always broken... I realized that the bootloader needs to be compiled in a very specific way, that using a toolchain with ssp support is a no no unless you disable it explicitly in the build, because it will compile you something, but the image won't work otherwise... Fun times. Not
<qpla>
6 months!
<Xogium>
yeah. Granted I was a beginner at the time, but when the oly doc you can find on the internet tells you to do steps that don't work for some reason, you gotta try to figure it out on your own
<Xogium>
I tried so many combinations I forgot all but the right one, which I suppose is better that way
<Xogium>
I had to do that because turns out the vendor of my board was not really that great at quality control, and they somehow ended up shipping at least an entire batch of boards and probably more, with a bootloader stored in the spi flash that was missing the driver to read its own spi flash, thus couldn't boot
<qpla>
WOW.
<Xogium>
yeah. I'm never buying a board from globalscale again :p
<qpla>
well, this one just reads from an SD card, no built-in spi flash chip or nothing.
<qpla>
it's quite funny, I'm able to get a desktop environment setup over ssh/x11 forwarding on this tiny little handheld device, but that's probably about the limits of my skill so far
<Xogium>
well, everyone started as beginner ;)
<qpla>
Trying to get retroarch setup but it's just hopeless...
<qpla>
yeah! I've never googled so much stuff in my entire life :D
<Xogium>
you might be able to get the userspace part of retroarch running. Maybe. You'd have to dump out the kernel and bootloader of the vendor and keep them, so that they're the ones booting/running retroarch
<qpla>
They're got the program running that allows you to change settings which displays on the main screen called dmenu.bin, which eats 50-70% cpu in idle state.
<Xogium>
but beyond that, not much else you can do if there's no mainline support for the SoC at all, unless you feel like learning enough to contribute it somehow
<Xogium>
and retroarch might struggle to run if it turns out your kernel needs a config that is missing
<qpla>
There's a guy who's working on mainlining some devices right now, the rg35xx plus (the one using the h700) is on his list, but... it's not looking promising, according to someone else
<Xogium>
yeah :/
<qpla>
so I'm interested in dumping out the kernel and bootloader, if that's a good first step, but I wouldn't even know where to go from there or how to achieve said dumping
<qpla>
Maybe I should stick to something like a raspberry pi :D
sudeepholla_ has quit [Ping timeout: 264 seconds]
<Xogium>
qpla: pm :)
TheCoffeMaker has quit [Ping timeout: 256 seconds]