JohnnyonFlame has quit [Read error: Connection reset by peer]
Consolatis has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Consolatis has joined #linux-amlogic
hexdump0815 has quit [Ping timeout: 252 seconds]
hexdump0815 has joined #linux-amlogic
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #linux-amlogic
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #linux-amlogic
zsoltiv_ has quit [Ping timeout: 256 seconds]
zsoltiv_ has joined #linux-amlogic
<narmstrong>
f_: you still need to reset the emmc, if the rom boot from emmc then the rom does it before running bl2, if you boot from usb you’ll have to reset emmc from uboot, look at the emmc pwrseq
psydroid2 has joined #linux-amlogic
zsoltiv_ has quit [Quit: Left]
zsoltiv_ has joined #linux-amlogic
<f_>
narmstrong: I boot from eMMC
<f_>
anyway I'll take a look at PWRSEQ.
<narmstrong>
Oh then it should work !
<f_>
I'll take a look at pwrseq anyway
<f_>
I wonder if Kwiboo's pwrseq patch got applied
<f_>
hmm doesn't seem to have been applied.
<f_>
so I'll apply it myself.
<f_>
I'm still afraid that my tree becomes a huge pile of downstream patches
<f_>
not upstreamable..
<f_>
Hmm Kwiboo's patch doesn't seem to work?
<f_>
>/usr/lib/gcc/aarch64-linux-gnu/13.2.0/../../../../aarch64-linux-gnu/bin/ld: /tmp/ccBP0NBD.ltrans0.ltrans.o: in function `meson_mmc_probe':
<f_>
>./u-boot/spl/../drivers/mmc/meson_gx_mmc.c:301:(.text.meson_mmc_probe+0x1d0): undefined reference to `pwrseq_set_power'
vkoskiv has quit [Ping timeout: 260 seconds]
zsoltiv_ has quit [Ping timeout: 264 seconds]
<f_>
$ ls spl/drivers/misc
<f_>
ls: cannot access 'spl/drivers/misc': No such file or directory
<f_>
Seems like despite this:
<f_>
$ grep SPL_PWRSEQ .config
<f_>
CONFIG_SPL_PWRSEQ=y
luka177 has joined #linux-amlogic
<f_>
It doesn't compile..weird
camus has joined #linux-amlogic
<f_>
Kwiboo: Hi, did U-Boot compile with your patch?
<f_>
*u-boot spl
<f_>
hmm seems like mmc PWRSEQ isn't needed anyway..
<xdarklight>
looking at your .dts: how does u-boot know about the voltages? there's no regulator in there (it's referenced as vqmmc-supply, with phandle 0x2a but that's not defined in the .dts)
<xdarklight>
I think it's also worth printing the configuration register in meson_dm_mmc_set_ios
<xdarklight>
or at least the input parameters (bus width, clock rate)
<xdarklight>
I'm wondering if it tries to tell the MMC controller to switch to an 8 bit bus but then pinctrl is not set up for that (not sure what bootrom uses but I'd expect it to try with a 1 or 4 bit bus width)
<f_>
I did notice something in BL2. It seems to do at least some init on eMMC.
<f_>
Looks like a new change. On GXBB, BL2 didn't init anything eMMC/SD-related at all.
<f_>
Dropped all of the 3.3V bits and also tried adding MMC_MODE_1BIT
<xdarklight>
:-(
<xdarklight>
are there any debug bits that you can enable in SPL? Linux has some debug option that prints every MMC command, all of the parameters and all card responses
<f_>
Probably, but I'm afraid that won't fit in 44K
<f_>
I tried removing that `if` (having that cmdarg set like so everytime) and it still doesn't work
<xdarklight>
can you dump the clock register (register offset 0x0 inside the SD_EMMC controller registers) so we can see if something unexpected is in there?
<xdarklight>
(I'd dump it right after we get the timeout)
<f_>
Think it's a clock issue?
<xdarklight>
at least we should check / rule it out
<f_>
oh I disabled clock support
<xdarklight>
but I think SPL doesn't have clock support anyways (looking at your .dtb again)?
<xdarklight>
add it to meson_mmc_config_clock but be careful: for newer SoCs (can be detected using MMC_COMPATIBLE_SM1) this has moved to BIT(28) instead of BIT(24) (see the Linux driver)
<f_>
ah yes
<f_>
Still doesn't work.
<xdarklight>
can you undo any changes we did to drivers/mmc/mmc.c to make sure we didn't break anything there?
<f_>
Done.
<xdarklight>
still no luck?
<f_>
I didn't try yet
<f_>
Nope.
<f_>
No luck
<xdarklight>
:-(
<f_>
:(
<f_>
Ok so in u-boot proper it works
<f_>
I was starting to worry about if it wouldn't work at all.
<xdarklight>
what if you remove the pinctrl nodes and try with fat u-boot? if it breaks then maybe we need to do the pinmuxing in SPL
<f_>
fat u-boot?
<xdarklight>
the full blown one, not running with the tiny SPL
<f_>
u-boot proper you mean?
<f_>
Ok
<xdarklight>
if that's the correct term then yes :)
<f_>
ISTR that SPL ignores pinctrl nodes
<xdarklight>
yep, my thought is: what if bootrom does something weird and switches the pinmux back to GPIO instead of eMMC? so if we can reproduce the fault by removing the pinctrl nodes with u-boot proper then it may be the cause within SPL
<f_>
and you're right!
<f_>
Card did not respond to voltage select! : -110
<f_>
^ u-boot proper with the pinctrl nodes commented out
<f_>
So that must be it!
<xdarklight>
hmm, there's CONFIG_SPL_PINCTRL
<f_>
good catch
<f_>
Then I just need to remove pinctrl nodes from the list of "nodes to be stripped"
<f_>
hope that it'll all fit..
<f_>
get an ld error
<f_>
"u-boot-spl section `.rodata' will not fit in region `.sram'"
<narmstrong>
pinctrl driver is quite big
<f_>
yup
<f_>
and we only have 44K max for SPL.
<narmstrong>
perhaps the pinctrl driver could be stripped to just the pinctrl entries for SPL
<f_>
Just enabling CONFIG_SPL_PINCTRL makes the binary take a lot of space, so pinctrl is probably a no-go..
<f_>
ugh
<f_>
I wonder if there's a stripped down pinctrl driver specifically for spl..
<f_>
>region `.sram' overflowed by 19360 bytes
<f_>
It's just too much.
<xdarklight>
if I've calculated right then 0xc88344cc would be the right pinmux register. can you dump it's contents from SPL and u-boot proper?
<f_>
Sure
<xdarklight>
bits 28-31 are the relevant ones for eMMC
<f_>
poking at it from the u-boot shell: c88344cc: f0000000
<xdarklight>
exactly what we want: eMMC pinmux (clk, cmd, data[0:7] and ds) is enabled
<f_>
indeed. Bits 28-31 are enabled
JohnnyonFlame has joined #linux-amlogic
<f_>
xdarklight: pinmux: 0xda0344cc
<f_>
^ pinmux register dump in SPL
<xdarklight>
BIT(29) is the eMMC CMD function
<f_>
and bit 29 is disabled, yes
<f_>
I could try forcefully setting that bit
<xdarklight>
can you hack together something: (register & ~0x3cff) | 0xf0000000
<xdarklight>
~0x3cff disables the NOR and NAND pinmux - those share some pads with eMMC (so I think we should disable them to make sure the signals are routed correctly within the SoC)
<xdarklight>
note that all of this applies to GXL only, pinmux registers on GXBB are different
<xdarklight>
that said, I'm starving and so I'm off for dinner. good luck and talk to you later