Sensu_Be1 has quit [Remote host closed the connection]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
<wens>
apritzel: is the emmc usable on the other a523 boards?
gsz has joined #linux-sunxi
Lightsword has joined #linux-sunxi
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
<diego71>
I've tried ttyS0, but didn't work so I put earlycon. I think console= never worked: "Warning: unable to open an initial console."
<diego71>
I have to fix the regulator thing first, and hope that fix most of the errors...
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Sensu_Be1 has joined #linux-sunxi
Sensu_Bean has quit [Read error: No route to host]
Sensu_Be1 has quit [Read error: Connection reset by peer]
Sensu_Bean 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
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
gsz has joined #linux-sunxi
<apritzel>
wens: it didn't work for me on the Avaota as well. I played a bit around with speed modes and frequencies, and it got a bit better, but was never really stable
<apritzel>
for instance I could read at least the partition table with DDR @ 40 MHz or so, but then it hangs up when using it for real
<apritzel>
and U-Boot was similar: it sometimes detected it and could read the partition table, but then timed out when trying to read an actual file
colinsane has quit [Remote host closed the connection]
radxanaoki has quit [Quit: radxanaoki]
bauen1 has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
iscle has joined #linux-sunxi
Sensu_Be1 has joined #linux-sunxi
Sensu_Bean has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
warpme has quit []
szemzoa_ has joined #linux-sunxi
szemzoa has quit [Read error: Connection reset by peer]
aggi_ has joined #linux-sunxi
szemzoa has joined #linux-sunxi
szemzoa_ has quit [Read error: Connection reset by peer]
aggi has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Sensu_Bean has joined #linux-sunxi
Sensu_Be1 has quit [Read error: Connection reset by peer]
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
warpme has quit []
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
dsimic is now known as Guest23602
dsimic has joined #linux-sunxi
Guest23602 has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
cp- has joined #linux-sunxi
colinsane has joined #linux-sunxi
colinsane has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
gsz has joined #linux-sunxi
ftg has joined #linux-sunxi
warpme has quit []
Sensu_Be1 has joined #linux-sunxi
hentai has quit [Quit: SIGTERM]
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
Sensu_Bean has quit [Ping timeout: 480 seconds]
bauen1_ has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
apritzel has quit [Ping timeout: 480 seconds]
deprecated-funderscore has quit [Remote host closed the connection]
Schimsalabim has quit [Read error: Connection reset by peer]
<lschmid>
0x02500c00 is completely empty and a write to the output register also does not trigger a character on the serial
<lschmid>
so I just had a very interresting discovery. the bx r6 crashing is due to gdb. if I put the uart snippet before and after the routine call it prints fine. further I can see with "si" that it actually exits secure mode and does begin to launch the linux kernel (or the simple_guest binary too). But it seems that, once we leave secure mode, we loose access to the uart's (or at least uart3). Pinctrl is fine and UART3 is still configured on PB, but
<lschmid>
so u-boot does actually launch the kernel or whatever, but the application can't talk to the outside world anymore or even gets stuck due to waiting for some register of UART3 (as in the simple_guest example)
apritzel has joined #linux-sunxi
<lschmid>
So it's probably just a matter of configuring the SPC to allow access outside secure mode. But how does one do that?
<lschmid>
apritzel: would you maybe happen to know how and where I have to write to do the "unlock everything" on the SPC?
<apritzel>
lschmid: well, I just checked, and I don't see much mentioned about the SPC in the T113 manual
<lschmid>
Yeah there is a "It's there and thats it's address range"...
<apritzel>
and I think anyway the SPC tends to be "NS allowed" by default
<lschmid>
Well, I can tell you that even gdb can't r/w when in ns mode on the uart3. Also your simple_guest hangs at some check waiting for the uart so set 0x20 at offset 0x14 from base
<apritzel>
interesting!
<apritzel>
lschmid: so the SPC is not complicated, check arch/arm/cpu/armv7/sunxi/tzpc.c and struct sunxi_tzpc. So question is just where it's located in the memory map
<lschmid>
Well where the spc is, is mentioned in the manual
<apritzel>
in other SoCs it's behind the SMC (secure memory controller), but the D1/T113 have the HSTIMER there
<lschmid>
That would be 0x02000800 then
<apritzel>
ah, right, just found it
<apritzel>
so give it a try: maybe jump somehow dump the first dozen registers, while still in secure
<lschmid>
As in just gdb u-boot and dump them?
<apritzel>
for instance, whatever works best
<apritzel>
the A64 manual describes the SPC, chances are it's still the same
<diego71>
juanesf91: i'll try it. Thanks
<apritzel>
diego71: do you have CONFIG_I2C_MV64XXX, for I2C? Also, have you considered just using "make defconfig"?
<apritzel>
lschmid: actually the SPC is an interesting point: we do set it up, in TF-A for all the recent SoCs, but I think the T113-s3 is the only(?) recent SoC which is 32-bit only, so doesn't use TF-A
<apritzel>
lschmid: so I guess try writing 0xff to +0x8, +0x14, +0x20, +0x2c, +0x38 ...
<apritzel>
and eventually try to enable the code in tzpc.c for the T113
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
<lschmid>
should i be able to see the write i did?
<diego71>
apritzel: I'm trying to have the relevant modules inside the kernel instead as modules, in case there is something wrong with the initrd
<apritzel>
diego71: sure, but defconfig should have that for the essentials as well
<apritzel>
and you should *always* use a sane config (either defconfig or a distro one) as a base
<apritzel>
so get this booted, then move the stuff you need into the Image, and remove everything you don't need
<apritzel>
it's not the 90s anymore, making a .config from scratch is no longer feasible
<apritzel>
diego71: ah, no, those registers are marked as WO in the A64 manual
<apritzel>
I meant lschmid ^^^^
<apritzel>
lschmid: the status is at +0x4, +0x10, +0x1c and so on, where 0 means non-secure, 1 means secure only, one bit per peripheral (whatever they are, we don't know for the T113)
<apritzel>
so if you read +0x4 and it has many ones (only the lower 8 bits seem used), then you write 0xff to +0x8, then read +0x4 again, it should read as 0
<lschmid>
I see. So the writes did not enable the uart, and also dumping the memory of the spc shows most a 0, but every nF0 has 00010001 set
<lschmid>
e.g. 020008f0 is 0x00010001
<lschmid>
as is 9f0, af0, bf0
<lschmid>
But i've also discovered that the weird 0xc08... address actually has data. And it looks to be somewhat valid arm code
Schimsalabim has quit [Ping timeout: 480 seconds]
<lschmid>
And the data in this range actually mentions itself as addresses
Schimsalabim has joined #linux-sunxi
<apritzel>
diego71: I just compiled a pure defconfig kernel, and it booted to an initramfs prompt just fine, so with the AXP and console
<apritzel>
(without any modules, just the Image.gz)
<apritzel>
lschmid: are you sure that's the right MMIO address? 0x10001 looks like a clock BGR register (reset + clock gate)
<lschmid>
0x02000800 where 0x020008f0 is this value... I don't know what else to tell you
<apritzel>
I see, but 0xf0 sound rather late
<lschmid>
Is c08 and so on stuff mapped by the linux kernel? It's got strings like "Linux version 6.15.5-dirty" or "ARMv7 Processor"
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<lschmid>
by c08 i mean 0xC08.....
<apritzel>
there is nothing in the memory map at this area, but it might be an alias on the DRAM side (so lower memory appearing again, due to the address decoding "wrapping around")
<apritzel>
and on my "non-secure boot" board all the first words are not writeable, though 0x8e0 is
<lschmid>
whats the worst that could happen if i do a memory fill of the whole spc??
<apritzel>
it's extremely unlikely to damage anything, if that's what you concerned about
<apritzel>
there are parts of the eMMC that are one way, and you should be careful with the PMIC programming, but the rest is open to experiments ;-)
<apritzel>
for instance the content of 0x8e0 seems to be mirrored to 0x9e0, 0xae0, ...
<lschmid>
Okay then. The SPC seems to wrap arround at 0x100, and only e0 is writeable here too
<apritzel>
yes indeed, and 0x8f0 (the 10001) seems read-only
<lschmid>
jup, the fill only wrote to 8e0 32-bit
<lschmid>
would it be possible for you to add a gpio blink or something into the start of your looks-like-a-kernel to check if it actually runs or just gdb/jtag playing up again?
<lschmid>
i know that pinctrl was readable, at least from gdb
<apritzel>
lschmid: which GPIO do you want? Anything with an LED on it?
<lschmid>
dont have an led connected yet, but thats no issue. How does PD22 sound?
<apritzel>
perfect, that's where an LED is on the Mangopi
Sensu_Bean has quit [Read error: Connection reset by peer]
Sensu_Be1 has quit [Read error: Connection reset by peer]
Sensu_Bean has joined #linux-sunxi
<lschmid>
So if I disable the console/uart in linux, will it boot and let me ssh? Or is that very far fetched?
evgeny_boger has quit [Quit: evgeny_boger]
evgeny_boger has joined #linux-sunxi
<apritzel>
the UART is very likely just the first of those limited peripherals that you hit
<apritzel>
(and yeah, it's three times, I just copied the writel a bunch of times ;-)
<lschmid>
Oh yeah, I had actually seen this... But it didn't make sense back then. I tried booting the efi shell and it also did nothing. Then I connected the debugger/gdb later while it was "hanging" and saw it looping in a uart EAGAIN loop. That makes total sense now
<lschmid>
So now we only need to find a way to tell the SoC that I do want my UART3 (and possibly other stuff)
Sensu_Be1 has joined #linux-sunxi
<apritzel>
trying to find some BSP U-Boot source now ...
<lschmid>
I actually do have the Allwinner BSP U-Boot source here (got it from the MYiR T113 SDK) but it only refers to the SPC like the 0x8, 0x14 registers we talked about before
<lschmid>
Oh and those aren't in u-boot but "spl-pub"
Sensu_Bean has quit [Ping timeout: 480 seconds]
<apritzel>
right, it might be in boot0, I just skimmed through some U-Boot (proper) sources
<lschmid>
is boot0 spl-pub?
<apritzel>
your guess is as good as mine, I gave up on trying to make sense of AW's naming ;-)
<lschmid>
It's probably spl-pub then, at least one of the main.c has "printf("HELLO! BOOT0 is starting!\n");"
<apritzel>
yeah, very likely
<apritzel>
spc.c (which follows the A64 MMIO layout) is not compiled, but smc.c is
<apritzel>
which is the "secure memory controller"
<apritzel>
on the A64 it looked like an Arm TZC-380, but this one is different, I think
<lschmid>
Well it does look a bit more populated looking at it with md. But it's also got the weird 00010001 at f0 again. Maybe just a thing this soc does?
<lschmid>
Where did you find that smc.c? My BSP doesn't have it...