ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
<smaeul> wens: ClockworkPi has `vcc-pg-supply = <&reg_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]
Schimsalabim has joined #linux-sunxi
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
mripard has joined #linux-sunxi
gsz has joined #linux-sunxi
warpme has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
colinsane has quit []
colinsane has joined #linux-sunxi
Daaanct12 has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
colinsane has quit []
colinsane has joined #linux-sunxi
hentai has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest3969
dsimic has joined #linux-sunxi
Guest3969 has quit [Ping timeout: 480 seconds]
<wens> smaeul: ah, I see
<wens> doesn't seem like the regulator bits got merged either
bauen1 has joined #linux-sunxi
chewitt has joined #linux-sunxi
Daaanct12 has quit [Remote host closed the connection]
gsz has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
Daanct12 has quit []
Daanct12 has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
Daanct12 has quit []
nickA has quit []
warpme has quit []
warpme has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
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.
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.0 Quasar http://www.kvirc.net/]
<alikates> apritzel pointed me to https://github.com/CrealityTech/sonic_pad_os/blob/main/lichee/brandy-2.0/spl/include/configs/sun50iw12p1.h, where looks like it has a similar SRAM layout as R329
<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> okay
<alikates> ty!
<apritzel> maybe .thunk_addr = 0x11fc00, .thunk_size = 0x200,
<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
<alikates> Here's a dump of boot0 output, just in case you can make anything useful out of it https://share.riseup.net/#nm05K5t6CpwKwYHiJbmlNA
<alikates> in fact, from that dump 792MHz
<alikates> and also, it's definitely emmc
<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
<alikates> (Assuming its similar to other SoCs)