<f_>
Really considering the possibility to load TPL before SPL
<f_>
Or just try having more space somehow
<f_>
Have it get loaded at some offset other than 0xc000
<f_>
Should be doable, just need to adjust SPL_TEXT_BASE and amlimage
<f_>
I won't do it now though
<Kwiboo>
I am guessing the mmc device bl1 loaded "bl2" from may be in a state where it probably can start taking new fifo read requests, but code in U-Boot will probably want to make a full init, set clocks etc before it tries to read data
<Kwiboo>
having a minimal TPL that does dram init and minimal interaction with mmc device to read SPL into dram could be something to investigate
<f_>
The mmc can start taking fifo reads already it seems.
<f_>
BL2 doesn't do any MMC init whatsoever IIRC.
<f_>
It does run a function called storage_init
<f_>
but it does absolutely nothing when running stuff from an MMC device.
<Kwiboo>
yeah, bl1 would alread have init the mmc device or it would not be able to read data, it probably also do not disable any clocks etc or it would cause issues for bl2
<f_>
Indeed
<Kwiboo>
drivers for meson in u-boot could be expecting to have some props that are stripped with CONFIG_OF_SPL_REMOVE_PROPS
<narmstrong>
if you remove clocks you'll have some issues :-p
<f_>
"some" issues
<f_>
Clearing this config still gives the same result.
<f_>
...and I probably know why
<f_>
there's no mention of clocks in u-boot-spl.dtb
f11f12 has quit [Quit: Leaving]
<f_>
Grr...binman: Node '/binman/u-boot-gxbb-with-spl/mkimage/blob': Entry contents size is 0xb225 (45605) but entry size is 0xb000 (45056)
<Kwiboo>
seeing how the mmc device is already init, I would try to rip out any code related to clock/reset/init in meson_gx_mmc.c and see it if can start issuing any commands
<f_>
Looks like a good idea.
<f_>
I'll do that tomorrow. For now I'll have to go.
<f_>
\o!
<Kwiboo>
Cool, basically an empty meson_dm_mmc_set_ios and probe could possibly work
<f_>
Will try that before disconnecting.
<f_>
It doesn't even get ran.
<f_>
I'll go.
f_ has quit [Ping timeout: 250 seconds]
<narmstrong>
Would probably work yes
hexdump0815 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #linux-amlogic
<hexdump0815>
f_[xmpp]: sorry can't really help with code in the area you are working on right now - this is quite a bit above my level :)
<hexdump0815>
xdarklight: chewitt: some progress regarding hdmi on meson8 - adding options like meson drm and hdmi phy support helped :)
<hexdump0815>
xdarklight: chewitt: now it probes well and i don't have any deferred devices anymore - somehow the monitor does not seem to get a valid mode now and i get
<hexdump0815>
xdarklight: chewitt: but to my surprise i seem to even have an audio device now on my good old mxq box - thanks to meson-gx sound it seems :)
<hexdump0815>
will be afk for a while now, but will read the logs just in case ...
<hexdump0815>
xdarklight: oh - and i noticed that meson-drm seems to depend on CONFIG_PHY_MESON_CVBS_DAC - maybe this could be handled by some config option dependency automatically for meson8?