<peterm6881>
something must have gone wrong with your test earlier, the R3c can be powered from the otg port
<peterm6881>
alone
<Xogium>
hmm how do you know that ?
<peterm6881>
I powered it from it via OTG on a wall wart, logged in via the NEC, then disconnected the TTL usb, so it was again just running on OTG
<peterm6881>
when I reconnected the NEC and connected via puTTy again, it was still logged in to Buildroot
<peterm6881>
excuse the bad grammar
<Xogium>
hmm
<peterm6881>
I dunno what happened when you tried it
<Xogium>
well at least on my computer, it doesn't seem to work
<peterm6881>
but it definitely stayed logged on despite running on purely OTG power
<peterm6881>
now, im using a wall wart for OTG power, to replicate a power bank
<peterm6881>
let me try it again with an actual power bank
<peterm6881>
i mean, as soon as I plugged in the OTG, the green power LED came on
<Xogium>
hmm I wonder if
<peterm6881>
i knew id read somewhere you can power from either
<Xogium>
the thing I did was to connect the usb with uart first
<peterm6881>
interesting, i connected otg first
<peterm6881>
by the way they are labelled ttl and otg
<peterm6881>
let me replicate it how you described earlier
<peterm6881>
gimme a sec
<peterm6881>
i'll even use screen
<peterm6881>
ok its booting
<peterm6881>
ok im at the prompt, wait
<peterm6881>
ok now ive connected another NEC usb to otg
<peterm6881>
screen still ok so far, still at the login prompt. wait
<peterm6881>
now ive disconnected the ttl
<peterm6881>
wait
<Xogium>
for me, as soon as I unplug uart, the green light goes out
<peterm6881>
thats bizarre, sounds like you have a dodgy micro usb cable
<peterm6881>
as soon as i reconnected the ttl and relaunched screen, it was still at the mangopi login prompt
<peterm6881>
it can definitely be powered from OTG, no question. So I think you have a dodgy cable or something weird going on with the power on your usb ports
<Xogium>
well here's the thing. I can swap the cables just fine and get exactly the same result
<peterm6881>
something peculiar about the power on your usb
<Xogium>
yeah, maybe. Whatever lol
<peterm6881>
meh, dont worry about it. The important thing is I can keep it alive
<Xogium>
heh
<Xogium>
will try and port our stuff to it
<peterm6881>
so, i can boot via laptop, and just keep it powered up all the time. I emailed mangobuge, did you read it?
<Xogium>
yeah I saw
<peterm6881>
exciting times
<peterm6881>
it'll blow my mind if the software just runs
<Xogium>
navit and such probably will
<Xogium>
but I need to trim down the device tree
<Xogium>
although… How many i2c buses do we get ?
<Xogium>
the big problem is that we can't even trust the freaking schematics
<peterm6881>
its bizarre their image boots ok, but the external tree doesn't. My problem is i have no idea what the difference is when it comes to booting up. Am I correct in saying the u-boot and kernel is untouched?
<peterm6881>
let me check that
<Xogium>
yeah its all the official stuff from them. I haven't modified anything related to that
<peterm6881>
what Multiplexing Function did we decide they were using?
<Xogium>
uh… let me check your email
<peterm6881>
they're using uart1 for the bridge right?
<Xogium>
multiplexing function 3
<peterm6881>
hmm... this could be quite bad
<peterm6881>
of course mangobuge never answered to confirm or correct my analysis
<peterm6881>
it 100% hinges on if its uart1 in the bridge
<peterm6881>
on, ffs
<peterm6881>
question, can you tell which or how many i2c bus's are enabled currently?
<Xogium>
only one
<Xogium>
enabled in the device tree
<peterm6881>
can you tell which it is? tw something
<Xogium>
currently connected to a er… lcd panel we don't have
<Xogium>
its just called i2c0
<peterm6881>
this is too hard, because they have dedicated clock and data pins, labelled as such, so that is assumed to be an i2c connection. However i have no information what GPIO on the Allwinner chip they are physically connected to. The LCD panel referred to is probably connected via one of the funky ZIF sockets
<peterm6881>
so, let me check the chip
<peterm6881>
3 TWI controllers on board
<peterm6881>
so, enable i2c 1 and 2, in addition to 0
<peterm6881>
the challenge for us is to reverse engineer this fucking board and deconstruct whatever the hell way they designed it, because none of it is documented
<peterm6881>
we just have to figure out what works by trial and error
<Xogium>
yeah… erk
<peterm6881>
lol
<peterm6881>
i just emailed you the basic version of the F1C200s, are you able to read the tables on pages 14 and 15
<peterm6881>
f1c200s datasheet i meant
<peterm6881>
it gives you the GPIO depending on what Multiplex Function is selected
<peterm6881>
Now, the following is exposed to pins, what much is absolutely certain, ok?
<peterm6881>
THAT much, i meant
<peterm6881>
PA0 to PA3, and PE0 to PE11
<peterm6881>
what im not 100% certain on is what GPIO they are currently using elsewhere, and what Multiplexing Function they have selected. I THINK its 3, out of a possible 6
<Xogium>
hmm
<Xogium>
will try
<peterm6881>
I think its mode 3, because I believe thats the only one that gives you UART1 on unexposed pins
<peterm6881>
specifically, PD1 to PD4
<peterm6881>
the bottom line is, the chip supports 3 TWI interfaces, so enable i2c 1 and 2
<peterm6881>
and we'll work out which works for our oled, either the dedicated Clock and Data pins, or TWI0 clock and data on PE11 and PE12 respectively
<peterm6881>
I think the pins labelled clock and data are TW10, connected to GPIO PD0 and PD12
<peterm6881>
although why would they provide pins, label them clock and data, but not enable them in their build.....
<peterm6881>
its a head fuck, but if we decode their board, it brings people to our party
<peterm6881>
100 mA on a 2600 mAh power bank, 26 hours
<peterm6881>
be interesting to see what it draws with a speedsaver image
<peterm6881>
night
peterm6881 has quit [Remote host closed the connection]