ftg has quit [Read error: Connection reset by peer]
vagrantc has quit [Ping timeout: 480 seconds]
ItsKaitlyn03 has joined #linux-sunxi
megi1 has quit []
megi has joined #linux-sunxi
<ItsKaitlyn03>
Hi all, it's been awhile (roughly 10 months?) since I was last here. I asked about some A100/A133 stuff around then, unfortunately never got around to messing around with my tablet at the time. I now have a better ""SBC"" for messing around with the A133, and I was given the "TinaLinux" kernel from my SBC manufacturer without any modifications. Would it be of any value at all?
<ItsKaitlyn03>
I like this SBC since it doesn't have secure BROM enabled, and it has 4GB of DRAM + it has a dedicated FEL button and a bunch of GPIO headers and LVDS/MIPI exposed
<Jookia>
ItsKaitlyn03: hi there, TinaLinux is generally not what you want if you can avoid it. But if it's not a public version putting it online could be useful
<ItsKaitlyn03>
A133 linux stuff is not very public, aside from mainline
<ItsKaitlyn03>
thanks allwinner for not open sourcing their linux kernel
<ItsKaitlyn03>
.-.
<Jookia>
ItsKaitlyn03: the kernel should be in the TinaLinux if it's the A133 kernel
<Jookia>
i'm happy to help you dig through it if you'd like
<ItsKaitlyn03>
yeah, ill prolly upload it to gdrive or something
<Jookia>
thanks!
<ItsKaitlyn03>
I have no clue why allwinner locks their linux src behind NDAs when its clearly against GPL
<ItsKaitlyn03>
but i guess they just, don't care??
<Jookia>
yeah nobody can really take them to court
<Jookia>
i just realized i've misplaced the bsp i downloaded for the rp-t113 code
<ItsKaitlyn03>
in fact it was already f'ed up enough when i asked my own SBC manufacturer for their linux kernel src and they were like "we cant give out our modified allwinner kernel source, but we can give out the allwinner kernel source"
<ItsKaitlyn03>
just WHAT
<Jookia>
yeah they should definitely be giving you the GPL source
<ItsKaitlyn03>
personally i didnt want to argue because the person in the emails was chinese and there was a bit of a language barrier, I'm just glad I was able to get the tina linux src
<Jookia>
arguing tends to not work very well either :(
<Jookia>
good for asking though, some vendors are good about it
<Jookia>
did they give you a binary linux distro image you can flash to an SD card?
<ItsKaitlyn03>
oh yes I have both android images and linuxqt/tina linux images
<ItsKaitlyn03>
linux qt is just tinalinux
<ItsKaitlyn03>
and tinalinux is just terrible openwrt
<ItsKaitlyn03>
its also a hellshow
<ItsKaitlyn03>
literally
<Jookia>
yeah i've had a look at it, it's not great
<ItsKaitlyn03>
so when you first boot it, standard openwrt/linux wifi commands dont work, you have to use this abhorrent allwinner wifi utility binary. AND THEN, using the OTG port/microUSB port or whatever
<ItsKaitlyn03>
in order to SSH/shell into it, uh
<ItsKaitlyn03>
you use ADB, they ported the ADB daemon to linux somehow
<Jookia>
whoa
<ItsKaitlyn03>
well, ADB is already written for linux, but ive never seen it just USED for sbc linux purposes
<Jookia>
yeah you generally don't see it in gnu land
<ItsKaitlyn03>
you can just ADB shell into it like an android device, but its not android
<ItsKaitlyn03>
"1 Processor, 1 Core, 4 Threads" I have no clue how this works
<ItsKaitlyn03>
I do know in dmesg logs, it does have a working powervr GPU driver surprisingly
<ItsKaitlyn03>
I just don't have a MIPI or LVDS display, yet
<Jookia>
linux 4.9!!! aaaa
<ItsKaitlyn03>
i think they also maintain a 5.10 kernel for a133, but good luck getting that
<ItsKaitlyn03>
.-.
<ItsKaitlyn03>
if i could id sign the allwinner NDAs just to get the linux src because it aggravates me so much. i wish they would just, distribute it to people
<Jookia>
if you have the patience and a bit of time for learning you can probably get latest kernel running on that. not sure
<Jookia>
unfortunately even with the allwinner linux source it's not so helpful long term, their drivers are usually kind of junk
<Jookia>
well, junk is a harsh term, but they're not really something that can be merged upstream without work
<ItsKaitlyn03>
u-boot doesn't exist for a133, there was some work on DRAM init in a non-upstream repo for A133, but if you're booting from FEL and not from FEL sdcard, you won't have working DRAM init afaik
<Jookia>
interesting
<ItsKaitlyn03>
since BOOT0 does some funky dram init before passing off exec to SD card to go back to FEL
acmeplus has quit [Remote host closed the connection]
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
vagrantc has quit []
apritzel has joined #linux-sunxi
<tokyovigilante>
Have managed to get sound out from the RG35XX headphone socket (line-out I assume) but no jack detection (and no speaker route configured currently), and the sample rate setting seems wrong, it's playing back very slowly and distorted at 48KHz
<tokyovigilante>
Still, clearly on the right track! Using codekipper's branch but there is a bunch of extra register setting in the vendor driver which may be the issue, although the vendor driver by itself doesn't work at all
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<apritzel>
ItsKaitlyn03: hi, welcome back!
<apritzel>
so regarding the A100/A133 support: that's more a problem of little demand than a technical problem
<apritzel>
there are some tablets and I think only very few reference design SBCs around, so there has never been much interest or support from the community to upstream it
<apritzel>
I think technically there is not much we are missing, and we have the user manual, which answers like 95% of the questions we need for Linux kernel support
<apritzel>
especially since the A133 is somewhat between the A64, H6 and H616, it probably works with slightly modifying the existing mainline drivers for one of those SoCs
<apritzel>
it's of course good to have the BSP source, though typically the tarballs for the one SoC tends to contain support for many other SoCs as well, and I have definitely seen code for sun50iw10p1 in there
<apritzel>
so keep it around, but try to not look at it ;-)
<apritzel>
it's helpful to answer questions in case the manual is lacking or plain wrong, but otherwise you just hurt your eyes by looking at their horrible code
<apritzel>
it's not only often completely ignoring Linux coding standards, but it also solving problems the wrong way, so it's not a good reference
<apritzel>
regarding EDK2: why, exactly? If you need UEFI support (to boot Windows or other UEFI-only OSes), U-Boot has you covered for years now
<apritzel>
the UEFI support has matured quite
<apritzel>
... a bit since its inception, and I think it passes most compliance tests now
<apritzel>
the problem with a EDK2 port is the BSD license, so you cannot easily copy Linux or U-Boot code
<apritzel>
which means you either have to write it yourself, or lift it off some {Free,Net}BSD code
<apritzel>
but in general EDK2 is not considered the best code base (it's very "DOS"y to begin with), and I don't see the advantage of having support for sunxi, apart from the sheer exercise of hacking around
<apritzel>
ItsKaitlyn03: if you want to contribute: as you mentioned we lack U-Boot support, that should be a rather straight-forward exercise, you just have to wade through the SPL swamp
<apritzel>
I think some patches went in, courtesy of being useful for other SoCs, but the rest could be rebased, cleaned up, and upstreamed pretty easily
<apritzel>
(the last two lines relate to Linux support, btw)
apritzel has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest6111
dsimic has joined #linux-sunxi
Guest6111 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
acmeplus has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
acmeplus has quit []
gamiee has joined #linux-sunxi
Robot_ has joined #linux-sunxi
<ItsKaitlyn03>
apritzel: I'll still go ahead and upload the tina src somewhere
<ItsKaitlyn03>
Also, turns out the dram init code is somehow just linked into everything
<ItsKaitlyn03>
it might be worth trying to reverse engineer that and reimplement it
<ItsKaitlyn03>
i think i'll probably try
<ItsKaitlyn03>
it'd probably be worth creating a repo for decomping libdram as well maybe
apritzel has joined #linux-sunxi
<apritzel>
oh yeah, DRAM init is a critical piece of code not covered in any manuals, so anything lifted from the BSP on that is useful
<ItsKaitlyn03>
i noticed the a133 uboot someone made has parts of their own libdram decomp just missing
<ItsKaitlyn03>
so it doesnt work as a boot0 replacement
<ItsKaitlyn03>
so if i try booting straight from FEL, it doesn't init DRAM fully due to those missing functions
junari has quit [Ping timeout: 480 seconds]
<apritzel>
there was some trick we pulled in the past: we linked some libdram.o found somewhere into a hacked mainline SPL, to do the DRAM init
<ItsKaitlyn03>
oh yeah that works, thats what AW seems to be doing here LOL
<apritzel>
but that has several issues, starting from requiring a 32-bit SPL build, and not ending with license issues (non-GPL code linked into the GPL SPL)
<ItsKaitlyn03>
seems they don't want libdram src leaking out, so they just provide it as a binary blob to get linked in
<apritzel>
yeah, DRAM init code is always something we painfully have to piece together
<apritzel>
but some people in here have some experience in that
<ItsKaitlyn03>
oh yeah I noticed my A133 starts in arm32 mode, still learning how ARM works and stuff, I mostly bought another board with A133 to mess around with it
<apritzel>
so far every Allwinner SoC starts in 32-bit, I guess this way they can keep their BootROM code the same
<ItsKaitlyn03>
that's such a lazy move LOL
<ItsKaitlyn03>
but i guess it means they don't have to worry about changing the BROM a lot
<apritzel>
so using libdram.o is a quick stopgap measure to get things going, but we need proper GPLed DRAM init code anyway
<apritzel>
and chances are it's not that different from the other SoCs
<apritzel>
with the A100 being something between the H6 and the H616, it seems
<Jookia>
dumping the object online and getting it to boot u-boot and linux would be cool
<Jookia>
in the github u-boot fork linked the code for the A133 dram seemed basically modified H616 init
<apritzel>
ItsKaitlyn03: so do you have that libdram.o file? Does it have debug symbols?
<ItsKaitlyn03>
Yeah it has symbols for exported funcs, I'll go ahead and upload libdram somewhere rq
<apritzel>
cool, now we just need to get jernej interested to have a look at this and tell us what it's close to ;-)
<Jookia>
speaking of kernel stuff, it reminds me of allwinner tina's top secret CAN driver, that was so secret some code was shimmed in an obj file distributed as assembly
<Jookia>
the obj file? the secret contents? just calls to a supervisor ;_;
<Jookia>
actually useless
<ItsKaitlyn03>
also my tar gz's turned out to be slightly corrupt, i dont think any of the uboot stuff is affected but just something to note, i had no problems loading up a133 libdram in ida though
<ItsKaitlyn03>
ill drop "brandy-2.0" as a zip on gdrive, without the tools dir thats inside it, as it has a full copy of GCC
<ItsKaitlyn03>
a133 is at: \brandy-2.0\spl\drivers\dram\sun50iw10p1
<ItsKaitlyn03>
they have libchipid and libdram, but libdram doesnt appear to link to libchipid
<Jookia>
i wonder how much of this could be used to reverse engineer secure boot...
<Jookia>
that might be more brom code
<ItsKaitlyn03>
isnt meme (secure) boot just a boot0 thing??
<ItsKaitlyn03>
im pretty sure it is
<Jookia>
yeah
<Jookia>
i think it's secure boot? it requires a key to boot
<ItsKaitlyn03>
you can replace boot0 on the NAND
<ItsKaitlyn03>
that i know, idk about BROM being "secure"
<Jookia>
no i mean the BROM security checks
<Jookia>
with a key you can fuse
<Jookia>
i dunno, there's probably some code in the tina for signing binaries
<ItsKaitlyn03>
libcedar is here
<apritzel>
we have still to see any device having an actual key burnt
<apritzel>
so far all "secure boot" devices use the signed TOC0 image format, but leave the key fuses empty, which means any code would do
<apritzel>
... any *key would do
<apritzel>
in mainline U-Boot you just have to enable CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0=y to create a TOC0 wrapped SPL binary, with a random key created on the spot, and it should work
apritzel has quit [Ping timeout: 480 seconds]
<Jookia>
apritzel: not fusing? cowards! (or maybe its all broken)
<ItsKaitlyn03>
oh i just found the code they use to warm reset the cpu to aarch64 mode
<ItsKaitlyn03>
intriguing
<ItsKaitlyn03>
but its marked as "boot0_jmp_monitor"
<Jookia>
:eyes:
electricworry_ has joined #linux-sunxi
electricworry has quit [Ping timeout: 480 seconds]
electricworry_ has quit [Remote host closed the connection]
<acmeplus>
@ItsKaitlyn03 I'll give a try to that u-boot on the TrimUI Smart Pro too.
<acmeplus>
Does that board use powervr ge8300? or something else?
<ItsKaitlyn03>
a133 uses GE8300, yes
<ItsKaitlyn03>
a100 is the same
<ItsKaitlyn03>
just note that im pretty sure you'll have to use FEL sdboot since boot0 checks if SD is bootable and boots from that after initing DRAM
<ItsKaitlyn03>
BROM -> FEL = DRAM not initialized, BROM -> BOOT0 -> SDBOOT FEL = DRAM initialized
<ItsKaitlyn03>
obviously if you fully reimplement libdram, then you can just use it as a boot0 replacement, but the biggest pain point is that you still need to warm reset the SoC to 64bit
<ItsKaitlyn03>
and thats what boot0 seems to handle(?)
<ItsKaitlyn03>
alongside initializing DRAM
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
electricworry has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
Robot_ has quit []
acmeplus has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
Robot_ has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
ItsKaitlyn03: keep in mind that the A133 is nothing special really, it's all the same sauce as the other Allwinner SoCs, just with very small variations
<apritzel>
so of course we have the 64-bit jump already covered in the SPL, and in fact there is code also in U-Boot proper
<ItsKaitlyn03>
oh nice :)
<apritzel>
in case you want to run the whole SPL in 32-bit (to link in libdram, for instance)
<apritzel>
the other trick is to hack some boot0 binary to get it to load U-Boot proper: equally hideous
<ItsKaitlyn03>
would be kind of cool to at least test things though
<apritzel>
probably the easiest to get you unblocked on DRAM: put just the AW boot0 on an SD card, no other code
<apritzel>
this sometimes puts the chip into FEL mode afterwards, then you can load U-Boot proper (and everything else) via FEL and take it from there
<ItsKaitlyn03>
couldn't you just also use SDBoot FEL since SDBoot FEL gets loaded after BOOT0 does its initialization?
<apritzel>
what do you mean with SDBoot FEL? the fel-sdboot.sunxi file from sunxi-tools.git?
<ItsKaitlyn03>
yeah
<apritzel>
I don't see how this would work: fel-sdboot.sunxi (or the .toc0 version) would *replace* boot0, so it's either one or the other
<apritzel>
so not sure what you mean exactly
<apritzel>
maybe it's what I wrote above: if boot0 doesn't find anything to load, it goes into FEL mode
<ItsKaitlyn03>
BOOT0 loads fel-sdboot from the SD card, then it goes into FEL mode
<ItsKaitlyn03>
iirc it tries SD boot first, then NAND boot, then SPI
<apritzel>
which boot0? where does that live?
<ItsKaitlyn03>
NAND
<apritzel>
or do you mean the BootROM? Because that does this SD first, then NAND, then SPI sequence
<ItsKaitlyn03>
Oh, I might be entirely wrong then. I was checking boot0 src...
<ItsKaitlyn03>
AW is slightly confusing
<apritzel>
slightly is an understatement
<apritzel>
boot0 (which is equally size limited as the SPL) tries to find more code to load
<ItsKaitlyn03>
the documentation is all over the place and it seems like nobody is exactly sure what AW does at times xD
<apritzel>
on the same device it got loaded from, so eMMC (I hope you have that instead of NAND)
<apritzel>
well, officially you are supposed to swallow what AW gives you, but installing their ridiculous BSP tarball and following the instructions
<apritzel>
but please don't do this!
<ItsKaitlyn03>
it's crazy that they dont even open source their BSP at all
<apritzel>
we understand the BootROM boot process very well, and this is all that counts
<apritzel>
the community decided a long time ago to deviate from AW's secondary boot process, and we have our own boot flow, after the BROM did its job by loading the SPL
<apritzel>
and I can only strongly advise you to not go down into the boot0 rabbit hole, there might be no one to rescue you from down there
<apritzel>
all you need to know is that the BROM expects an eGON header on the first code it should load into SRAM (or a TOC0 header when "secure boot" is enabled)
<ItsKaitlyn03>
I might see if I can just get h616 dram init going by modifying it till it works
<ItsKaitlyn03>
it seems familiar similar ish
<apritzel>
yeah, that's the sanest route indeed
<apritzel>
are you trying this on the non-secure SBC, or on the secure tablet?
<ItsKaitlyn03>
that secure tablet, idk where it went (its probably somewhere in my bin of electronics). however, my current devboard is the thing I am primarily using, it has both UART0 and UART2 exposed, a bunch of GPIO and LVDS/MIPI exposed
<ItsKaitlyn03>
it was something i bought off aliexpress (the devboard)
<apritzel>
ah, yeah, that one, I had my eyes on that as well, but as I said: A133 isn't particularly popular, and we have bigger fish to try (finish H616 and get A523 going)
<apritzel>
so yeah, please stick to this one, I guess it's not using secure boot?
<ItsKaitlyn03>
yeah no, there is no secureboot
<ItsKaitlyn03>
i noticed this in the UART logs when i first checked it out
<ItsKaitlyn03>
it says "BOOT0" not "SBOOT"
<apritzel>
that's great to hear, and removes one problem (though there are still plenty left)
<apritzel>
so if you build the U-Boot A133 branch I pointed to above, you might see some output, probably about the failing DRAM init
<ItsKaitlyn03>
i'll go ahead and try that soonish
<apritzel>
ItsKaitlyn03: are you using FEL boot (via an USB OTG cable)?