Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
<alikates>
nvm, looks like it was just corruption
<apritzel>
jtag is typically pinmuxed on the SD card pins, but I haven't used that
<alikates>
with sunxi-fel, now im getting "Unexpected SCTLR (E121F001)"
<alikates>
And that looks like one of the instructions that get written to the scratch space for reading the stack pointers
<alikates>
I don't know why that would happend
<alikates>
Sometimes it works and gets past that to loading the thunk
JakobL has quit [Remote host closed the connection]
<alikates>
setting icache_fix allows it to proceed, maybe the cache isn't invalidated at boot and there's leftover data between power cycles...?
flyback has quit []
flyback has joined #linux-sunxi
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
<apritzel>
before you are going to execute code you just wrote, you need to clean the D cache and invalidate the I cache, since ARMv8.0 doesn't require coherency between the two
<apritzel>
so if the BROM enables the I cache, you need that flag, where we disable the I$ before writing
<alikates>
Okay
<alikates>
With that i'm getting a lot more consistent results
<alikates>
now every time i get to "Executing the SPL"
<alikates>
though after that it hangs FEL
<apritzel>
how familiar are you with ARM(32) assembly?
<alikates>
a bit, but i'm a bit rusty with some of the not-so-risc instructions (ie load/store multple and the coprocessor stuff) hehe
<apritzel>
you can write small code snippets, that read some registers and write that somewhere in SRAM, then execute that
<apritzel>
or just write some constants somewhere
<apritzel>
you actually don't need the spl command for that, so can upload ("write") a pure binary, and "execute" that
<apritzel>
if you don't mess with SP and LR, just execute a "ret" at the end, and you are back in FEL
<apritzel>
and then can read the SRAM and check the results
<apritzel>
to verify that your problem is not in the payload (uart0_helloworld)
<apritzel>
just assemble with "gcc -c", then convert with "objdump -O binary" from the .o file to .bin
<apritzel>
if you run "mkimage -T sunxi_egon" or "mksunxiboot" on that, you should be able to try the "spl" command that way as well
<alikates>
Hmm, okay
<alikates>
What I understand now is that the thunk gets executed, but the SPL never returns
<apritzel>
that would happen if *anything* goes wrong in the code
<alikates>
Well, i'm assuming the thunk works haha
<apritzel>
I mean in the payload code
<apritzel>
which is not so easy to debug, hence the idea to start with something very small and easy
<alikates>
So I will do as you say and try writing some rets to follow the program execution
<apritzel>
is there an LED on the device? it would be quite easy to trigger that
<alikates>
it would be nice to have a working uart too, so I will try to port the helloworld too
<alikates>
Yes!
<apritzel>
is there any hint about the GPIO used in the vendor DT?
<alikates>
Was looking into it
<alikates>
It says led_blue = "PL1"
<apritzel>
right, so you read from 0x7022000, mask off bits [7:4], write a "1" in that nibble (=GPIO output), then set bit 1 in 0x7022010 (data register)
<apritzel>
or clear that bit, depending on the polarity
<apritzel>
you can do this all in a very RISC-y way ;-)
<apritzel>
though maybe start with a simple "ret" ...
<alikates>
So PIO offset 0x0 is polarity and 0x10 is value?
<alikates>
I haven't touched any ARM code since my bachelor, now I mostly write RISC-V so thats why :PP
<apritzel>
yes, the first four words are the pinmux values for each of the up to 32 pins per port, 4 bits for each pin
<alikates>
Are there any docs on that?
<apritzel>
0 is GPIO input, 1 is GPIO output, 7 means HighZ (disabled), the rest depends on the pins
<apritzel>
yes, look up any of the H616 or H6 user manual
<machinehum>
aperezdc: were you looking for something like this? I can't remember which SoC you wanted a board for
<machinehum>
4K@60fps H.265 decoder ;o
<aperezdc>
machinehum: I think you pinged the wrong person ;-]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<machinehum>
@apritzel
<machinehum>
lol
<machinehum>
Sorry I a+tab'd
<machinehum>
Two quite close looking nics at a glance
<gamiee>
machinehum : yes, this is what we were looking for , A527 or T527. Although, this will be sold through Dongshan Pi
<machinehum>
gamiee: I'll have to get one as well
<machinehum>
It's a pretty slick part, I wonder what the power consumption is
<machinehum>
Pretty decent contender for the pinephone2 maybe?
<gamiee>
The problem is, I wanted to buy some Yuzuki boards in the past, Dongshan Pi on AliExpress couldn't ship to EU, and I think the same will happen also with now. (So maybe ChipBoard seller on Ali will be able to ship it into EU)
<gamiee>
machinehum : maybe, A527, or rather A523 might be suitable for new PinePhone (A523 does not have HDMI, so should be cheaper than A527)
<gamiee>
But yeah, power consumption, how mainline will go.... we will see
<gamiee>
but it is indeed very promising
<machinehum>
I'm interested in helping with some of the efforts
<gamiee>
That would be cool :) Well, I think, as always, first we need proper SBC for the chip, do initial stuff, power measurements etc... and then we will see :)
<gamiee>
but yeah, I am very keen for A527
<machinehum>
Oh shit it has pcie
<gamiee>
hm?
<machinehum>
single lane PCIe 2.1
<machinehum>
A523
<gamiee>
yeah
<machinehum>
I could maybe get some of those boards fab'd for everyone
<machinehum>
I have a sponcorship with NextPCB
<machinehum>
They make me things for free as long as I made a video about it
<machinehum>
sponsorship*
<gamiee>
machinehum: Pine Store will sell Yuzuki's board with A527 in following months, so we should be able to get the boards with the SoC
<machinehum>
That works to
KREYREN_oftc has joined #linux-sunxi
<gamiee>
I will let you all know on how the effort goes.
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
warpme has quit []
<machinehum>
Thanks!
ungeskriptet is now known as Guest4052
ungeskriptet has joined #linux-sunxi
Guest4052 has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
machinehum: thanks, and yeah, I am aware of this board, and Pine64's efforts of getting this out and available
<apritzel>
and yes, the chip has PCIe, though just a single line, but somewhat annoyingly it shares the PHYs with the only USB 3.0 port
<apritzel>
so you only get either USB 3.0 or PCIe
warpme has joined #linux-sunxi
<apritzel>
regarding mainline: it will take a while, but I don't see big obstacles, especially with some dev board available
<apritzel>
that would be the basics, so the headless server use case, cannot promise anything about graphics, as this is out of my comfort zone
<apritzel>
alikates: btw: can you check whether your device has a PMIC (Power Management IC)? Those are typically connected via R-I2C, which is on pins PL0 and PL1?
<apritzel>
alikates: if it has, it's unlikely that the LED is on PL1
<alikates>
I see what probably is a PMIC in the board
<alikates>
Surrounded by capacitors and coils
<Jookia>
nice!
<apritzel>
alikates: can you read the label? Does it contain AXP?
<apritzel>
alikates: or even better: could you create a Wiki page for that device at some point? That would help tremendously to collect all that information
<apritzel>
so do we know something definitive about the H313? Is it just the bad H616 chips from each wafer? They come in the same package, and are pin compatible, right?
<alikates>
Ofc, i was planning on doing so eventually
<alikates>
I dont remember it being an axp device
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
alikates: thanks!
<apritzel>
if it's not an AXP, then PL1 could indeed be the LED
<apritzel>
alikates: actually, you could even try to use sunxi-fel's readl/writel commands directly first, to poke the GPIO registers
obbardc has quit []
ungeskriptet is now known as Guest4059
ungeskriptet has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
Guest4059 has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest4060
dsimic has joined #linux-sunxi
Guest4060 has quit [Ping timeout: 480 seconds]
evadot has quit [Read error: Connection reset by peer]
evadot has joined #linux-sunxi
jelly has quit [Remote host closed the connection]
dliviu has quit [Remote host closed the connection]
pmp-p has quit [Remote host closed the connection]
dliviu has joined #linux-sunxi
machinehum2 has joined #linux-sunxi
machinehum has quit [Read error: Connection reset by peer]
pmp-p has joined #linux-sunxi
machinehum2 has quit [Ping timeout: 480 seconds]
f_ has quit [Ping timeout: 480 seconds]
f_ has joined #linux-sunxi
jelly has joined #linux-sunxi
bauen1 has joined #linux-sunxi
machinehum has joined #linux-sunxi
ity has quit [Remote host closed the connection]
ity has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
machinehum has quit [Read error: Connection reset by peer]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
machinehum 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
machinehum has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
warpme has quit []
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
bauen1_ has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
KREYREN_ has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
chewitt has quit [Quit: Zzz..]
apritzel has joined #linux-sunxi
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
machinehum has joined #linux-sunxi
wingrime-ww has quit [Quit: WeeChat 4.2.1]
wingrime-ww has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<apritzel>
oh wow, I just discovered that the H616 BROM apparently reads from SD card sector 512, not 256, as a second location after the traditional sector 16!
<apritzel>
macromorgan: which would explain why this didn't work for you on the RG35XX+
<apritzel>
tested on OPi Zero3, Transpeed (both H618) and X96 Mate (H616)
apritzel has quit [Ping timeout: 480 seconds]
machinehum has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
bauen1 has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
gsz has quit [Ping timeout: 480 seconds]
warpme has quit []
JohnDoe_71Rus has quit [Remote host closed the connection]
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
<alikates>
Hey, so I have written a something for driving the board LED. Still no luck anyways, but by placing the "bx lr" in different parts looks like what causes a hang is the final write to the IO data register
<alikates>
Btw, whats the difference between the normal and "r" pinmuxes?
<alikates>
I see theres one at 0x2000000 and another one at 0x7022000
<alikates>
and yes, im triggering both PL0 and PL1
<alikates>
One is the blue "poweron" led , the other one is the red standby led
warpme has quit []
<alikates>
but in the DTS i see some strange definitions, there are multiple PL gpios, more than the 2 documented in the h616 user manual. I see PL8, PL9...
<apritzel>
alikates: you need: "bic r1, r1, #0xff" since you need to clear *two* pins
<alikates>
Oops, right
<alikates>
Ty
<apritzel>
and the #9 is wrong as well, I think, you want 0x11, right?
<alikates>
Anyways, i see the PL have 3 bit pinmux function field, instead of 4 like the other pin groups
<apritzel>
3 bits of significant bits, but spaced 4 bits apart
<alikates>
^ this is why its 9
<alikates>
Aggg okay haha
<apritzel>
so you said 0x20000000 as the other PIO base, are you sure of that, and where does this come from?
<apritzel>
there is one "normal" GPIO controller, for most of the pins, with up to 10 ports
<apritzel>
and there is a separate one, in some kind of "always-on power domain"
<alikates>
It comes from the dts
<apritzel>
meant for the management processor, or when *most* of the chip is powered down, but not everything
<alikates>
Oookay i understand now
<alikates>
Have you seen any versions of this always on pinmux with more than 2 pins?
<apritzel>
yes, we have even SoCs with two or three ports in there
<apritzel>
the H616 doesn't have a management processor, so this side is somewhat reduced
<alikates>
In the dts i see 3 ports, one defined as red other green and blue, with pin ids 0,1 and 5 respectively
<alikates>
Its a bit strange
<apritzel>
for instance the H6 has PL0-PL10, and PM0-PM4
<alikates>
I dont know the mapping of that id to the actual offseta
<apritzel>
well, did you try "sunxi-fel readl 0x7022000"?
<alikates>
I tried writing, not reading, and it hangs
<apritzel>
that should give you the content of that register, on your host shell
<apritzel>
ah, OK, so we might have a wrong address somewhere, still
KREYREN_ has quit [Ping timeout: 480 seconds]
<alikates>
hmm i read 0xf1ffffff
<alikates>
and 0x00000040 at 0x7022010
<apritzel>
try the next address 0x7022004
<alikates>
0xffffffff
<alikates>
0x11111111 at 0x7022014
<apritzel>
what's 0x7022008 and 0x702200c?
<alikates>
writing to those hangs everything
<alikates>
all zeros
<alikates>
*writing to 7022000, sorry
<alikates>
and ..10
<apritzel>
mmh, there might be something wrong with sunxi-fel, then
<apritzel>
what is your scratch_addr?
<apritzel>
this is where sunxi-fel writes the helper code to make a proper word access
<alikates>
Huh no, writing all Fs to 0x7022010 and reading back gives me 0x0000ffff
<alikates>
scratch_addr is at 0x105000
<apritzel>
ah, that pattern makes some sense
<apritzel>
at least it's somewhat consistent
<apritzel>
there are 16 pins
<apritzel>
which means the first two words configure each pin, and all are set to 0xf
<apritzel>
which also would mean that is has the new type of pincontrol, where the pinmux actually covers all 4 bits
<apritzel>
(not just 3 as the H616 and every SoC befor that)
<apritzel>
which would mean that the TV303/H713 is more different than we thought
<alikates>
Oh interesting
<alikates>
So I understand one of the ports is set to output
<apritzel>
ah yeah, the D1 has its main PIO at 0x20000000
<alikates>
from the 0xf1ffffff value...
<apritzel>
yes, PL6
<apritzel>
so your chip is actually an "NCAT2", closer to the D1/T113 or A523
<apritzel>
so cool thing about the pinctrl is that it only implements used bits, as you have seen
<apritzel>
which means you can probe that for all ports
<apritzel>
and figure out how many pins each port has
<alikates>
Ah nice, because theres absolutely no info about this chip besides one cnx-software article covering its announcement in january 2023
<apritzel>
so for instance read 0x20000000, ..4, ..8, ..c
<alikates>
and a couple references to the family in github like you said
<apritzel>
which tells you how many pins PortA has
<alikates>
Hmm it hangs
<alikates>
ah sorry its one zero less
<apritzel>
yeah, that's always tricky, happens to me as well ;-)
<alikates>
Okay i'm able to hexdump the registers
<apritzel>
next try 0x2000030, ..4, ..8, ..c if the values in there make sense, we would have proof of it being an NCAT2 chip
<apritzel>
NCAT2 puts each port 0x30 apart, where the older chips used 0x24 only
<alikates>
yes looks like it's like that
<apritzel>
so if there are quite some "f"s in those registers, it would support that
<alikates>
lots of Fs at 0x0, 0x30, 0x60, 0x90...
<alikates>
yess
<apritzel>
very good!
<alikates>
And from that looks like the alternative pinmux has 21 ports
machinehum has joined #linux-sunxi
<apritzel>
21 ports? you mean up to 0x3f0?
<apritzel>
I think that's a red herring, the register layout only allows up to 10 ports, as there are other registers (for interrupt control) overlapping
<alikates>
i mean 21 pins, 2 ports i guess, PL and PM
<alikates>
I can see them in A523 manual
<alikates>
maybe it was a bit risky but I tried to configure all the ports as outputs and drive them
<alikates>
No led
<alikates>
:(
<alikates>
Btw, I see some "mipsloader" name in the DTS, do you know anything about that?
<apritzel>
yes, driving all pins is indeed risky, I would avoid that
<alikates>
as we say here "de perdidos al río"
<alikates>
translates to smth like yolo
machinehum has quit [Ping timeout: 480 seconds]
<alikates>
xDD
<apritzel>
those boards and SoCs are surprisingly robust, but people have managed to fry something once in a while ;-)
<apritzel>
as long as you don't hit the self-destruct reg..... <NO CARRIER>
<alikates>
No more fun project :(
<alikates>
Okay, setting PL6 to 0 kills FEL but I know why
<alikates>
in dts I see PL6 is the regulator enable
<alikates>
for the main CPU SS
<alikates>
power key is PL4, red led is theoretically PL0, blue PL1, arisc uart is PL10/11
<alikates>
and PL9 looks like the IR receiver
<alikates>
Might be that the leds require another regulator to be enabled
ftg has joined #linux-sunxi
<apritzel>
yeah, maybe, though mostly LEDs are directly connected
<apritzel>
so if you copy the T113 code in uart0-helloworld, you might be UART output from that...
<jernej>
aren't leds usually active low?
<jernej>
ah, depends
<apritzel>
I think we have seen both polarities
<apritzel>
btw: does anyone know how to describe two LEDs driven by one GPIO in DT? High on that pin turns on the blue LED, low turns on a (different) red LED
<apritzel>
is that covered by this multi-color LED scheme?
<alikates>
i will try the code from T113, ty!
wasutton- has quit [Ping timeout: 480 seconds]
wasutton- has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]