ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
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?
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
<tokyovigilante> oh have found https://linux-sunxi.org/A10_DRAM_Controller_Register_Guide, will get fiddling
<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?
bauen1 has joined #linux-sunxi
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
warpme has quit []
warpme has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
daschaos_ has joined #linux-sunxi
daschaos is now known as Guest2766
daschaos_ is now known as daschaos
Guest2766 has quit [Ping timeout: 480 seconds]
warpme has quit []
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> macromorgan: can you try with https://pastebin.com/raw/QdFWyQ2w ?
<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
<jernej> it is :) I haven't worked on it since
<gamiee> what is needed to do for upstreaming it?
<jernej> issue was to figure out proper clock tree, because there is implied /16 divisor
<jernej> I'm sure you can find discussion on ML. IIRC MoeIcenowy tried to upstream it
<macromorgan> okay I'll look at that in a bit
<gamiee> jernej: I will take look on it, thanks.
chewitt has quit [Quit: Zzz..]
<macromorgan> jernej: Got me further... `Failed to set core voltage! Can't set CPU frequency
<macromorgan> `
<jernej> is detected DRAM size correct?
<macromorgan> yes, 1024MB
<macromorgan> U-Boot SPL 2024.04-rc1-00154-g73b5b47dd5-dirty (Feb 14 2024 - 11:59:46 -0600)
<macromorgan> DRAM: 1024 MiB
<macromorgan> Failed to set core voltage! Can't set CPU frequency
<macromorgan> so 3 lines total of console... but it sees the RAM. Now I'm looking at the regulator situation.
<jernej> I wonder if regulator setup is really necessary
<macromorgan> right, that might be on me
<macromorgan> might be necessary... told it no pmic and it freezes. I guess I'll keep plugging away
<jernej> macromorgan: do you know which PMIC is used? BSP DT sometimes uses names from different but compatible chips
<macromorgan> AXP2202
<macromorgan> let me physically check the chip
<jernej> do you know if AXP2101 is compatible?
<jernej> since I found datasheet for it
<macromorgan> well that's odd... chip physically says AXP717
<jernej> not really :)
<jernej> in case you need datasheet
<macromorgan> thanks
<macromorgan> it's odd that the devicetree itself says its an AXP2202 though
<jernej> not sure which one is correct
<macromorgan> well I can physically see an AXP717, so I'm guessing that's right?
<jernej> macromorgan: as I said, nothing new. BSP DT uses name from whatever compatible regulator is already implemented
<jernej> yeah, second then
<jernej> although they too are probably compatible
<macromorgan> yes, it looks like the 2202 and the 717 are very similar
<macromorgan> not that I have a datasheet... I'm basing it off of BSP files
<KREYREN_oftc> 👀👀👀👀
<KREYREN_oftc> The A64 has a 2G/3G modem?
<KREYREN_oftc> and teres seems to have an exposed pins that are wired to Y7 that coincidently look like someone could tape a sim card onto
* KREYREN_oftc was just looking into implementing an LTE modem and found this by accident
<KREYREN_oftc> seems to be wired for a sim card also :D
<jernej> KREYREN_oftc: many AW SoCs have smartcard support, which can be used for sim card reading
<jernej> but there is no mainline driver for it
<KREYREN_oftc> nooooooooo
<KREYREN_oftc> the dream of oshw 2G/3G modem i can use in teres ruined
<macromorgan> 717 seems to be a cut down 2202
<jernej> KREYREN_oftc: you can implement it? :)
<jernej> anyway, you still need modem
<gamiee> KREYREN_oftc , it is just SIM module reader, A64 doesn't have modem
<KREYREN_oftc> The schematic says modem O.O
<KREYREN_oftc> I guess it expects some proprietary thing connected to these pins?
<KREYREN_oftc> more than likely the same modem olimex sells as UEXT mod
<KREYREN_oftc> or is there any good known modem that works and is at least somewhat libre?
<jernej> modem in pinephone has been hacked to death
<KREYREN_oftc> what modem is that
<jernej> but it contains it's own linux environment afaik
<KREYREN_oftc> Quectel EG25-G ?
<jernej> yes
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.0 Quasar http://www.kvirc.net/]
<KREYREN_oftc> 👀
<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
vagrantc has joined #linux-sunxi
bauen1 has joined #linux-sunxi