ftg has quit [Read error: Connection reset by peer]
tokyovigilante has joined #linux-sunxi
<tokyovigilante>
Hi, I'm trying to bring up an Allwinner H700-based board (RG35XX+ console, think macromorgan is also working on it) and have u-boot built with a DTS extracted from the vendor firmware, but when I try and boot I get (from a UART console) "DRAM:This DRAM setup is currently not supported."
<tokyovigilante>
I have dumped out the required DRAM parameters from the vendor firmware using sunxi-fw, and put them in my uboot defconfig, but this doesn't seem to be working.
vagrantc has quit [Quit: leaving]
<macromorgan>
yeah, might have to look at the T507 next
<apritzel>
tokyovigilante: " ... u-boot built with a DTS extracted from the vendor firmware ...": I believe vendor firmware DTs and mainline DTs are wildly incompatible, unless the vendor firmware is actually mainline based
<tokyovigilante>
apritzel: thanks, would I be better off using some other mainline H6160-based tree? Would that affect the DRAM config?
<tokyovigilante>
macromorgan: you think the RG35XX is a lost cause?
<apritzel>
tokyovigilante: yes, use something near by and adjust, potentially looking at the vendor DTs for info (which GPIO, which PMIC rail, etc)
<tokyovigilante>
vendor firmware is using a 2018 uboot and 4.9 kernel.
<tokyovigilante>
ok thanks
<apritzel>
lost cause? why give up so quickly?
<macromorgan>
35XX is a lost cause (the Actions Semi based device). 35XX+/35XXH is very much doable (the Allwinner H700 based device)
<tokyovigilante>
I haven't given up, just no real idea what I'm doing
<tokyovigilante>
sorry yes I mean the plus
<macromorgan>
you're in the wrong place if you want to throw in the towel on an Allwinner device :-)
<tokyovigilante>
No not at all, was overly pleased with myself just getting u-boot built and outputting something
<apritzel>
for a start, you can try to let the existing boot0 do the DRAM init, then focus on getting the DT right and then start looking at the LCD part
<macromorgan>
I think it will require effort and work, but it's absolutely doable. Right now we just need to get the RAM init thing done. Also I think the PMIC might prove to be a pain. But it's not insurmountable.
montjoie has joined #linux-sunxi
<macromorgan>
yes, I think that's my next goal apritzel
<tokyovigilante>
Cool. There seem to be a large number of non-mainline drivers for the PMIC leaked on Github
<apritzel>
the DRAM part just requires some experiments and patience
<macromorgan>
is there a way to have the boot0 hand off to U-Boot without having to manually load via FEL?
<macromorgan>
binary RAM init isn't ideal, but I can live with it for now
<apritzel>
macromorgan: not really, AW's firmware setup is quite different from mainline, so it won't load a FIT image, for instance
montjoie_ has quit [Ping timeout: 480 seconds]
<macromorgan>
hmm
<apritzel>
and yeah, I would just try to get you unblocked with the DRAM
<apritzel>
you should try to dump the DRAM registers in the vendor U-Boot, then send this to junari and jernej, for inspection
<macromorgan>
vendor U-Boot doesn't have serial access (though I haven't tried hiding the kernel image from it yet). Can I still dump those registers from Linux do you think?
<macromorgan>
It's a 4.9 kernel that doesn't exactly appear to be built for security
<apritzel>
what's the problem with FEL? It's quite easy to use once you have this set up
<macromorgan>
tethered reboots
<tokyovigilante>
Have dumped from the image, TPR6 doesn't quite match what is output during boot and two TPR12s are output, but no joy yet.
<apritzel>
so yes, you should be able to dump the DRAM registers from Linux as well, using devmem2,or more comfortably my peekpoke (shameless plug: https://github.com/apritzel/peekpoke)
<macromorgan>
on the H700 front, should I worry that A-TF has references to various PMICs and mine isn't one of them?
<apritzel>
(that allows dumping ranges)
<macromorgan>
let me boot up BSP kernel later and see if I have access to /dev/mem... I imagine I should
<apritzel>
the boards with the AXP313 have the same problem, and that's not really a problem
<macromorgan>
okay good
<apritzel>
for H616 boards we actually have U-Boot drivers for the PMICs, so just need TF-A access for power-down
<macromorgan>
yeah, who needs powerdown when you can just yank the battery cable?
<macromorgan>
just kidding (sort of)
<apritzel>
this should be cleaned up, anybody please be my guest, it's not high on my list
<apritzel>
it's needed anyway, because the AXP313 is I2C only, while we address the AXP805 via RSB
<apritzel>
but that's not critical, if you can just ignore the error messages
<apritzel>
so my hunch is that the DRAM init algorithm for that type of DRAM is slightly different than what we have seen before, so it's not covered by the mainline driver yet
<apritzel>
junari said that he used a different phy init array for the T507, that's also worth trying
<apritzel>
do you guys have access to the schematic? Then creating a DT should just be a matter of diligence
<tokyovigilante>
I've only seen docs for the H616, and no board schematics
<apritzel>
for the PMIC: pick a supported PMIC, say the AXP805 or AXP313, then look at their U-Boot driver: drivers/power/regulator/axp_regulator.c
<apritzel>
those tables in there should give you an idea what data you really need. Correlate that to the datasheet to get a better understanding
<apritzel>
then look at the Linux driver (drivers/regulator/axp20x-regulator.c) and try to match the structures there to the U-Boot driver. I'd recommend the AXP313, which is the easiest
<apritzel>
then look at the github drivers for the AXP2202, and try to match them to mainline Linux drivers: chances are the structures are somewhat close to mainline
<apritzel>
then you should be able to extract the actual rail data (name, register offset, voltage ranges, enable bit) and put them in mainline structs
apritzel has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-sunxi
<tokyovigilante>
ok, I've built peekpoke and got it on the board, is there any guide to how to extract the right DRAM info?
<tokyovigilante>
hmm... "This generation of DRAM controller has DDR4 memory support, and still being mysterious now. "
warpme has joined #linux-sunxi
gamelaster has joined #linux-sunxi
norton has joined #linux-sunxi
warpme has quit []
chewitt has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
chewitt has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
tokyovigilante: yeah, sorry, this info in the Wiki is ancient and doesn't apply to the modern DRAM controllers anymore
<apritzel>
tokyovigilante: you should look at the addresses starting with SUNXI_DRAM_ in arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
warpme has quit []
chewitt has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
chewitt has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
warpme has quit []
gsz has joined #linux-sunxi
warpme has joined #linux-sunxi
chewitt has joined #linux-sunxi
chewitt has quit [Ping timeout: 480 seconds]
warpme has quit []
apritzel has joined #linux-sunxi
warpme has joined #linux-sunxi
<apritzel>
macromorgan: tokyovigilante: can you please add a Wiki page for that board? To collect information and track the progress on the remaining issues? Also to help you both coordinate your work?
chewitt has joined #linux-sunxi
dsimic is now known as Guest2753
dsimic has joined #linux-sunxi
Guest2753 has quit [Ping timeout: 480 seconds]
<apritzel>
is there any technical difference between the RG35XX H and Plus, apart from the form factor? And how are the button connected? Direct GPIO, I2C, or LRADC?
daschaos has quit [Remote host closed the connection]
<macromorgan>
I'm still trying to figure out the real technical differences. Best I can tell the 35XXH uses some sort of ADC to handle joystick inputs, whereas the 35XX+ has no joysticks. Beyond that it's just form factor I think.
<macromorgan>
the display connector looks like a 40 pin RGB/DPI connector versus the DSI stuff I'm used to messing with, and I assume it's the same for both devices.
daschaos has joined #linux-sunxi
<apritzel>
so the RK3566 use a different display interface?
JohnDoe_71Rus has joined #linux-sunxi
gamelaster has quit []
<macromorgan>
it can use a DPI/RGB display, but none of the devices I've messed with have, they've all been DSI (or in one weird case an SPI 3-wire controlled panel with DSI data). I guess DSI is easier to deal with since it has fewer pins and the hardware is already there?
<macromorgan>
The one Allwinner thingy I played with (an Anbernic RG-Nano) had a pure SPI screen which was... interesting.
gsz has quit [Ping timeout: 480 seconds]
<apritzel>
I think the H700 just lacks an DSI interface, that's why they reverted to RGB? I don't have any practical experience, but I think DPI is not more complicated to program, it's just different.
<apritzel>
macromorgan: the more challenging part is that the whole display engine (DE33) support is not upstream for the H616, jernej has some patches in progress on that
<macromorgan>
damn... I was hoping it wwas still DE2 based or something
<apritzel>
macromorgan: did you post the vendor DT somewhere already? Curious about how they attach the buttons ...
<macromorgan>
I honestly haven't checked, but I assumed they're GPIO buttons and ADC joysticks
junari_ has quit [Ping timeout: 480 seconds]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-sunxi
macromorgan has quit []
macromorgan has joined #linux-sunxi
<apritzel>
it that DT can be trusted, it's indeed direct GPIOs
<apritzel>
(we have seen bogus DTs in the past, where things were obviously overridden somewhere else)
<jernej>
maybe just dump /sys/firmware/fdt which will have fully patched dt?
vagrantc has joined #linux-sunxi
<jernej>
tokyovigilante: you can find DRAM controller regions in user manual, under memory map - MSI_CTRL, DRAM_CTRL and PHY_CTRL. Note that PHY_CTRL is big and only first megabyte or so is interesting.
norton has quit [Quit: WeeChat 4.2.1]
<macromorgan>
I don't have the user manual for an H700 though
<macromorgan>
I'm fairly sure the DTS can be trusted, I haven't gotten far enough yet to start configuring it though.
<jernej>
by chance I have T507 boot0 with exactly the same DRAM lib version, so I took a look and noticed that you need different phy_init value just as junari suggested
<jernej>
trouble is that decompilation is often unclear and I'm not sure if this is correct table
<KREYREN_oftc>
i could probably reverse-engineer this and make a mod for teres
<KREYREN_oftc>
what bus is the pinephone using for the modem? just USB works?
<jernej>
uart + i2s
<KREYREN_oftc>
that's fast enough?
<jernej>
hm, probably usb too
<KREYREN_oftc>
It has GPS too 👀
<jernej>
I'm just looking at schematic, I have no idea how software is designed
<jernej>
megi would know ^
<KREYREN_oftc>
The chip alone is expensive af
<KREYREN_oftc>
oh 25 EUR nevermind
<KREYREN_oftc>
oh wrong version so it's like 118 EUR h,,
<KREYREN_oftc>
is Quectel EG25-EC the same firmware-wise? It seems that the suffix means the location where the -G is for global and is like twice the price of e.g. EC for the EuroMarket
bauen1 has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
apritzel_ has quit []
apritzel has quit [Ping timeout: 480 seconds]
<tokyovigilante>
Wow great news on the DRAM and potentially PMIC! I have generated a wiki page for the RG35XX+ (will add the H as a redirect) and will fill it in later today.
apritzel has joined #linux-sunxi
<apritzel>
macromorgan: if the voltage rail for the DRAM (DCDC3?) is already at the correct 1.1V, then you can skip the SPL PMIC part, by selecting CONFIG_SUNXI_NO_PMIC
<apritzel>
that's what we do for the A64 and H6, where the boards have VDD_DRAM correctly set up at reset already
<macromorgan>
I did, however it froze shortly after
<macromorgan>
not sure why yet though
<apritzel>
well, if the voltage is wrong, then DRAM becomes very unstable
<apritzel>
I think lately some boards provide 0.9V on that rail, that's definitely too low
<apritzel>
macromorgan: if you look at (and copy) U-Boot commit d17d051c540a97b8, and fill that in with the data from the 717 datasheet, you might get beyond that
<macromorgan>
yes, I'm in the process of doing that now.
vagrantc has quit [Quit: leaving]
<apritzel>
DCDC3 smells like is the regulator meant for DRAM: the datasheet mentions that, and the max 1.84V voltage supports that (1.8V is the max you need, for DDR2)
<apritzel>
I cannot find anything in the bootlog or DT, though, but maybe the BSP kernel is friendly and has regulator_summary in sysfs?
gsz has quit [Quit: leaving]
paulk has quit [Ping timeout: 480 seconds]
paulk has joined #linux-sunxi
igraltist has quit [Remote host closed the connection]
igraltist has joined #linux-sunxi
<macromorgan>
I'll check. I think I have a long road ahead of me on this one...
<apritzel>
yes, but there are several scenic stops on the way, and you can short cut on some parts to make progress
<apritzel>
I mean, a display is for people without imagination. Text adventures are only really fun on a serial console, aren't they?
<macromorgan>
I'm going to probably just use BSP U-Boot for the moment and focus on the kernel
<macromorgan>
seems reasonable I suppose...
<apritzel>
normally I would agree, but I am not sure if the BSP U-Boot is able to boot a mainline kernel?
<apritzel>
though having BSP boot0, and the rest (U-Boot proper, TF-A, kernel) from mainline should work
<apritzel>
but indeed the most promising and rewarding route is to get the firmware somehow out of the way for now, and focus on the kernel, actually mostly the DT