smaeul has quit [Remote host closed the connection]
smaeul has joined #linux-sunxi
smaeul has quit [Remote host closed the connection]
smaeul has joined #linux-sunxi
smaeul has joined #linux-sunxi
hipboi has quit [Quit: hipboi]
smaeul_ has joined #linux-sunxi
smaeul has quit [Ping timeout: 480 seconds]
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
smaeul_ has quit [Read error: No route to host]
smaeul has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
smaeul has quit [Remote host closed the connection]
smaeul_ has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
smaeul_ has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
smaeul has joined #linux-sunxi
smaeul has quit [Remote host closed the connection]
nolash has quit [Remote host closed the connection]
nolash has joined #linux-sunxi
smaeul has joined #linux-sunxi
smaeul has quit [Read error: No route to host]
smaeul has joined #linux-sunxi
smaeul has quit [Read error: No route to host]
smaeul_ has joined #linux-sunxi
smaeul_ has quit [Read error: No route to host]
smaeul has joined #linux-sunxi
dsimic is now known as Guest6450
dsimic has joined #linux-sunxi
Guest6450 has quit [Ping timeout: 480 seconds]
smaeul has quit [Read error: No route to host]
smaeul_ has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
smaeul_ has quit [Remote host closed the connection]
smaeul_ has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
nolash has quit [Ping timeout: 480 seconds]
warpme has quit [Ping timeout: 480 seconds]
smaeul has joined #linux-sunxi
smaeul_ has quit [Read error: No route to host]
smaeul has quit [Read error: No route to host]
smaeul has joined #linux-sunxi
smaeul has quit [Read error: No route to host]
smaeul has joined #linux-sunxi
smaeul has quit [Remote host closed the connection]
nolash has joined #linux-sunxi
smaeul has joined #linux-sunxi
warpme has joined #linux-sunxi
nolash has quit [Ping timeout: 480 seconds]
warpme has quit [Ping timeout: 480 seconds]
<apritzel>
iscle: where did you get the AXP2202 information from? Is there a datasheet? Because I was under the impression that it's the same as the AXP717, as least the 2202 BSP driver supports AXP717's.
apritzel has quit [Remote host closed the connection]
warpme has joined #linux-sunxi
szemzoa_ has quit [Ping timeout: 480 seconds]
szemzoa has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
gamiee_ has joined #linux-sunxi
iscle has joined #linux-sunxi
<iscle>
apritzel: From some leaked allwinner code haha but I think it indeed is the same as the AXP717 (some boards use that one instead)
<iscle>
I just removed it, I completely missed the "AXP2202" in "other names" lol
<iscle>
apritzel: Do you know if the AXP717 sends meaningful data for the 0x03 register? (CHIP ID)
<iscle>
A board I have only sends 0xFF on that register, I have to read 0x0e for the CHIP_ID_EXT in order to detect it. I don't know what IC the board uses, if 2202 or 717, but the 0x0e register returns "0x02"
<iscle>
I can't physically check the IC as it's under a heatsing
<iscle>
s/heatsing/heatsink
warpme has joined #linux-sunxi
<apritzel>
iscle: ah, thanks for the confirmation!
<apritzel>
and no, I don't think there is an ID register for the AXP717. Why do you need one?
<apritzel>
the valid ID bits are pretty limited anyways, so it's not a big source of information. And the PMIC (and its address) is just one on the platform details you would need to know, and put in the DT
<iscle>
apritzel: I was just wondering, as when I reverse engineered the code that initializes the A133's AXP chip for dram and mmc, it checks for 4-5 AXP ICs by comparing the 0x03 register on some, and 0x0e on others.
<apritzel>
interesting, didn't know about that
<apritzel>
for mainline U-Boot's SPL we just set the AXP in the defconfig, and U-Boot proper and the kernel look at the DT
<apritzel>
so far there was often a close relationship between SoCs and PMICs, though that seems to vary a bit more lately
<iscle>
I was trying to reverse engineer it for the MMC dump code, which for some reason does not detect the card. I thought it was a voltage issue but turns out the regulators are already enabled...
<iscle>
"there was often a close relationship between SoCs and PMICs" > well, as far as I know, manufacturers tend to have a specific PMIC for a specific SoC most of the time, with the efuses set to the required voltages. At least that's how MediaTek does it
<iscle>
Most MediaTek SoCs have a specific (also MediaTek) PMIC they use, which is not shared with others
warpme has quit [Ping timeout: 480 seconds]
<apritzel>
yeah, that's very similar for Allwinner: the contemporary PMIcs seemed to often match the power requirements. Also I think AW bundles PMICs and SoCs, or at least merchants do
<apritzel>
regarding MMC: are you using an SD card or the eMMC?
<apritzel>
I am asking because for some odd reason eMMC does not work on the H616 in U-Boot
<apritzel>
SD card works, though, and eMMC is absolutely fine in Linux
<iscle>
For MMC I'm trying both, internal eMMC and I have an SD card in the slot too just in case. For internal eMMC I'm guessing it's using MMC2 in 8-bit mode, and for SD card 0 or 1 in 4-bit mode. I copied the code from U-Boot, and I was about to check it against the RE
<apritzel>
which makes me wonder if that's due to U-Boot reading just the FIFO, whereas the kernel uses the built-in DMA engine to transfer data
<iscle>
agains the RE'd init library
<apritzel>
and yes, SD card is almost universally MMC0 in 4-bit mode, at 3.3V, whereas eMMC is MMC2 in 8-bit mode, at a board specific voltage
<iscle>
Could it be bit 31 in the MMC CTRL register? FIFO_AC_MOD: FIFO Access Mode: 0: DMA bus 1: AHB bus
<apritzel>
iscle: and keep in mind: the BootROM can access both, without any board (or PMIC) knowledge, so it's using fixed parameters (per SoC)
<apritzel>
which means we can piggy-back on this assumption, and don't need a lot of flexibility (just one setting per SoC is enough)
<iscle>
Hmm, that's true, I did not think about the bootrom being able to access it. Then I don't need to do anything with the AXP IC, it should be already set up.
<apritzel>
exactly!
<iscle>
Also, clock should be set up (might be slow, but working)
<apritzel>
the board vendor needs to configure the eMMC in a way where it's usable at reset, so with the PMIC's defaults
<iscle>
I'm booting into FEL with the FEL button on the board, that one uses the bootloader to reboot into fel, or is it handled by the bootrom?
<apritzel>
well, clock is a different story, and you need to follow the MMC protocol here, so I think starting with 400KHz, then switching to whatever you negotiate (or a safe 50 MHz@4bit, for instance)
<apritzel>
FEL button is handled by the BootROM, so there would be no user provided code involved there
<apritzel>
there are ways to enter FEL mode with user provided code, like our fel-sdboot.sunxi, but a true FEL button does not need this
warpme has joined #linux-sunxi
<iscle>
Okay, so the question now is: if it reboots to FEL with the button, does it also set up the clocks and mmc peripheral? haha I might need to dump it and check it out
<apritzel>
and indeed a FEL button is the best way to catch the SoCs in its most pristine way
<apritzel>
some BootROM disassemblies contain some annotations
<apritzel>
I think sun50iw10 is not among those
<apritzel>
but in general the FEL button should be checked before MMC is tried
<apritzel>
if you fall through to FEL because nothing else worked (no SD card and no/nothing on eMMC), then it's of course different
<apritzel>
and the BootROM does proper MMC clock setup, following the protocol
<apritzel>
iscle: btw: you can check the state of the FEL button via bit 8 in 0x03000024 (VER_REG in SYS_CFG)
<apritzel>
iscle: oh, and it's not bit 31 in SMHC_CTRL, we set this correctly. I should have said that is works for a bit: we can dump like six sectors, but then it breaks
<apritzel>
there is an ugly workaround with a really slow clock, but I still hopes it's something else, maybe the FIFO level register
aggi has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
Hypfer has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
Hypfer has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
MasterR3C0RD is now known as MasterR3C0RD
<MasterR3C0RD>
apritzel: Would it be of any use to offer an nboot dump for the sun50iw10p1 to that repo? It appears there is no iw10p1 broms