<hexdump0815>
apritzel: i did give the gpio register dumping in u-boot a try and was also able to verify the sd card gpio on my x96q box by diffing the gpio state with sd card inserted and out
<hexdump0815>
apritzel: but on the tx6s box i did not see any change on the gpio values when changing the card ... the strange thing is: in android the box does recognize if an sd card is inserted
<hexdump0815>
apritzel: any idea how else it might recognize it?
<apritzel>
hexdump0815: nice, good job
<apritzel>
hexdump0815: did you try *all* GPIOs?
hlauer has joined #linux-sunxi
<hexdump0815>
apritzel: i did md.l 0x0300b000 128 - does that make sense? in my understanding that should cover all of them, but i might be wrong
<apritzel>
hexdump0815: did you configure the pins as "input"
<apritzel>
?
<hexdump0815>
apritzel: ok, then i guess my idea of how it works seems to be too simple :) ... how do i configure them as "input"?
<apritzel>
every port occupies 0x24 bytes (9 words)
<apritzel>
the first four are the function, 4 bits per pin
<apritzel>
you typically spot a lot of 7's, which means High-Z
<apritzel>
GPIO input is function 0
<hexdump0815>
oh - looks i overlooked some of the things you mentioned last time ...
<apritzel>
well, a quick diff seemed to already worked, because the pin was already configured as input
<apritzel>
it should be safe to replace every 7 with a 0, since HighZ is very similar to GPIO input
<apritzel>
yeah, PI ends at 0x144, so you just need to dump 0x51 registers
<apritzel>
(U-Boot takes everything as hex, even without the 0x prefix)
<apritzel>
I would focus on PortG and H first, they have the most usable free pins
<apritzel>
page 690 in the H616 manual gives a nice overview of the pins
<hexdump0815>
just to understand it right: PI starts at 0x120 then? and 0xfc until there would be PH and 0xd9 to 0xfc PG?
popolon has joined #linux-sunxi
<hexdump0815>
this is the x96q case: https://pastebin.com/raw/6jvMCfcb - here 0xc7 flips from 00 with sd to 40 without sd - according to dts it is PF6 - how am i getting this mapped to each other?
<smaeul>
0xc4 is the PF status register, 0x40 is bit 6 => PF6
<smaeul>
where PF is (zero-based) port number 5, and 5 * 0x24 + 0x10 => 0xc4
Guest92538 has quit [Remote host closed the connection]
<hexdump0815>
smaeul: thanks a lot - now i got it ... and to configure the gpios as input as mentioned above by apritzel i have to set 0xb4-0xc3 to 0 then?
<apritzel>
hexdump0815: roughly, but not all pins are implemented
<apritzel>
for PF it's only 7, in fact, so just the first word would suffice
<apritzel>
PF6 is the 7 in "07222222"
<apritzel>
hexdump0815: and be careful with clearing non-7's to 0, as you might mess up something (losing the UART comes to mind)
<hexdump0815>
apritzel: so for the PG case i would set 0xd9-0xdf and 0xe2-0xe2 (all the 7 in the PG range) to 00?
<hexdump0815>
apritzel: sorry 0xe2-0xe3 i ment
<smaeul>
MMIO here is always done with 32-bit words, so you wouldn't set 0xe2 or 0xe3, you do a read-modify-write on 0xe0
vagrantc has quit [Quit: leaving]
<hexdump0815>
ok - what would be the corresponding proper u-boot command this example?
<smaeul>
mw.l 0300b0e0 0
<smaeul>
the reading you already did, and the modifying is done in your head :)
<apritzel>
exactly!
<smaeul>
though it would be nice if u-boot had a set-bits or clear-bits command
<apritzel>
well, it's a bootloader, not a debug monitor ...
<apritzel>
we just abuse it as such, since it's available and is comparably easy to get running
<hexdump0815>
so it would be: mw.l 0300b0e0 0 + mw.l 0300b0d9 0 + mw.l 0300b0dd 0 for the full PG case here then?
<smaeul>
there's already three memory-modify commands (mm, mw, nm), what's the harm in adding two more? ;)
qschulz has quit [Read error: Connection reset by peer]
<smaeul>
hexdump0815: you're off by one, it would be d8 and dc
<smaeul>
otherwise that's correct
<hexdump0815>
smaeul: right - zero start :)
qschulz has joined #linux-sunxi
<apritzel>
hexdump0815: you will learn that pretty quickly, since unaligned accesses to device memory will introduce you to the exception handler ;-)
<hexdump0815>
apritzel: i think i already ran across that - it will reboot - right? ... btw. nothing in PG, so let me try PH
hlauer has quit [Ping timeout: 256 seconds]
<hexdump0815>
so for PH it would be mw.l 0300b0fc 22 + mw.l 0300b100 0 then?
<apritzel>
hexdump0815: yes
<hexdump0815>
nothing there neither - so lets check PI, which is what is actually in the android dtb ... btw. can it also be that some wait time is needed? i think i saw such a parameter at least in a kernel dts - does it exist also for u-boot?
<apritzel>
no wait time for CD GPIO pins
<apritzel>
PortL is a special snowflake, it's at 0x7022000
<apritzel>
PortI is Ethernet, I doubt they use a pin there
<apritzel>
does the Android dtb list a CD pin for the SD card?