evgeny_boger1 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
macromorgan has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
dikiy has joined #linux-sunxi
<wens>
jernej: compared to hantro, running fluster gstreamer test on cedrus additionally fails vp80-00-comprehensive-006 and vp80-00-comprehensive-014. these two are the odd dimension test vectors
evgeny_boger has joined #linux-sunxi
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
junari__ has joined #linux-sunxi
apritzel has joined #linux-sunxi
junari_ has quit [Ping timeout: 480 seconds]
<apritzel>
junari__: are you sure your code gets actually loaded?
<apritzel>
junari__: at least the FEL problems you reported the other day suggested otherwise
junari_ has joined #linux-sunxi
<apritzel>
junari__: if you want to debug early code, I'd recommend you use "sunxi-fel spl uart0-helloworld-sdboot.sunxi", before you do the actual load: that sets up the UART.
junari_ is now known as junari
<junari>
apritzel: It is hard to say. The problem with 21KB also appears on the H616, but the SPL boot works fine on it
<apritzel>
Then you can just do "writel('1', 0x05000000);" or the assembly equivalence
junari__ has quit [Ping timeout: 480 seconds]
<apritzel>
junari: yeah, sorry, I still owe you that test with the 21K payload
<junari>
I tried putting it at the beginning of the function board_init_f(), but it didn't work
<junari>
On t507 and H616 too
<junari>
apritzel: sorry, works on H616, don't work on t507
<junari>
apritzel: When I start uploading via FEL I get the output on t507: Stack pointers: sp_irq=0x00021400, sp=0x00053FD4 / MMU is not enabled by BROM / => Executing the SPL... done. /usb_bulk_send() ERROR -9: Pipe error
<junari>
Now I found, that sp register is different with H616 (sp=0x00053FE4). Could it matter?
<apritzel>
junari: not really if it's just 16 bytes
<apritzel>
junari: my gut feeling is sunxi-fel does something wrong already with the H616, and we *mostly* get away with it. Apparently the T507 is a bit more picky here.
<apritzel>
junari: can you please dump the BROM and put that somewhere? "sunxi-fel read 0 65536 t507_brom.bin"
<junari>
Yes, of course
<MoeIcenowy>
apritzel: is it possible that the T507 device is secure booted?
<apritzel>
MoeIcenowy: I doubt it, and we would see a message from sunxi-fel about doing the smc
<MoeIcenowy>
apritzel: do we have secure detection for H616?
<apritzel>
ah, good point ...
<apritzel>
(as we don't have the secure SRAM A2 to check)
<apritzel>
MoeIcenowy: thanks for the answer on the A100, btw. I will then not pretend they are identical, but just closely related
junari_ has joined #linux-sunxi
junari has quit [Read error: Connection reset by peer]
<apritzel>
but bummer: seems to be identical to the H616 NBROM
<apritzel>
junari: can you check whether "sunxi-fel -v sid" works?
<junari>
apritzel: SID key (e-fuses) at 0x03006200
<junari>
33007c00:7c004808:01464701:64841f0e
<apritzel>
that seems fine, I don't think this would work when the device is secure fused
<junari>
It should have been easy to bring up the T507 with well known H616...
<junari>
But it turned out not to be as easy as I expected.
<apritzel>
junari: yeah, that's interesting. You could compare the two manuals, especially around the clocks (mostly the PLLs and bus blocks), and the system config
<junari>
I'll try to do it again. But it looks like copypaste
evgeny_boger1 has joined #linux-sunxi
warpme____ has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
<apritzel>
libv: mnemoc: any chance you can revive the Wiki (that's dead for days now)? Or just switch over to the new version?
<junari>
apritzel: yeah, success
<junari>
Over RVBARADDR register
bauen1 has quit [Ping timeout: 480 seconds]
<junari>
apritzel: thank you for your help
junari_ has joined #linux-sunxi
freemangordon has quit [Ping timeout: 480 seconds]
junari has quit [Read error: No route to host]
junari__ has joined #linux-sunxi
freemangordon has joined #linux-sunxi
junari_ has quit [Ping timeout: 480 seconds]
freemangordon has quit [Ping timeout: 480 seconds]
freemangordon has joined #linux-sunxi
<apritzel>
junari__: good find, though I think we don't use those registers in U-Boot
dikiy has quit [Read error: Connection reset by peer]
freemangordon1 has joined #linux-sunxi
freemangordon has quit [Read error: Connection reset by peer]
<apritzel>
junari: oh, I see, the base address is different now! I checked that RVBAR was still at +0x40, but didn't check the base ...
<apritzel>
but sunxi-fel identifies the SoC as H616, right?
freemangordon has joined #linux-sunxi
freemangordon1 has quit [Read error: Connection reset by peer]
junari_ has joined #linux-sunxi
<apritzel>
junari: did you find any BSP code for the T507 out there? Something were we can find something to differentiate between the two? Like we do for the H2+ and H3, for instance
<apritzel>
I would guess we can compare SID keys (we have yours already), but it would be good to have something definitive
JohnDoe_71Rus has quit []
junari has quit [Read error: No route to host]
grming has joined #linux-sunxi
junari__ has joined #linux-sunxi
junari__ is now known as junari
evgeny_boger1 has quit [Ping timeout: 480 seconds]
<junari>
apritzel: yes, sunxi-fel think that it H616
junari__ has joined #linux-sunxi
junari is now known as Guest1236
junari__ is now known as junari
<junari>
sorry, don't understand what you mean about BSP
<MoeIcenowy>
apritzel: my two sentences are not related at all
<apritzel>
MoeIcenowy: I got that ;-)
<apritzel>
I wanted to add something to the A133 page, so for me it's related ;-)
<MoeIcenowy>
A100 is now discontinued because all new dies meet the criteria for A133
<MoeIcenowy>
well this reminded me of F133-A and F133-B
<apritzel>
MoeIcenowy: I see, that makes sense
<MoeIcenowy>
the former has broken TVIN
evgeny_boger has joined #linux-sunxi
bauen1 has joined #linux-sunxi
freemangordon1 has joined #linux-sunxi
freemangordon has quit [Remote host closed the connection]
freemangordon has joined #linux-sunxi
freemangordon has quit []
freemangordon has joined #linux-sunxi
freemangordon1 has quit [Ping timeout: 480 seconds]
freemangordon has quit []
evgeny_boger has quit [Ping timeout: 480 seconds]
dikiy has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<mnemoc>
apritzel: maxima is still the official wiki, I'll try to get that old *censored* up again. both disks are dying
<apritzel>
mnemoc: many thanks, much appreciated!
<mnemoc>
pretty upsetting considering Hetzner is charging 70EUR/month for that piece of junk
<mnemoc>
hopefully this will be maxima's last month
<mnemoc>
up
<apritzel>
mnemoc: many thanks, it's indeed working again!
<mnemoc>
be gentle please :)
<apritzel>
I will try to only change one character at a time ;-)
<mnemoc>
:D
junari has quit [Ping timeout: 480 seconds]
<smaeul>
apritzel: at some point the SID started allowing the first 0x40 bytes to be read even in NS mode. I don't remember exactly what SoC that started with.
<MoeIcenowy>
smaeul: oops
<smaeul>
this is so you could still read the SID -- all the key material was moved to the secure-only half
dikiy has joined #linux-sunxi
freemangordon has joined #linux-sunxi
<MoeIcenowy>
smaeul: then on H616 where could we use to identify whether we're secure or non-secure?
dliviu has quit [Ping timeout: 480 seconds]
dikiy has quit [Ping timeout: 480 seconds]
<apritzel>
we could just try the second half then, given that this is something non-zero in there
ftg has joined #linux-sunxi
<jernej>
junari: do you have issues with DRAM initialization?
dikiy has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<jernej>
wens: I just tested samples you mentioned with ffmpeg. Each frame md5 matches with reference md5 hash for both samples. I'm certain that Cedrus was used because debug log printed usual messages when using request api.