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
<alikates> Hey!! almost:
<alikates> > SPL: failure code 'eGON.???'
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
<alikates> Okay then
<alikates> Ty!
<apritzel> chapter 9.6.6 GPIO(PL) register description
<alikates> Okay tysm! Enough for today, it's almost 3 am here and I have work in a couple hours... (on OSHW ASIC designs :DD)
<alikates> Seeing some progress possessed me
<alikates> See you!
<apritzel> I know that feeling ;-)
<apritzel> cu
nickA has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
utsweetyfish has joined #linux-sunxi
nickA has quit []
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
chewitt has joined #linux-sunxi
NekoMay has quit [Ping timeout: 480 seconds]
NekoMay has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<wens> smaeul: would you have time to respin the regulator and dt patches? otherwise I can resend them, but I don't have any way to test them.
warpme has joined #linux-sunxi
gsz has joined #linux-sunxi
warpme has quit []
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
machinehum has joined #linux-sunxi
<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 joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
vpeter has joined #linux-sunxi
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> apritzel: this is the assembly I wrote https://share.riseup.net/#ATaH6rptoCLLJFAyuklksw
<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]
Schimsalabim has joined #linux-sunxi