<Kirby64>
apritzel: yeah, I'm using AXP305_POWER. And I called them out as AXP_DCDCA - AXP_DCDCE
<Kirby64>
... which if those are the wrong config settings then that very well may be our issue
<apritzel>
though looking at the reset values again now makes me think it doesn't matter: the DRAM value (DCDCE/DCDC5) is correct, courtesy of 0 being the right and also the reset value
<apritzel>
and the rest is fine for booting
<Kirby64>
Hm. So, leads back to either DRAM settings or the channels thing I guess
<Kirby64>
None of the LDO settings matter typically, I take it?
<apritzel>
not typically for the SPL and the booting phase in general
<Kirby64>
hmmm
<Kirby64>
well I went ahead and dumped all the ldo settings too for good measure
<Kirby64>
lots of non-standard values
<apritzel>
yes, but they don't matter for booting. The basic settings must be correct at reset time already, otherwise the BootROM wouldn't work
<apritzel>
as the BootROM is fixed and only knows about the SoC, not the board, so for instance SD card and eMMC must work with the reset settings
<apritzel>
it's really only the DRAM and maybe the CPU voltage if you want to run at higher frequencies that need adjustment
<Kirby64>
Yeah, so I'm a bit at a loss then. It might be the channels issue I guess
<apritzel>
well, there is much more about the DRAM that might not be quite right. Probably worth talking to MasterR3C0RD, he could provide given better advice what to try
<Kirby64>
Yeah, good idea. I appreciate all the help you've provided along the way, by the way. Extremely helpful, and definitely much further along than I was a few weeks ago
<apritzel>
for instance we have seen TPR13 (I think) to contain a bit field of algorithms to use, and the BSP driver does not implement all of them
<Kirby64>
Is what each of those registers does documented somewhere? I tried digging in the A133 user manual or datasheet but I didn't seem to turn up anything that matches those names
<apritzel>
for some boards we were skipping those extra algos, by tweaking the DRAM parameters to contain the values that the BSP eventually "measured"
<Kirby64>
Or is it all "free apps engineer from Allwinner included in the price of a purchase of 50k" type thing
<apritzel>
for board vendors: probably yes
<apritzel>
DRAM setup is dark arts, and no official documentation at all. There is some IP documentation from other vendors, which we found to be close
<apritzel>
but the bulk is disassembly / decompilation / reverse engineering
<Kirby64>
Well, hopefully my weird new board can eventually help
<Kirby64>
I doubt this type of DRAM I'm using will only be used once
hentai has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
<Kirby64>
Huh.
<Kirby64>
Well, disabling full width and forcing 16-bit didn't work either?
<Kirby64>
it correctly shows 1024MB now
<Kirby64>
as expected, since it can't address both sides
<Kirby64>
once again it refuses to boot though
<Kirby64>
bypassing simple RAM test hangs as soon as it tries to reallocate uboot
<dlan>
Lightsword: did you check docs/H616/Linux_EMAC_开发指南.pdf (although in chinese), AC300 use MDIO to initialize A300 + EPHY (while AC200 using TWI/I2C interface), page 11, 3.2.3.2
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<Lightsword>
dlan, yeah, think I saw that before, had taken me a bit to figure out which docs were relevant and such
<Kirby64>
apritzel: so, I've thrown in a bunch of debug stuff... and my u-boot appears to be hanging once it attempts to execute out of the top of RAM. I disabled u-boot reallocation via the flag (which I had to patch in...) but that unfortunately didn't help
<Kirby64>
but, board info, gd, and fdt are all top of RAM, so I kind of assume it may not be working there?
<Kirby64>
or, stack pointer maybe.
<Kirby64>
On the other hand, global data should ostensibly include the relocation flag... so I'm a bit surprised if it's causing issues in such a weird way
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
<Kirby64>
MasterR3C0RD: if you get a chance, any input on why my DRAM doesn't appear to be initializing properly on an A133? It's 2GB of LPDDR4 and nothing seems to really be working quite right...
<Kirby64>
dlan: I ported that patch to my branch. relocation disables u-boot relocation, but it doesn't disable the top-of-ram locations for SP/FDT/GD/etc
<Kirby64>
Which I suspect is part of my problem (besides the whatever issues with DRAM init)
JohnDoe_71Rus has joined #linux-sunxi
<dlan>
right, probably still the issue of DRAM init
gsz has joined #linux-sunxi
<Kirby64>
yeah, I mean I'm pretty certain it's dram init issues... just, I'm not sure where to go on DRAM init besides randomly changing settings which obviously is pointless
<Kirby64>
unless there's more to discover in the boot0 that sunxi-fw doesn't show
gsz has quit [Quit: leaving]
<MasterR3C0RD>
Kirby64: DRAM values have some weird black magic paths sometimes; any logs from the DRAM init?
<MasterR3C0RD>
Most of the actual DRAM init should be working fine if you're using the latest bits off my branch, the only thing that's really been a pain point is the address mapping (mctl_set_addrmap)
<MasterR3C0RD>
Strange issues there that like to break addresses over 2GB, though I'm sure there's extra cases that'll break depending on the specific DRAM organization it has
<MasterR3C0RD>
If your DRAM is the 16Gb one in the datasheet you posted, should be detecting row_bits = 15, col_bits = 6, bank_bits = 3, rank_bits = 1 it seems
<Kirby64>
My DRAM is indeed the one I posted, the Rayson datasheet
<Kirby64>
Unfortunately no logs during BSP init
<Kirby64>
UART totally disabled and I don't have any log access. I could look around SRAM after I reset it (since boot0 is stuffed in there), but unclear if I'd see anything useful
<MasterR3C0RD>
Hmm that makes things quite difficult. For some reason the TPR values can be different from those you get from sunxi-fw (even with the patches to enable additional support). What about when booting SPL, do you get anything from the DRAM init code there?
<MasterR3C0RD>
You *should* get code from there that's something like "cols = 6, rows = 15, banks = 3, bank groups = 0, ranks = 1, full width = 1" or something similar
<Kirby64>
Booting SPL does do DRAM testing just fine (I patched it out to see if there was an issue with the simple test though...). The code I currently get is: DRAM:Testing ranks = 1, 32-bit bus
<Kirby64>
cols = 10, rows = 15, banks = 3, bank groups = 0, ranks = 1, full width = 1
<Kirby64>
expected size: 2048 MB
<Kirby64>
so, cols=10, vs 6 as you state
<Kirby64>
column addresses are listed as C[9:0] though; where are you seeing 6? cause 2^6 = 64?
<MasterR3C0RD>
Didn't notice that; looks like it's probably correct as cols = 10 since the math works out to give the expected 2GB
<Kirby64>
yeah the cols=64 fetch boundaries throws me off a bit
<MasterR3C0RD>
What issue specifically are you running into? Is it failing to get into the U-Boot shell?
<Kirby64>
It's failing to get past the U-boot reallocation phase. Or specifically, when it seems to start executing from the top-of-memory stack pointer
<Kirby64>
I've disabled relocation and disabled the simple DRAM testing in that one
<Kirby64>
so, although it states simple DRAM test is 'ok' it definitely keeps showing aliasing
<Kirby64>
(if I didn't stub that out)
<MasterR3C0RD>
Okay, I have seen that before. Points to either address mapping or MRs being wrong in my experience. Been a bit since I touched the code, but I don't think there's a special case for cols=10 rows=15...
<Kirby64>
Any idea if it would somehow be related to channels per die? apritzel seemed to think this DRAM was extra weird
<Kirby64>
i.e., technically there's 4 channels on this DRAM
<MasterR3C0RD>
I would assume that the RAM would be wired such that it's addressable as usual, but I suppose anything could happen. Do you have sunxi-fw output from boot0?
<Kirby64>
and yea I guess this RAM seems pretty normal for dual rank from the block diagrams I can gather...
<MasterR3C0RD>
Autodetected parameters look right
<Kirby64>
Yeah... I've also tried slowing down the RAM as well to no avail
<MasterR3C0RD>
Can you try jumping back to commit 3eacb20 ("Fix typo in 16-row-10-column special case")?
<Kirby64>
Yup, hold please
<MasterR3C0RD>
It reverts the address mapping code to an older version that was a more direct port of boot0's address mapping
<Kirby64>
to be clear: back to 3eacb20 or to the commit right before that?
<MasterR3C0RD>
That commit exactly
<Kirby64>
kk
<Kirby64>
still seems grumpy. Same output for col/row/etc
<Kirby64>
For reference, the error if you let dram test try is: DRAM simple test FAIL----- address 80000000 = f01234567800bc00
<Kirby64>
Potentially aliased with 7b2ff908
<MasterR3C0RD>
Oh that's very interesting... sounds more like 2 of the data lines are messed up. Is it the same DRAM test failure on both?
<MasterR3C0RD>
Or rather, not that data lines are messed up but perhaps timings or something else are
<Kirby64>
I believe so. Let me dig through my history I'm sure there's a pastebin of the original aliasing before
<MasterR3C0RD>
I would bet there's potentially something wrong with DRAM parameters if it's the same. Irritatingly boot0 changes some of the parameters somewhere that I couldn't easily track down during RE
<Kirby64>
yup, identical aliasing/address on the newer branch
<Kirby64>
I've heard discussion of 'modifying' boot0 to return to FEL... maybe that's a path to pull out the proper parameters?
<Kirby64>
really wish there was another way into this thing
<MasterR3C0RD>
I'll take a deeper look on my end tomorrow, but there should be a way to force boot0 to print out debug info (there's a data structure at the start that matches some values); I don't remember the details off the top of my head but if you look at the Sonic Pad's BSP (specifically boot0 private header stuff) you should be able to track down what I'm
<MasterR3C0RD>
talking about
<MasterR3C0RD>
Might let you re-enable serial
<Kirby64>
oh, that could be the ticket. The expectation being that if we get the debug output it'd spit out whatever values it decides to shove into the registers?
<MasterR3C0RD>
Yeah, exactly
<Kirby64>
which, I think I've seen those stubs for output in the hex code. Certainly looks like it has the ability to output its training data...
<Kirby64>
the 'HELLO! BOOT0 is starting!' certainly exists haha
<Kirby64>
Anywho, if you could point me to any work done on the Sonic Pad boot0 that did something similar I can try my best there. Hard to find documentation a lot of the time though :(
<MasterR3C0RD>
Honestly every other device that this has been tested with (~5 I think) has had serial open by default thus far; all of the focus for boot0 reveng was for DRAM init AFAIK
<MasterR3C0RD>
But there are flags in the boot0 binary you should be able to set to enable serial/debugging that were mentioned in the priv_head data structure or something; Sonic Pad vendor tree has that somewhere but afraid I can't look too hard right now
<Kirby64>
Yeah, this one is such an odd one. I would expect it'd have serial enabled because it has a port for it on the board.
<Kirby64>
Like, full connector.
<Kirby64>
Same with the USB FEL, and the buttons for FEL/reset
<Kirby64>
Anywho, I appreciate you taking a look. I'll keep poking around myself. Hopefully the sonic pad stuff can help
freemangordon1 has quit []
freemangordon has joined #linux-sunxi
Kirby64 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
paulk-bis has joined #linux-sunxi
paulk has quit [Read error: Connection reset by peer]
warpme has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
cnxsoft has quit []
warpme has quit []
<tokyovigilante>
Ok, got into FEL mode on my A523 device - AWUSBFEX soc=00001890(A523) 00000001 ver=0001 44 08 scratchpad=00061500 00000000 00000000
<tokyovigilante>
No UART is going to be a real pain though
<tokyovigilante>
Is the microSD-JTAG thing supported by all boards or would it have to be designed in?
<tokyovigilante>
Ah I see that's already been suggested, sorry
warpme has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.6, revision: 5.2.6+git-7614-6f23368f1, build type: debug, sources date: 20160102, built on: 2025-03-30 13:34:35 UTC 5.2.6+git-7614-]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has quit []
paulk-bis has quit []
paulk has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
apritzel has joined #linux-sunxi
ungeskriptet_ has joined #linux-sunxi
ungeskriptet has quit [Ping timeout: 480 seconds]
kepstin has quit [Remote host closed the connection]
kepstin has joined #linux-sunxi
kepstin has quit [Remote host closed the connection]
kepstin has joined #linux-sunxi
warpme has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
apritzel has quit [Ping timeout: 480 seconds]
iscle has joined #linux-sunxi
warpme has joined #linux-sunxi
<iscle>
Hi! I tried searching on the chat history but saw nothing related to it. I own an A733 device, but the datasheet / user manual is nowhere to be found. Anyone has got access to it?
<paulk>
not as far as I know
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
iscle has quit [Remote host closed the connection]
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
JohnDoe_71Rus has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Ixnus has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Ixnus has left #linux-sunxi [#linux-sunxi]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
ftg has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: No route to host]
Schimsalabim has joined #linux-sunxi
Kirby64 has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
dsimic is now known as Guest14611
dsimic has joined #linux-sunxi
Guest14611 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
ftg has quit [Ping timeout: 480 seconds]
Kirby64 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
colinsane11 has quit []
colinsane has joined #linux-sunxi
ftg has joined #linux-sunxi
<MasterR3C0RD>
jernej: I think I might've finally found a PHY that matches the A523
<MasterR3C0RD>
Also check DDRPHY_REG14 (offset 0x54)
<MasterR3C0RD>
PHY_BASE + 0x0 has bits 12:8 written to differently if DRAM is LPDDR4 or not, which corresponds with reg_channel_en, and behavior also matches enabling 2 channels instead of 4 as suggested in that manual. Also, 0x54 is where the phy_init data is written to
<MasterR3C0RD>
reg_cmd##_wrap_sel selects the pins used for addresses, in other words it's CA pad swizzle
<MasterR3C0RD>
In other words A523 uses an Innosilicon [LP]DDR3/[LP]DDR4 DDR PHY, likely the same for the A133 but with different stride settings
<montjoie>
apritzel: does your SD patch could help my previous uboot stuck problem ?
colinsane1 has joined #linux-sunxi
colinsane has quit [Ping timeout: 480 seconds]
BroderTuck has joined #linux-sunxi
<jernej>
MasterR3C0RD: nice find! that certainly looks like similar PHY. It looks like 0x70 reg isn't described, but this doc should certainly explain a lot
<jernej>
maybe we can borrow some code from RK
<jernej>
(if it exists)
<MasterR3C0RD>
It's possible there's just more pads that aren't on the RK3568
<MasterR3C0RD>
Should be able to compare the writes on on A523 to A133/H616 as well to rebuild that map too
<jernej>
Kirby64, apritzel: LPDDR4 chip can have two channels, each of them 16 bit. You can just connect most control signals (not all) together and communicate to it as single 32-bit channel.
<jernej>
I think LPDDR4 channels are always 16 bit, so in order to have 32 bit bus, you need dual channel chip
<jernej>
MasterR3C0RD: I suspect H616 is some early version of same PHY family
<jernej>
MasterR3C0RD: there are register descriptions missing above 0x300 offset
<jernej>
Lightsword, apritzel: let's first merge ac200 code, I would be very happy with that :) then we can discuss best method for ephy selection :)
<Lightsword>
jernej, what's needed to merge that at this point?
<jernej>
well, iirc, apritzel send rfc a while back with minimal feedback
<jernej>
I guess update is needed and possibly slight refining
<MasterR3C0RD>
jernej: Looks like the DRAM init is not in Rockchip U-Boot, but rather is part of something called IDBLoader that seems to have the same purpose as boot0/SPL on AW
<MasterR3C0RD>
And surprise surprise, it's binary distribution only
<jernej>
in the past, RK provided open source drivers, so I hoped that this will be the case here too
<jernej>
oh, well, maybe some RK enthusiast will reverse engineer it
<Lightsword>
jernej, at the moment I don't have physical access any AC200 based boards so it's a bit tricky for me to test
<jernej>
right
<MasterR3C0RD>
jernej: Maybe, but wouldn't hold my breath. Collabora recently got most of the RK3588 (newer with DDR5 support; A733 PHY perhaps?) boot stages reimplemented, However RK said in a Debian bug they won't be open-sourcing the DRAM binaries
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
BroderTuck has quit [Quit: -]
aggi_ has joined #linux-sunxi
aggi has quit [Ping timeout: 480 seconds]
<apritzel>
jernej: I just sent one or two preparatory patches back then, I think, for a PHY taking a "clocks" property. There was some pushback, but IIUC something similar went now in
<apritzel>
jernej: and I was thinking to upstream the AC300 first, as this would be much easier: we just need a PHY driver. We could build on your one, which we deemed optional back then
<apritzel>
this PHY driver and the PWM driver is all we need, right?
jelly has quit []
jelly has joined #linux-sunxi
farhan2 has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]