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
sunshavi_ has quit [Remote host closed the connection]
<anarsoul> MoeIcenowy: ^^
sunshavi_ has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
dikiy has quit [Ping timeout: 480 seconds]
jelly has quit [Ping timeout: 480 seconds]
jelly has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest1182
Guest1182 has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-sunxi
grming has quit [Quit: Konversation terminated!]
Daanct12 has joined #linux-sunxi
Daanct12 has quit [Remote host closed the connection]
<MoeIcenowy> apritzel: I am not sure, but what I heard is A100 is different from A133
<wens> jernej: looks like gstreamer works as well
junari__ has joined #linux-sunxi
junari__ has left #linux-sunxi [#linux-sunxi]
junari__ has joined #linux-sunxi
junari__ has quit [Remote host closed the connection]
junari has joined #linux-sunxi
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
junari_ is now known as junari
<junari> So, I added to the beginning of board_init_f function (https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/board.c#L439 ) the reset_cpu() function. As a result, the device with the H616 processor is rebooted, and the device with the T507 is not. Same with sd card.
<junari> Is there anything else before board_init_f() that could affect the load?
<junari> As I understand it, previously there was only a general code for the arm64 platform
JohnDoe_71Rus has joined #linux-sunxi
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
junari__ has joined #linux-sunxi
junari_ has quit [Read error: No route to host]
junari_ has joined #linux-sunxi
junari_ is now known as junari
junari__ has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
evgeny_boger1 has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
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