<smaeul>
wens: ClockworkPi has `vcc-pg-supply = <®_ldoa>;` which depends on the internal regulator driver that was not merged, which is why I dropped that board DT
ftg has quit [Read error: Connection reset by peer]
timsu has joined #linux-sunxi
timsu has quit []
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
apritzel___ has quit [Ping timeout: 480 seconds]
gamiee_ has quit [Remote host closed the connection]
gamiee_ has joined #linux-sunxi
f__ has joined #linux-sunxi
f_ has quit [Ping timeout: 480 seconds]
nickA has joined #linux-sunxi
<Jookia>
woo, sent off one small new patch for sunxi
gsz has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus 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
f__ has quit [Remote host closed the connection]
f_ has joined #linux-sunxi
warpme has joined #linux-sunxi
apritzel___ has quit [Ping timeout: 480 seconds]
warpme has quit []
ity 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]
JohnDoe_71Rus has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
JasperStigho has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
gsz has quit [Ping timeout: 480 seconds]
JasperStigho has quit []
utsweetyfish has quit [Read error: Connection reset by peer]
vagrantc has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
apritzel has quit []
vpeter has quit [Remote host closed the connection]
chewitt has quit [Quit: Zzz..]
bauen1 has joined #linux-sunxi
flyback has quit [Ping timeout: 480 seconds]
flyback has joined #linux-sunxi
<alikates>
Hi, I'm back at tinkering with the TV303/H713 projector I got a while ago. Right now I'm trying to add support for it in the sunxi-fel tool, but I'm struggling with the SRAM regions and the loading of SPL to a specific address.
<alikates>
My main question right now is: do I have to figure out by hand which parts of the SRAM are critical (like interrupt routines) by writing to different addresses, or is there any intuition to it?
<alikates>
I guess the main concern is not to touch the irq stacks and some critical code. But right now I've failed to identify those regions, when I try to boot a basic SPL or the uart0 helloworld, everything hangs when jumping to the thunk code
<alikates>
If it helps I can provide a dump of the SRAM, as I've managed to make the instruction scratch space to work
apritzel has joined #linux-sunxi
<apritzel>
alikates: if you can write and read from SRAM, you can do some experiments with that
<apritzel>
for instance IIRC the IRQ stack area changes a few bytes every time
<apritzel>
so read the same region (or the whole SRAM) twice and compare
<apritzel>
then you can starting writing to SRAM and read that back
<apritzel>
if it hangs (quite likely), try a different region
<apritzel>
it's some kind of puzzle work, but after some time you should get an idea of what is where, and how large the SRAM is in general
ity has quit [Remote host closed the connection]
<alikates>
from my initial testings, the sram goes from 0x104000 to 0x124000, well like on the .h file
<alikates>
however i've noticed SRAM A2 base is 0x100000, and i've read that sometimes A2 bank is only accessible from a secure exec mode
ity has joined #linux-sunxi
<alikates>
i've tried writing a 4k block of ones to it but only the first 4 bytes of each multiple of 0x100 get written
<alikates>
That makes me wonder if its just a reset vector space or something
<apritzel>
alikates: secure> theoretically, yes. But first you are most likely in secure state at this stage, and secondly this is not enforced unless the secure boot fuse is burnt
<apritzel>
so ignore any secure restrictions for now
<alikates>
okay
<apritzel>
first 4 bytes in each 256> that's the OpenRISC exception vector area
<alikates>
Aaaah okay
<apritzel>
you are supposed to write a branch instruction in that word
<alikates>
btw, there's also some bits set with offset like 0x8 of each 256
<apritzel>
the next word in a delay slot NOP
<alikates>
0x0000015?
<apritzel>
yup
<alikates>
that's what i see
<alikates>
okay then
<apritzel>
same thing on H3, A64, H6 and friends
<alikates>
okay, so I should set the SPL base to 0x104000 then?
<alikates>
I don't know where the brom will look for the eGON header
<alikates>
hmmm
<apritzel>
the BROM will not *look* into SRAM, it would *load* something in there
<alikates>
okay, I thought it checked the header or something
<apritzel>
the BROM header is checked by sunxi-fel, some kind of molly guard to prevent uploading random stuff
<alikates>
okay
<apritzel>
the *eGON header
<alikates>
that's where i get stuck
<alikates>
sometimes it hangs, but some other it tries to read the header and reads empty
<apritzel>
have you copied the R329 entry in soc_info.c
<apritzel>
?
<alikates>
i started from it, but modified it a lot to make it work so now its totally different
<apritzel>
or is that exception vector area right at 0x100000?
<alikates>
yep
<alikates>
looks like the usable sram starts at 104000
<alikates>
which would make sense, as i can only read up to 124000 without making it crash.
<apritzel>
right, that's good info!
<alikates>
so 128kB of SRAM
<alikates>
i assume
<alikates>
i can also read the stack pointers,
<alikates>
one is at 0x105400 and the other one at 0x12300(IIRC, i dont have my notes at hand)
<apritzel>
that sounds reasonable
<alikates>
*0x12f300
<apritzel>
can you just not read at 0x124000, but again further down?
<alikates>
further than 0x124000 it hangs
<alikates>
at least near that address
<apritzel>
and how do you read? with the normal "sunxi-fel read" command? That should work nevertheless, as it uses only the FEL primitives, and does not require any code upload or execution
<apritzel>
(readl is different)
<alikates>
now im in doubt if i even tried to read with that
<alikates>
i might' have only used hexdump at that address
<alikates>
let me try
<apritzel>
hexdump should be the same as read, it just uses a different output scheme
<alikates>
okay
<alikates>
i tried anyways
<alikates>
it doesn't work
<apritzel>
hanging while reading is an interesting data point, often we read only zeros, but any writes don't stick (read-as-zero/write-ignore)
<apritzel>
but you said some stacks are at 0x12f300? So beyond that?
<alikates>
nope sorry
<alikates>
it was 12x300
<alikates>
but definitely before 0x124000
<alikates>
btw, something interesting about this board is that there's an unpopulated sdcard slot. I wonder if I solder one and put a card in there if it will boot from it
<apritzel>
so start with: .spl_addr = 0x104000, .scratch_addr = 0x105000,
<apritzel>
most likely yes
<alikates>
and what about the swap buffers?
<alikates>
what I understand is that they are only useful for devices with smaller srams right?
<apritzel>
try: { .buf1 = 0x105000, .buf2 = 0x120000, .size = 0x0400 } for now
<apritzel>
well, one stack is typically in the way nevertheless, so we need to move that
<apritzel>
that's only different on the (newest) A523
<alikates>
also, i tried to run the meminfo command from the android recovery, but i found out the kernel hasn't been compiled with DEVMEM -_-
<apritzel>
so we store everything near 0x120000, where it's safe
<apritzel>
meminfo wouldn't work on these newer SoCs anyway
<alikates>
ah well, okay
<alikates>
I'll try with those values and tell you if i get something
<apritzel>
does that device has eMMC or raw NAND?
<alikates>
I'm not sure, i think its only NAND
<apritzel>
you can run a statically linked sunxi-fw on the boot block device from Android, like "sunxi-fw info -v /dev/block/mmcblk1", to dump the DRAM parameters (if you have root there)
<apritzel>
and what's the SoC ID, btw? 0x1860?
<alikates>
okayy. yeah I have root. when I got uart i saw a user shell with autologin, and when rebooting to recovery the shell was for root
<alikates>
yep 1860
<apritzel>
on a user shell, just cheekily try "su", that works on some recent TV boxes ;-)
<alikates>
xDDD
<apritzel>
"cat /proc/partitions" should give you a list of block devices, and tell you whether it's eMMC (good) or raw NAND (bad)
<apritzel>
afk for a bit, but keep trying (and typing) ...
<alikates>
okay, btw looks like those addresses don't work
<alikates>
from /proc/partitions, looks like its emmc... are mmcblk devices always emmc in linux?
<gnarface>
no, it could be a microsd card slot too
<gnarface>
(does that mean in theory it could also be a regular SD card slot? i don't know)
gsz has joined #linux-sunxi
<apritzel>
mmcblk could be both. There are hints in dmesg about what it is.
Schimsalabim has quit [Read error: Connection reset by peer]
<apritzel>
an easy sign is the existence of two boot partitions, that's eMMC then
Schimsalabim has joined #linux-sunxi
<apritzel>
but of course if there is no SD card, and you see mmcblk, then it means it's eMMC
ftg has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
<apritzel>
alikates: when you say "it doesn't work": what did you try? You mentioned uart0_helloworld, did you port this to the SoC?
colinsane has quit []
colinsane has joined #linux-sunxi
<alikates>
I tried loading the uart helloworld as spl. I didn't check the inner workings, but I assumed it used some kind of standard way of outputting to the uart
<apritzel>
alikates: somewhat, but only standard *per SoC*, so the code needs to know the UART base address, clock gates, reset and pinmux for each SoC's UART0
<alikates>
okay, i just read it
<alikates>
hmm i got the dump with sunxi-fw
<apritzel>
if outright bails out if it sees an unknown socid
<apritzel>
ah great, that will become handy later on, for the DRAM parameters, though this might be premature if the DRAM controller is different from the others - and quite high chance it is :-(
<alikates>
do the a64 and h616 columns mean something or is something hardcoded in the tool?
<apritzel>
it's two different way of interpreting the parameters, an old and new way, if you like
<apritzel>
for an H616 derivate, you could put some of those values in the U-Boot defconfig
<apritzel>
it's apparently DDR3 at 786 MHz
<alikates>
ah yes its ddr3, i can also look for the dram IC datasheets
<apritzel>
interesting, it might actually be more an old style DRAM controller (which is odd)
<apritzel>
and yeah, those dumps are somewhat useful, though them alone, without BSP code or a "user manual" of the SoC, don't give too much info
<apritzel>
remind me, did we have some SoC manual for that TV303/H713?
JakobL has joined #linux-sunxi
<alikates>
yeah from what i understand, the dram chip used is a really cheap, and also only 1GB
<apritzel>
the chip is one thing, but not too important. The DRAM controller (inside the SoC) is the big unknown. Typically some wizards disassemble and rev-eng some boot0 code, but that takes effort and time
<alikates>
I also asked you for manuals the first time haha. I've been looking for them from time to time since then and haven't found anything yet. Not even a detailed spec or one of those marketing sheets
<apritzel>
yeah, I was afraid of that ;-)
<alikates>
The kernel doesn't care about the DRAM controller right? It's only on boot
<apritzel>
the kernel doesn't know or care, but it of course needs it to be initialised. I mean it's no fun without DRAM
<alikates>
I could try doing some reversing of boot0, maybe that way we can figure out which controller it is
<apritzel>
one trick I sometimes use is to talk boot0 into initalising the DRAM, then return to FEL
<apritzel>
you said there is no SD card, right?
<alikates>
theres an unpopulated footprint
<alikates>
i'm tempted to get a sd to microsd adapter and solder directly to the pins
<alikates>
and also what looks like a footprint for an SPI flash
<apritzel>
yeah, I had some luck with this in the past
<apritzel>
and have a full drawer of those adapters anyway ...
<alikates>
what's strange is that both footprints are overlapping xD
<apritzel>
what sometimes works is to put just boot0 on an otherwise "empty" SD card: if it doesn't find any further payload, it might go to FEL
<apritzel>
and then you can upload U-Boot proper and a kernel via FEL
<alikates>
interesting
<alikates>
i noticed something else
<apritzel>
I see some hits for "sun50iw12p1" in github code search, might be worth going through them and see what can be found there
<alikates>
> [01.192]usb burn from boot
<alikates>
but maybe thats some functionality for flashing at the factory or smth
<apritzel>
there is A LOT of nonsense output in boot0 ;-)
<apritzel>
sometimes pointless debug leftovers, sometimes code from other SoCs or boards, definitely quite some exclamation marks!!!!
<apritzel>
don't read too much into that
vagrantc has quit [Ping timeout: 480 seconds]
<alikates>
okay
<apritzel>
there is a .dts, I guess at least the base address in there are useful - though we have seen a lot of plain wrong DTs in BSP code
<alikates>
it's a dump from the vendor partition but i could also dump the one effectively read by android
<alikates>
sorry not vendor partition, a partition called vendor_boot
<alikates>
the one that in fact holds the android kernel-ramdisk-dts bundle
<alikates>
there's a boot_a/b partition but I think that holds u-boot
<apritzel>
the data in there would help you to figure out the values for uart0_helloworld at least
<alikates>
yeah i've already seen the uart base
<alikates>
pio and GIC base too
<alikates>
I guess the u-boot versions in github that have sun50i12w definitions won't help much with the DRAM situation, right? as it's being chainloaded from boot0/1
<apritzel>
chances are the clock bits are the same as in the H6/H616, it seems to be the same "NCAT" generation
<apritzel>
yes, in contrast to mainline, the DRAM init is done by boot0, which is a completely separate code base - and proprietary
<apritzel>
even if you find some boot0 source, it mostly links in some (binary) libdram library
<apritzel>
if you happen to find such a file, make sure to save it, more often than not it contains debug symbols that significantly help reverse engineering
<apritzel>
alikates: do you know the UART pins? and the pinmux used?
<alikates>
i can see them in the DTS, yes
<alikates>
PH0/1
<alikates>
pinmux at 0x2000000
<alikates>
What about licensing issues when reversing? Some people are quite strict with that and OSS development...
<alikates>
Personally i dont care about it, they are benefiting from OSS without contributing back anyways
<apritzel>
exactly
<apritzel>
I am pretty sure they still violate the GPL in many places
<alikates>
The uboot on my device for example
<apritzel>
and to be clear: we don't disassemble and copy the code: it's mostly a complete rewrite, just using the information from that dump
<alikates>
Yeah
ftg has quit [Read error: Connection reset by peer]
<alikates>
Do you know if its common for jtag to be exposed on the boards? Though i guess thats up to the manufacturer
<alikates>
And ive seen its behind the pinmux so up to the boot0 to set it up ig