<f_>
I added a printf there to be sure, and that's it I guess
<f_>
Putting this inside #ifdefs
<narmstrong>
nop sorry I can't...
<f_>
No problem
<f_>
You're quite helpful already
<narmstrong>
but I support you 100%
<f_>
AFAICT you do, indeed :)
<f_>
Imagine now if it can't find itself
<narmstrong>
lost in translation, u-boot edition
<f_>
Now also thinking that clk_get_bulk is the one returning ENOSYS
<f_>
clk_get_bulk: -38
<f_>
There's our proof ^
<f_>
What's weird is...debug doesn't work
<f_>
Actually not weird
<f_>
Perhaps should I set LOG_EMERG
<f_>
Anyway....
<f_>
clk_get_bulk doesn't work
<f_>
I presume this could be because of the device tree
<f_>
I'll have to see what actually fails
<f_>
Perhaps something in drivers/clk/meson
<narmstrong>
ignore it, you don;t need to enable clocks since they're already enabled, just disable clk code
<Kwiboo>
yep, just remove/comment out all clk_ calls in the driver to test
<f_>
Perhaps
<f_>
Will do.
<Kwiboo>
ENOSYS is also returned when support for a uclass is disabled, do you have CONFIG_SPL_CLK=y ?
<Kwiboo>
or whatever the Kconfig option is called to enable clock support in SPL
<f_>
# CONFIG_SPL_CLK is not set
<f_>
Very sleepy brain :/
<f_>
I knew ENOSYS was also used when support is disabled
<f_>
But then I hit into linking issues
<f_>
because SPL_REGMAP doesn't seem to be enabled either
<Kwiboo>
I still think the best approach in the end will be to enable TPL and have TPL do bare minimum: use debug uart, init dram, read X blocks from pos Y from the mmc boot device into SPL text base, jump to SPL text base
<Kwiboo>
basically do same as vendor BL2 :-)
<narmstrong>
yep so it should only use the boot device, not another so no clock, pinctrl, gpio or other changes needed
<f_>
Time to reenable CONFIG_LTO
<f_>
Wow, with -j4 it compiles so much faster
<f_>
*people laughing*
<narmstrong>
*people rolling on the floor laughing*
GNUtoo has quit [Ping timeout: 246 seconds]
GNUtoo has joined #linux-amlogic
<f_>
Now
<f_>
I got a linker error saying the .sram region got overflowed
<f_>
and that the bss section overlaps some other section
<f_>
SPL can run on a 16K size limit
<f_>
and there's still plenty of space between the header and 0xc000 that could be used
<f_>
(just need to modify SPL_TEXT_BASE and amlimage/header)
<f_>
4K is taken by the header
<f_>
4K is a lot
<f_>
/usr/lib/gcc/aarch64-linux-gnu/13.1.0/../../../../aarch64-linux-gnu/bin/ld: region `.sram' overflowed by 5544 bytes
<f_>
I keep getting that same overflow
<f_>
Let's try disabling some stuff..
<f_>
I'm giving up
<f_>
...so I'll go with Kwiboo's suggestion
<f_>
I'll enable TPL
<f_>
get it to init the DRAM, load SPL, and jump to it
<f_>
44K is just not enough
<f_>
and if only I could use any sort of compression :X
<f_>
anyway, I'll try to get a TPL to run
<f_>
But what should I set the SPL text base to?
<f_>
Where should I load SPL in memory?
GNUtoo_ has joined #linux-amlogic
GNUtoo has quit [Ping timeout: 246 seconds]
<f_>
Actually
<f_>
I could leave DRAM init to SPL
<f_>
Let TPL just load SPL from MMC to 0xD9001000, and have TPL at e.g. offset 0x1024
mripard has quit [Quit: mripard]
* f_
scraps that idea
<f_>
Totally fine with TPL -> SPL -> BL30 & BL31 & U-Boot
<f_>
TPL is b0rked.
<f_>
Upon compiling I see lots of compile errors
<f_>
*compiler
<f_>
¯\_(ツ)_/¯
luka177 has quit [Ping timeout: 245 seconds]
vagrantc has joined #linux-amlogic
<f_>
Perhaps should I make use of a very tiny MMC framework instead?
<f_>
Now it hangs.
rpardini has joined #linux-amlogic
<f_>
Now it can't find itself.
<f_>
(with everything in meson_mmc_probe commented/inside ifdefs)
jacobk_ has quit [Ping timeout: 246 seconds]
<f_>
CONFIG_SPL_CLK really is the one adding too much stuff
<f_>
>The clock subsystem adds a small amount of overhead to the image.
<Kwiboo>
f_: Hehe, yeah, it all adds up eventually, a minimal TPL that does bare minimum to load SPL, then SPL can have access to complete DRAM to go nuts
<f_>
Yeah but compiling TPL with the MMC driver leads to...issues
<f_>
And besides, we don't need any init for our lovely MMC devices
<f_>
Let me double-check
<Kwiboo>
Yep, we need to figure out how much of the meson mmc driver needs to work, and how we can fool mmc core to be happy enough to think it can successfully init the mmc device
<f_>
No I mean
<f_>
drivers/mmc/mmc-uclass.c
<Kwiboo>
Maybe MMC_TINY is something to look into, sounds like it is what we want to do, bare minimum to mmc interaction
<f_>
I'll enable it.
<f_>
But it's just a framework. It also uses the meson driver
<Kwiboo>
that cfg->voltages down to upriv->mmc = mmc; must probably stay, everything else in probe can probably go
<Kwiboo>
and just return 0 in meson_dm_mmc_set_ios
<f_>
But then it hangs
<f_>
clock is disabled (0Hz)
<f_>
clock is enabled (380953Hz)
<f_>
and apart from the printfs I added (just checking against NULL), it doesn't print a single thing
<f_>
Possibly trying to load something but then failing.
<Kwiboo>
possibe the different cfg-> values needs to be configured into a state that match what bl1 leaves the state in, or mmc core will try to change its state
<Kwiboo>
yeap, only dropped the serial hack I played with last weekend, like you mentioned, with "# CONFIG_SPL_SERIAL_PRESENT is not set" and not including the uart_AO in spl dtb, debug uart will be used
<Kwiboo>
meson_write(mmc=d900e348): writel(23f, 72000) <<-- address translation is not working
<f_>
Pretty clear what the problem is at this point.
<Kwiboo>
pdata->regbase <<-- = 72000
<f_>
Supposed to be 0xd0072000
<f_>
:^)
jacobk has quit [Ping timeout: 248 seconds]
<Kwiboo>
dev_read_addr at fault, it will at least with full of_live tree take parent reg / range into account
<Kwiboo>
mayby not fylly in flat dt / platdata mode
<f_>
Let's hardcode
<f_>
(for now)
<f_>
We do have apb@d0000000
<f_>
and mmc@72000 is a child of it
<Kwiboo>
Yeah, it is suppose to work, will look at patches on ML, have seen fixes for similar issues
<f_>
Thanks!
<Kwiboo>
LOL, that address issue has been hinted in the logs all this time: "fdtdec_get_addr_size_auto_parent: na=2, ns=2, fdtdec_get_addr_size_fixed: reg: addr=00000000x" <<-- addr = 0x0
<f_>
haha
<f_>
Always thought that `0000000x` thing was weird
<Kwiboo>
it is possible that ranges is causing issues
<narmstrong>
OF_TRANSLATE and OF_REAL should be enabled