ftg has quit [Read error: Connection reset by peer]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
radxanaoki1 has joined #linux-sunxi
radxanaoki has quit [Quit: radxanaoki]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
vagrantc has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
vagrantc has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
Sensu_Bean has joined #linux-sunxi
Sensu_Be1 has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
vagrantc has quit []
gsz has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
linux-sunxi.org is down?
apritzel has joined #linux-sunxi
<wens>
probably getting hit by AI crawlers again?
apritzel has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
wens: Suppose so; seems strange that they're bringing the wiki completely down though
<wens>
server only has so much cpu power for rendering
Sensu_Be1 has joined #linux-sunxi
Sensu_Bean has quit [Ping timeout: 480 seconds]
Sensu_Bean has joined #linux-sunxi
Sensu_Be1 has quit [Read error: Connection reset by peer]
Schimsalabim has quit [Ping timeout: 480 seconds]
sdfgsdfs 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
<gamiee>
+ mediawik is power hungry when attacked by AI
<gamiee>
right now, at pine64 servers, mediawiki is taking the most resources.
paulk-bis has joined #linux-sunxi
paulk has quit [Ping timeout: 480 seconds]
paulk-bis has quit []
paulk has joined #linux-sunxi
paulk-bis has joined #linux-sunxi
paulk has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
bauen1 has joined #linux-sunxi
radxanaoki1 has quit []
Sensu_Be1 has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
Sensu_Bean has quit [Ping timeout: 480 seconds]
Sensu_Bean has joined #linux-sunxi
Sensu_Be1 has quit [Read error: Connection reset by peer]
Daanct12 has quit [Quit: WeeChat 4.7.0]
bauen1 has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
flyback has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
flyback has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest23539
dsimic has joined #linux-sunxi
colinsane has quit []
Guest23539 has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
paulk-bis has quit []
paulk has joined #linux-sunxi
Sensu_Be1 has joined #linux-sunxi
<paulk>
apritzel: almost ready to send v3s series, sorry it took longer than I thought :/
Sensu_Bean has quit [Remote host closed the connection]
Sensu_Be1 has quit [Read error: Connection reset by peer]
<paulk>
aperezdc: I'm having a weird issue where the ephy led polarity is not applied on v2025.10, but it works on v2025.07
Sensu_Bean has joined #linux-sunxi
<paulk>
the syscon register value is definitely correct in both cases
Sensu_Be1 has joined #linux-sunxi
Sensu_Bean has quit [Ping timeout: 480 seconds]
iscle has joined #linux-sunxi
<iscle>
Hi! It's been a long time since I was around here, hope everything's well. A stupid question, is there any tool for Linux to flash PhoenixSuite images? I want to revert my A733 to stock and I can't find any, only LiveSuite which requires a kernel module which I'm not willing to install...
<apritzel>
paulk: no worries, and thanks for coming back to this!
<apritzel>
paulk: do you mean setting or clearning H3_EPHY_LED_POL? Is that bit even used at all?
<paulk>
apritzel: yes I have a board using the internal PHY that has LEDs and it needs this bit to correctly drive them
<apritzel>
paulk: I don't see any code handling this in the U-Boot driver at all, so am a bit puzzled how it should have worked before? Maybe the kernel set it up, and U-Boot just didn't touch it, after a reboot?
<paulk>
apritzel: yes I'm adding support for it, I mean that my patchs works normally when applied on top of v2025.07 but not on v2025.10
<paulk>
(and it always works in linux, indeed)
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
paulk: mmh, doesn't ring a bell from the top of my head. I'd try to squash all your changes in one patch and sneak that in right after the v2025.07 release, so that you can bisect
loki6669 has quit []
loki666 has joined #linux-sunxi
<paulk>
yes I don't see a better approach, nothing from the log stands out
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
lschmid has joined #linux-sunxi
Lightsword has quit [Quit: ZNC]
Sensu_Bean has joined #linux-sunxi
Sensu_Be1 has quit [Read error: Connection reset by peer]
vagrantc has joined #linux-sunxi
bauen1 has joined #linux-sunxi
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
apritzel has joined #linux-sunxi
<lschmid>
apritzel: Is it expected that booting with "bootm_boot_mode=sec" the system will successfully boot?
<lschmid>
Oh and should your snippet of writing to the uart also work inside the smc call?
<apritzel>
yes, the UART writes should work everywhere with the MMU either off or using a 1:1 mapping
<lschmid>
Okay then... Because i tried putting it into the _smc_psci function right at the top and got nothing...
<apritzel>
with boot_mode=sec? then it would skip all that
<apritzel>
which is also the downside: you lose the second core, since you won't have PSCI. It might even crash, when the kernel tries to do the SMC ...
<lschmid>
No no. boot_mode=sec was sonething i tried later. I did not touch boot_mode when I had that in there
<lschmid>
The kernel actually boots. Like to login. Init runs, but yes there is only one core
<diego71>
I'm tring to boot a kernel for a cubie A5e (A527 cpu), but i'm stuck with this error:
<diego71>
I suppose I probably missing something in the kernel, but I don't understand what is missing
<apritzel>
diego71: looks like the regulator driver? multiple AXP20X symbols
<apritzel>
or I2C, don't see that either
<apritzel>
serial and mmc are waiting for the regulator anyway...
gsz has joined #linux-sunxi
<apritzel>
lschmid: but does that assembly snippet work elsewhere?
<apritzel>
lschmid: can you verify that the MVBAR write worked, e.g. you can read back the same value?
<apritzel>
lschmid: and just to double check: this was booting from SD card, via a TOC0 image, right? I am just wondering if U-Boot really runs in secure SVC
<wigyori>
is there someone using the D1 boards with (compressed) kernel + dtb FIT images? can't seem to work out the addresses that would work, as any setup i try booting fails in u-boot with uncompress errors
<lschmid>
apritzel: I'll check those two thing right now. But as for booting, yes it's booting from SD (now eMMC because JTAG) via a TOC0 image, and the soc will not boot eGON images anymore, also u-boot crashes when loaded over FEL when trying to write the clk register thing (dont know the name right now) which it did not prior to fusing
<apritzel>
lschmid: another test would be to check if a write to CNTFRQ works: "mov r0, #0x420000; mcr p15, 0, r0, c14, c0, 0"
<lschmid>
CNTFRQ was the one I meant above
<apritzel>
right, that's indeed a good test
hentai has joined #linux-sunxi
<apritzel>
I am still wondering what's actually different at this point between secure boot and not, because that would only affect peripherals like the SID
<apritzel>
although there are some secure clock and DMA controls that we need to enable on other SoCs, maybe we miss this on the T113
<apritzel>
(and it doesn't matter without secure-boot, as those controls might get ignored then)
<apritzel>
though I think this would only show up later ...
<lschmid>
Would the kernel boot up fully tho, if that were the case with missing clocks or dma issues? (Assuming those would still matter with boot_mode=sec)
<apritzel>
with =sec we stay in secure state, so the controls don't matter. They are only needed to grant access to certain registers in non-secure state
<apritzel>
and to confirm: if you boot via FEL, you will run into all kind of issues, as you are stuck in non-secure state. There is a typically a trick to get out of this, but no one has figured that out of tested on the T113
<lschmid>
as for the snippet, yes it does work somewhere else. so I'd say _smc_psci never gets called or at least doesnt run
<apritzel>
(for the A64 this works by simply issuing an SMC, which sunxi-fel does automatically)
<apritzel>
but I think _smc_psci would only be called later, no? For instance from the kernel, once it wants to bring up the second core
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
<lschmid>
So "smc #0" does not end up in _smc_psci?
<apritzel>
the first smc should end up in _monitor_vectors
<apritzel>
which then first thing installs the psci vectors
<apritzel>
so that any *subsequent* SMC ends up there
<lschmid>
apritzel: yes it looks like MVBAR is written correctly, if 0x10000 is correct to begin with. But if I understood correctly before "_secure_monitor" should be the one that is first called using smc, so if the uart snipped in there worked that means that smc is working somewhat
<lschmid>
Oh right, we had that already. We're crashing or getting stuck in the "bx r6" inside the psci_stack_setup
<paulk>
apritzel: btw my issue with ephy leds was a patch that removes a phy reset
<paulk>
I've asked to revert it on the mailing list. It might affect other things as it was done pretty carelessly.
iscle has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
Been making decent progress on digging through A733's DRAM init. Even with firmware-driven training, it is significantly more complex than prior PHYs/controllers
<MasterR3C0RD>
Databook has been a saving grace for a lot of that complexity though thankfully
<lschmid>
apritzel: does cpsr contain the thumb mode bit on the t113?
iscle has joined #linux-sunxi
<MasterR3C0RD>
Bleh, there's one part of the PHY initialization that will be very unpleasant to rewrite though: `ddrphy_phyinit_C_initPhyConfigPsLoop`. The original source code for that function is itself 2598 lines long...
<MasterR3C0RD>
I'm hoping I can skip over it though since it's for configuring PStates
<lschmid>
apritzel: could it be connected that I sometimes have to reset my board twice after it crashes or I get a "prefetch abort" when doing a "continue" in gdb?
<lschmid>
Oh, and the pc in the prefetch abort is this weird "0xc08cb424" again
gsz has quit [Ping timeout: 480 seconds]
<apritzel>
lschmid: yes, CPSR contains the T bit. I suspected Thumb vs. ARM already, but that code looks like it's all ARM, and bit 0 is cleared in those jump targets
<lschmid>
T bit is 1 however according to gdb, but always is?
<lschmid>
at least cpsr remains the same as before entering psci_stack_setup and when trying to "bx r6" inside it
Sensu_Be1 has joined #linux-sunxi
<apritzel>
lschmid: can you check bit 30 in SCTLR? (mrc p15, 0, r0, c1, c0, 0)
<apritzel>
that should be 0, to enter monitor mode in ARM state. U-Boot only seems to read-modify-write that register, so if there is a 1 in there from the BootROM still ...
<lschmid>
apritzel: no bit 30 is not set. SCTLR is 0xC50878
<apritzel>
curious where this odd 0xc0..... address comes from ...
Sensu_Bean has quit [Ping timeout: 480 seconds]
<lschmid>
VBAR is 0x47f74000
<lschmid>
apritzel: is u-boot in thumb?
<lschmid>
Cause if not. Why are we crashing in Thumb mode?? "Flags: nZCv IRQs off FIQs off Mode SVC_32 (T)"
<apritzel>
most of U-Boot proper is indeed compiled in Thumb2: CONFIG_SYS_THUMB_BUILD=y
<lschmid>
But while in the initial smc call we're running as ARM?
<apritzel>
all assembly files are in ARM
<lschmid>
Okay, so if i look at the CPSR while in a .S file it shouldn't have bit 5 set, right?
<apritzel>
correct
<lschmid>
So 0x1d3 in CPSR while in "nonsec_virt.S" is somewhat unexpected
<apritzel>
how so? bit 5 is clear, isn't it? 0x1d3 is svc mode with A/I/F masked
<lschmid>
Yeah, I just noticed that too. Starting to count at 1 rather than 0...
<lschmid>
Do you have any other ideas where the 0xc08... addresses could come from?
Sensu_Bean has joined #linux-sunxi
Sensu_Be1 has quit [Read error: Connection reset by peer]
<MasterR3C0RD>
0xc0000000 is the start of cacheable DRAM according to the memory map, so potentially something in memory, so it'd be about 8 megs into system RAM
<lschmid>
MasterR3C0RD: I saw that too, but it's for the DSP memory map...
<MasterR3C0RD>
Ah... yeah, you're right.
Sensu_Be1 has joined #linux-sunxi
sdfgsdfs has joined #linux-sunxi
Sensu_Bean has quit [Ping timeout: 480 seconds]
<apritzel>
diego71: oh, I also noticed that your console string is not right, it should be: console=ttyS0,115200n8
<apritzel>
diego71: and for earlycon it's literary just "earlycon", without further addresses or types, then the kernel will pick the values from the DT
<apritzel>
that's more robust and as you notice not device specific, so you can use those parameters on every device (given it's UART0 and this is an 8250 compatible one)