<ad__>
debugging into kernel now, Looks like SPL is missing some smp related init
<ad__>
if any tip welcome
prefixcactus has joined #linux-sunxi
tnovotny has joined #linux-sunxi
warpme_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
lunixoid has quit []
tnovotny has quit [Quit: Leaving]
anarsoul has quit [Ping timeout: 480 seconds]
anarsoul has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
indy has quit [Ping timeout: 480 seconds]
indy has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
indy has quit [Ping timeout: 480 seconds]
indy has joined #linux-sunxi
indy_ has joined #linux-sunxi
indy has quit [Ping timeout: 480 seconds]
indy_ has quit [Ping timeout: 480 seconds]
indy has joined #linux-sunxi
indy has quit [Ping timeout: 480 seconds]
megi has quit [Remote host closed the connection]
megi has joined #linux-sunxi
indy has joined #linux-sunxi
indy has quit [Ping timeout: 480 seconds]
megi has quit [Quit: WeeChat 3.3]
megi has joined #linux-sunxi
<smaeul>
ad__: Linux is trying to call in to PSCI to turn on secondary CPUs, most likely because they have enable-method = "psci"; in the device tree. this is added by arch_fixup_fdt -> psci_update_dt -> fdt_psci in U-Boot.
<smaeul>
are you using a device tree you dumped from somewhere, or compiled from source?
<smaeul>
and yes, SMP is provided by U-Boot's PSCI implementation for H3. so if you don't use full U-Boot, or an alternative PSCI implementation, you won't get SMP
prefixcactus has quit [Ping timeout: 480 seconds]
indy has joined #linux-sunxi
<ad__>
smaeul, i tried disabling PSCI and system boots, but very slow. Yes, using mainline sun8i-h2-plus-bananapi-m2-zero.dts with some changes in it
<ad__>
issue is that i am trying to boot in falcon mode, from SPL. If i boot from regular u-boot , no errors
<ad__>
as u-boot is doing more initializations than SPL, or, devicetree not properly passed to the kernel ?
<apritzel>
ad__: if you see it booting, the DT should be fine
<apritzel>
ad__: I am not 100% sure, but maybe U-Boot proper does some more CPU clock setup?
<apritzel>
falcon mode is not really well tested on Allwinner (missing SMP being one reason), so I am not really surprised there are issues
<MoeIcenowy>
apritzel: PSCI implementation is in U-Boot at all
ftg^ has quit [Ping timeout: 480 seconds]
<MoeIcenowy>
for clock init code, there shouldn't be much difference
<apritzel>
MoeIcenowy: yeah, I was wondering, I thought we set the CPU clock to some safe value in the SPL ...
<MoeIcenowy>
apritzel: setting safe value and raise it to wanted value are both done in SPL
<MoeIcenowy>
(the second step is omitted if PMIC init failed
<MoeIcenowy>
CPU clock is never changed in main U-Boot, and clock_set_pll1() is even guarded with #ifdef CONFIG_SPL_BUILD
<apritzel>
right, but why is it slow then?
<jakllsch>
because it starts slow maybe?
<apritzel>
ad__: was the *loading* slow? Or the actual execution?
lunixoid has joined #linux-sunxi
<MoeIcenowy>
lossing SMP may lead to boot slow, especially if you have systemd (it does parallel booting)
<apritzel>
ad__: anyway, why do you want Falcon mode? Can you try to trim the full U-Boot stack (disable USB, etc.) to make it boot faster?
<ad__>
well, in SPL i had to add this
<ad__>
in board_init_sunxi
<ad__>
asm volatile("mcr p15, 0, %0, c14, c0, 0"
<ad__>
+ : : "r"(COUNTER_FREQUENCY));
<ad__>
without this, kernel was hanging much before
<ad__>
apritzel, already trimmed as much as possible, need more fast boot.
<ad__>
COUNTER_FREQUENCY is set to 24000000
<apritzel>
ad__: interesting, we should probably fix this, CNTFRQ should be programmed early
<apritzel>
does the 32-bit SPL run with caches off? That would explain slow loading ...
<ad__>
seems slow loading, is also in proper u-boot, when kernel PSCI disabled
JohnDoe_71Rus has joined #linux-sunxi
<ad__>
later i can send a u-boot patch for the COUNTER_FREQUENCY setup in a more proper place
<ad__>
but strangely remains the smp issue, so proper u-boot is doing something more
<ad__>
(thanks for your help)
<apritzel>
ad__: does it help if you use maxcpus=1 on the kernel command line?
cmeerw has joined #linux-sunxi
macromorgan has joined #linux-sunxi
<ad__>
apritzel, will try, thanks
<ad__>
in short will close my main job :) then some relax and i move to sunxi :)
<macromorgan>
hate to ask this, but has anyone had/been able to solve wifi issues with an SDIO interface?
<macromorgan>
I have a r8723bs (using staging driver on mainline kernel 5.10) on an R8 that seems to love to completely freeze up the entire system after an hour or 3. No dmesg, no warnings, no nothing. sysrq useless.
<macromorgan>
I'm completely stumped, as I otherwise have a fully functional mainline Debian working on the PocketCHIP off of NAND (using the slc-mode emulation)
cnxsoft has quit []
<ad__>
mmm macromorgan system hangs silently ? is it a custom board ? Would check power supply lines, maybe consumption of the module cause main power supply to suffer ?
<macromorgan>
it's the NTC PocketCHIP
<macromorgan>
with functioning battery and all
<macromorgan>
hmm... let me check what upower has to say
<macromorgan>
power looks fine, fully powered with a battery in good health
<ad__>
can you test it powered by a power supply ?
<ad__>
(just a think i would do in such cases)
Danct12 has joined #linux-sunxi
<ad__>
macromorgan, ^ also in such cases maybe magic sys rq keys may help (you need to enable them in the console, likely)
<macromorgan>
tried the serial version, no dice
<apritzel>
smaeul: were you planning for any changes on the U-Boot DM_I2C series? You mentioned a v2 in some reply, but I don't see a real reason. I would like to push it on the weekend, to get rid of the DM_I2C warnings.