<LordKalma>
(haven't tested because I'm at work without the device, I'll test the artifacts and see what needs improvement)
sergi1 has quit []
apritzel has joined #linux-sunxi
<apritzel>
cheetahpixie: forget about that conversion, it's not worth it. You copy an existing DT from the kernel tree, chances are that is 95% correct already
<apritzel>
and then you just look up the GPIO and PMIC rails and compare them
<LordKalma>
fex? never heard of that format
<cheetahpixie>
in sunxi-tools, there is a bin2fex.
<cheetahpixie>
and is it not worth it to create a tool to make this sort of conversion easier to do?
<karlp>
as apritzel says, normaly you'll just end up with junk.
<apritzel>
cheetahpixie: for a start, FEX is total legacy, Allwinner themselves don't use it anymore
<cheetahpixie>
not a reason to not have weapons to read and convert that to usable dts/dtb.
<cheetahpixie>
fex is also what I have to work with.
<gamiee>
apritzel: doesn't they still use them, but convert it to DTS during build?
<cheetahpixie>
and "use new" isn't something I can do.
<apritzel>
cheetahpixie: but also there are conceptual differences between the two, so a conversion would be complicated and not complete anyway
<apritzel>
cheetahpixie: if you want to run mainline Linux, you *have* to use DT
<cheetahpixie>
that's why I want the conversion.
<apritzel>
You will spend half a year coming up with such a tool. OR: you copy an existing DT, adjust the few properties that are different, and are done in an hour
<karlp>
because it will _only_ be a few gpio connections and power hookup choices.
<cheetahpixie>
a tool that'd cut others' time doing this same thing in what could be an automated chain down to near zero.
<apritzel>
karlp: exactly
<cheetahpixie>
okay?
<cheetahpixie>
that's still enough info to gather and use.
<apritzel>
cheetahpixie: have you tried running with one of the existing DTs?
<cheetahpixie>
I haven't even gotten to trying to build anything linux yet.
<apritzel>
cheetahpixie: you wouldn't necessarily need to build Linux, you can just use an existing kernel, for instance from a distro
<cheetahpixie>
how do I even go about doing that?
<cheetahpixie>
also it has a silead panel.
<cheetahpixie>
gc2035/gc0329
<cheetahpixie>
also axp22 here.
<cheetahpixie>
rtl8723 on top.
<cheetahpixie>
really, parsing this file to generate a workable dts shouldn't be hard
<cheetahpixie>
I'm gonna go eat stuff. I'd still like to know what to and how all of this converts to a dts.
<cheetahpixie>
then again, sunxi-babelfish did similar stuff.
<apritzel>
last commit was 8 years ago: good luck
<cheetahpixie>
I am not scared of tall tasks and the impossible.
<cheetahpixie>
I knew nothing about machine code and managed to learn enough in a night to add code to an old SNES game without any disassemblers.
<cheetahpixie>
so yeah, mnemonics for fex > dts are definitely something I'm interested in tackling.
<cheetahpixie>
and this without c.
<apritzel>
why do you ask then in here if you have made up your mind already and don't want to take our advice?
<cheetahpixie>
and do what?
<cheetahpixie>
use already existing devicetrees?
<apritzel>
yes
<cheetahpixie>
because I want to be able to automate this process.
<apritzel>
for the random A33 trash find?
<cheetahpixie>
to facilitate compiling a linux distribution (preferrably postmarketos) that'll fit on that device, for which all you have to do is put the resulting .img onto an sd card, put it into a tablet, and boot.
<cheetahpixie>
not just this one.
<cheetahpixie>
just as a general thing.
<cheetahpixie>
firmware for nonames is very, very hard to find.
<cheetahpixie>
this came off aliexpress.
<cheetahpixie>
and if people have an avenue to simply generate firmware for their devices, it'd help lots of them not end up in a landfill.
<cheetahpixie>
(and actually retain usable life after the... zero seconds the manufacturer will even think to support the device.)
<cheetahpixie>
I also happen to have an a20 tablet on hand that's currently bricked.
<cheetahpixie>
I know why and it's a dumb thing on my part.
<cheetahpixie>
the generic alpine boots, which helps. but it doesn't see the emmc.
<cheetahpixie>
which I need access to to both dump it and fix the recovery on it.
<cheetahpixie>
(I backed it up onto the mmc on device, but never off device.)
<karlp>
blah, crahed the kernel, and "reboot failed -- system halted" instead of back to uboot. What's likely to be not hooked up properly for that to fail?
<cheetahpixie>
is this from inside linux?
<karlp>
well, it's crashing on boot, but yeah
<karlp>
reboot normally works for me in my build.
<cheetahpixie>
hm.
<cheetahpixie>
is this not inside uboot?
<karlp>
eh, it's a minor thing, should just not make it crash instead :)
<cheetahpixie>
heh. challenge.
<cheetahpixie>
I like it.
<karlp>
the kernel panic'd, did "rebooting in n seconds..." then "reboot failed -- system halted" so I never got my u-boot prompt back.
<cheetahpixie>
oh.
<cheetahpixie>
maybe it's power related?
<cheetahpixie>
like, the command from software to the hardware to tell it to reboot seems to not be making the entire trip
<cheetahpixie>
power management bug?
<cheetahpixie>
unless this is another subsystem that does reboots and whatnot.
<cheetahpixie>
wasn't it a lowrisc thing in a64 that did something like that?
<karlp>
well, a normal "reboot" works from linux when it's finished booting.
<karlp>
some hints on the internet that it might be watchdog related
<karlp>
little bit sucky though if a kernel panic won't end up in a reboot (for my needs)
<karlp>
will have to look at it later
<karlp>
if it's only a problem with panics on boot, I can ignore it.
PPA has quit [Server closed connection]
PPA has joined #linux-sunxi
szemzoa has joined #linux-sunxi
<cheetahpixie>
it seems no device in the wiki is exactly identical to mind.
<cheetahpixie>
but I suspect this to be an astar y3, even though s/astar/Boda/
<cheetahpixie>
does not have the ippo q8h shell though.
<karlp>
so yeah, "linux,rs485-enabled-at-boot-time;" causes a null pointer :) will come back to that later. I'm not on 5.19+ yet anyway for that to work.
<cheetahpixie>
whoops, haha
<cheetahpixie>
also.
<cheetahpixie>
the a33 has 16 gigs of storage and a full gig of memory. ddr3, going by the fex.
rajkosto has joined #linux-sunxi
junari_ has joined #linux-sunxi
junari__ has quit [Ping timeout: 480 seconds]
junari__ has joined #linux-sunxi
junari_ has quit [Ping timeout: 480 seconds]
junari__ is now known as junari
<junari>
I built vendor spl with shared libraries from H616 - it works on a devboard with a T507 processor. It is also loaded on a board with an H616 processor with both libraries (T507 and H616). Only the mainline spl on the board with t507 does not work.
<junari>
Can someone tell me what else could be the problem?
<apritzel>
junari: is that loading via FEL or from SD card?
<junari>
All via FEL
<apritzel>
junari: and that was that case were you don't see any output at all, when it's not working?
<junari>
Yes
<apritzel>
junari: so I spent a whole evening last week over how the BROM uses SRAM (by just observing SRAM content, not by looking at actual BROM code yet)
<apritzel>
that seemed to be fine, although we should lower the SPL stack address in U-Boot
<apritzel>
(the BROM seems to write *something* to the end of SRAM C, which we use for the stack, but that oddly enough is not a problem. It might just be temporary data)
<apritzel>
but I actually didn't repeat your 21K vs 20K experiment yet
JohnDoe_71Rus has quit []
<apritzel>
junari: you can try to change the 0x58000 in include/configs/sunxi_common.h to 0x53000
<junari>
apritzel: I did it, but didn't help
buZz has joined #linux-sunxi
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
junari_ is now known as junari
JohnDoe_71Rus has joined #linux-sunxi
<cheetahpixie>
ain't twodimensional arrays fun?
<cheetahpixie>
or rather, a matrix.
macromorgan is now known as Guest1025
macromorgan has joined #linux-sunxi
fisiek has joined #linux-sunxi
<fisiek>
apritzel: You're right, i didn't knew that orange pi or banana pi are that cheap
<fisiek>
probably going to buy orange pi pc or something like it with parallel csi
<karlp>
unless you need a very specific form factor, or are making sufficientyly high volumes, there's very little appeal to doing your own
<fisiek>
I want to learn high speed ddr routing etc
<fisiek>
but probably i should first learn designing >4 layers pcbs :P
<karlp>
that's totally valid too of course.
<karlp>
but you need to accept that _that's_ the goal, up front.
Guest1025 has quit [Ping timeout: 480 seconds]
<fisiek>
wwhat do you mean?
<karlp>
just so you admit to yourself that you're doign a project to learn ddr routing, not "I'm solving my board requirements and I'll learn ddr routing as well, win win" because the first win (getting the board you want) could have been done with COTS parts :)
<fisiek>
yes, you're right
<LordKalma>
the RPI is so expensive atm :(
<LordKalma>
banana pi is cheap indeed
<fisiek>
yeah and rpi is out of stock everywhere
<cheetahpixie>
raspberry shortages be damned
<cheetahpixie>
we have a banana surplus
<LordKalma>
what are the specs of higher end banana pis?
<LordKalma>
are there like 4GB of ram banana pis?
<apritzel>
those boards used to be much cheaper, though, I remember something like 10ish USD for the small boards (OPi Zero), and 20-30 USD for the bigger ones
<LordKalma>
welcome to the silicon crisis :)
<fisiek>
now there are twice as much from what i see on aliexpress
<apritzel>
yes
<fisiek>
~20 usd for OPi zero
<LordKalma>
I've been trying to get parts for my ${DAYTIME_JOB} and nobody wants to sell
<apritzel>
you can get cheap offers on TV boxes, though
<cheetahpixie>
and I sure wanna make a riscv16 or even riscv8 chip and stick 'em in an XT or the like for the hell of it
<apritzel>
LordKalma: 4GB on Allwinner requires H616/H313, and except the OPi Zero 2 (with 1GB) there are not many devboards with that SoC
<LordKalma>
(wow, there's a banana pi with SFP plugs?!?!)
<cheetahpixie>
there are a ton of really interesting rpis
<cheetahpixie>
such as that one a20 nas they had
<apritzel>
LordKalma: that's a Mediatek SoC, though ;-)
<cheetahpixie>
there's also an a20 thing basically purpose made for openwrt
<cheetahpixie>
etc
<LordKalma>
apritzel, i'm surprised, that's all
<LordKalma>
I wanted to buy some trans-impedance amplifiers (an analog radio-frequency component) and nobody wants to sell
<LordKalma>
one model had a 52 weeks lead time
<LordKalma>
we're just prototyping so most sellers don't even reply when we tell them it's not a volume sell
<LordKalma>
the silicon crisis is hitting hard
<LordKalma>
speaking of TV boxes
<LordKalma>
I think I have a piece of crap tv box that runns an allwinner now that I think of it
<LordKalma>
maybe it could be converted to linux
rajkosto has quit [Quit: Leaving]
<LordKalma>
nope, it's a Rockchip RK3318
<jakllsch>
(which allwinner has sfp?)
<fisiek>
iirc banana pi with sfp has mediatek SoC
<fisiek>
BPi R3 and it has MT7986
<fisiek>
its more like router/switch than sbc :P
<fisiek>
it even has m.2
<karlp>
that's what the "R" is intended to imply I believe :)
junari has quit [Ping timeout: 480 seconds]
fisiek has left #linux-sunxi [#linux-sunxi]
<apritzel>
libv: mnemoc: given that the Wiki is down again for a while now, wouldn't it be a good time to flick the switch *now*?
<apritzel>
I mean the new version with minor issues is surely better than "522: connection timed out"?
<LordKalma>
how does the Sunxi community feel about other chip vendors? :D :D :D
<LordKalma>
in fact, how does the sunxi community feels about AllWinner? Isn't your work to basically do what the company was supposed to do but doesn't :)
<LordKalma>
and is mediatek better at releasing kernel sources than it was couple years ago or not really?
fisiek has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
LordKalma: I see Allwinner as a company making dirt cheap hardware, that can be hacked (as in: you can boot your own code, even on embedded devices like tablets or TV boxes)
<apritzel>
I just completely ignore their software offerings.
<jernej>
LordKalma: for me is just a challenge to make something useful from little or no documentation and of course to learn Linux development workflow.
<jernej>
and HW is actually cheap and capable for some cases, it just lacks in SW department, as apritzel said
fisiek has quit []
<jernej>
cheetahpixie: I don't think you'll be able to fully convert fex to dt or even BSP dt to mainline dt. I don't think vendor fex or dt offer information which peripheral uses which voltage regulator.
<jernej>
I mean automatically convert
<jernej>
apritzel: regarding DRAM in SPL - I don't think we have enough H616 DRAM parameters. ODT and bit delay compensation certainly seem like a board specific thing and IMO they work just by chance on other boards.
<apritzel>
jernej: totally agree: I guess we have enough parameters to run on the two boards we support ;-)
<apritzel>
I ordered a T95 Mini (LPDDR3), let's see what this looks like (if it actually ships)
<jernej>
making them Kconfig options shouldn't be hard. We can even make them take same value (format) as it is in BSP DRAM node
<jernej>
I guess I could write wiki page to explain how to figure out which H616 DRAM options to enable based on BSP DT values
<apritzel>
jernej: that would be awesome!
<jernej>
it's easy. Harder problem is to obtain BSP DT values :)
<apritzel>
once the Wiki starts to work again ...
<jernej>
I use local tftp server to upload DT from Android using "busybox tftp"
<apritzel>
jernej: BSP *DT* values? Or do you mean the parameters tucked into the beginning of boot0?
<jernej>
I mean DRAM node
<jernej>
there are about 10 parameters
<jernej>
values printed on serial console during boot are not enough
<apritzel>
are DT values reliable? I don't think the DT is used that early, instead boot0 just uses the bits near the beginning of its binary?
<jernej>
Another possibility is to dump SPL and read values using hex viewer in specific positions. This is more reliable but harder for average user
<apritzel>
I downloaded random "firmware updates" for some TV boxes lately, then peeked into boot0_sdcard.fex, to learn the DRAM type and frequency (to figure out which box has LPDDR3)
<gamiee>
jernej: I think, anyone who would try to do this, will be advanced Linux user, so reading values from hex viewer not might be that hard.
<jernej>
well, DT DRAM node should reflect values baked in SPL. From what I saw, they always matched.
<jernej>
Only in one case, DT actually hold 16 sets of them and I had to figure which one is actually used.
<jernej>
gamiee: fair enough
<apritzel>
we could even write a small tool to parse those IMAGEWTY files, find the boot0 in there and dump the parameters
<jernej>
raw SPL is easier, since it's on fixed offsets and SPL can be even dumped from live system (if device is rooted, which usually it is)
<jernej>
well, both modes could be supported
<apritzel>
sure
<jernej>
fun fact, H616 DRAM code uses 31 parameters
<jernej>
fortunately, not all are relevant and some seems to be same for same DRAM type
<apritzel>
jernej: isn't it also that the mainline code tries more autodetection, where the BSP uses mostly fixed values?
<jernej>
depends on parameters
<jernej>
there are some flags which tell if parameters should be used as is or they should be autodetected
<apritzel>
ah
<jernej>
H616 code has a flag to enable verbose output during DRAM initialization
<apritzel>
you mean the BSP code?
<jernej>
yes
vagrantc has joined #linux-sunxi
<apritzel>
nice, how do you trigger this? Change something in the boot0 binary and recalculate the eGON checksum?
<apritzel>
or is it a build time flag?
<LordKalma>
The LCD panel driver is finished :D :D :D :D :D
<jernej>
I didn't test it myself, just noticed during reverse engineering. But in principle, boot0 binary would need to be updated with updated value of one of the parameters.
<jernej>
not sure if checksum needs to be updated
<jernej>
LordKalma: congrats!
<LordKalma>
thanks to some random Russian dude that joined the "team"