<f_>
# CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
luka177 has quit [Ping timeout: 255 seconds]
<Kwiboo>
f_: yes, noticed that also, I am still having issues with mmc, but starting to think it is because I have no dram
<narmstrong>
f_: indeed otherwise it won't know where to load from, but it depends where we want the fit image to be stored, it could be in the first partition
<f_>
I don't make use of partitions for loading images
<f_>
Kwiboo: honestly I doubt my DRAM init works at all
<f_>
:^)
<f_>
And even if it works I still have to rewrite one of the functions
<f_>
Really starting to like binman by the way
<Kwiboo>
I have had very strange issue in sd_get_capabilities, it first sends CMD55, then tries to send CMD51, but somehow the arguments is changed to CMD8 :S
<Kwiboo>
for mmc I noticed that bl1 leave the always on flag set, but mmc driver will unset it, also when it triest to set high clock rate it will switch from 24mhz osc clock to 1ghz clock that is disabled, so limit to 24mhz and change logic
f_ has quit [Ping timeout: 246 seconds]
<narmstrong>
perhaps you could run a memtest to check if the ddr is working ?
<hexdump0815>
xdarklight: somehow ethernet does not seem to work on my meson8m2 boxes with gbit eth port - no errors or warniings, they are configured rgmii and phy detects the connection properly as 100mbit which is the case here
<hexdump0815>
xdarklight: but i do not get any network connections - any idea what might be the cause? do you have any meson8 with gb eth working?
<hexdump0815>
chewitt: as you seem to be the amlogic audio expert :) - i tried headphone audio on my m8s box, but do not get any sound out of it
<hexdump0815>
chewitt: what would be required to make headphone audio work as well - looks like there is no mixer where i could enable/disable anything
<hexdump0815>
xdarklight: even if i set the network to rmii (mxiii instead of mxii-plus dtb) i'm getting the same behaviour: no error, but also not network connection
kilobyte_ch has quit [Ping timeout: 250 seconds]
kilobyte_ch has joined #linux-amlogic
buzzmarshall has joined #linux-amlogic
Daanct12 has quit [Quit: WeeChat 4.0.4]
Danct12 has quit [Remote host closed the connection]
jacobk has quit [Ping timeout: 246 seconds]
Danct12 has joined #linux-amlogic
vagrantc has joined #linux-amlogic
f_ has joined #linux-amlogic
<Kwiboo>
f_: new lesson learned: mmc device cannot read data directly into tzram, have to use the tiny mmc internal sram as a bounce buffer
<Kwiboo>
That ushort in struct mmc_cmd seem to cause issue with my builds, could be compiler/linker bug, with it changed to uint correct cmd was passed along
<Kwiboo>
meson mmc driver contains more changes than is needed, will try to cleanup later, started to align some code with linux during my testing session, but those changes may not fix anything
<Kwiboo>
One intereseting thing is that reading 512 byte from sd-card into mmc sram fails, but for emmc it worked, but then fails because it cannot memcpy into dram
<Kwiboo>
add .diff or .patch to github url to get plain text
<f_>
but thanks, didn't know this trick
<f_>
that's a long diff you got there
<f_>
narmstrong: Perhaps
<Kwiboo>
Hehe, it is that code + amlimate on top of v2023.10-rc3 that I have been playing with, meson_gx_mmc.c diff have lots of parts that is unneccecerty
<Kwiboo>
look for my HACK comments for the important part
<f_>
hm
<Kwiboo>
and the mmc sram bounce buffer should not be needed once you have dram working :)
<f_>
Doubt it works ¯\_(ツ)_/¯
<f_>
You see, when meson_write wrote at 0x72000?
<f_>
0x72000 is between 0x0 and 0xbfffffff
<f_>
And that just happens to be where the DDR is
<f_>
The fact that it failed to write to some random DRAM address proves that my init doesn't work
<f_>
But I'd still need to verify/test for sure
<Kwiboo>
Hehe, true, maybe some mmu tables needs to be configured
<f_>
We're literally back to the same issue I had with my custom DRAM init when I was working on TF-A BL2
<narmstrong>
No because there’s a 16MiB hole up to 0x1000000
<f_>
hah
<narmstrong>
On gxbb and gxl
<f_>
That's why there was an offset then
<f_>
Thought about that
<f_>
Still would have to test by writing to some random address, to be sure.
<f_>
that's a quick and dirty way of testing though.
<f_>
Anyway, I'll modify amlimage first
<f_>
sick of this size limit
<f_>
and you have plenty of space between the header and 0xc000
<Kwiboo>
you only have free space between header an start of code, 0x1000, and if you have emmc relocation code there is only free space between 0x420-0x1000
<f_>
Yeah what I want to try is having SPL @ 0x1024
<Kwiboo>
ahh, 3kb more space :)
<f_>
this is the offset where you normally have the eMMC relocation code, but I'd like to try.
<f_>
Of course that also means changing SPL_TEXT_BASE according to that
<f_>
Kwiboo: Perhaps we should also use OF_PLATDATA?
<Kwiboo>
looks like u-boot only will check 4k aligned code with CONFIG_POSITION_INDEPENDENT enabled, so you should probably be able to move it
<f_>
Ah yeah, also 4K-aligned
<f_>
so 0x1024 will not do I guess
<Kwiboo>
it should probably work, there is an if CONFIG_POSITION_INDEPENDENT around 4k align check in arch/arm/cpu/armv8/start.S
<f_>
Perhaps offset 0x1000?
<Kwiboo>
Yes, OF_PLATDATA and other space saving flags should be enabled
<f_>
ok I'll enable those first
<f_>
I can't tiny-ify the FIT implementation, else I'd lose ATF support too.
<Kwiboo>
offset 0x1000 = 4k, 0x400 = 1k
<f_>
I know
<f_>
We should now have ~3K less
<f_>
sigh
<f_>
ValueError: Cannot parse 'cd-gpios' in node 'mmc@72000'
<f_>
and vim can't find any mention of cd-gpio
<f_>
amlogic_meson_gx_mmc: WARNING: the driver amlogic_meson_gx_mmc was not found in the driver list
<f_>
hmm
narmstrong has quit [Server closed connection]
narmstrong has joined #linux-amlogic
<Kwiboo>
Yeah, use of OF_PLATDATA requires that drivers are changed to support it, it expect a driver names as compatible, or a driver alias