<Kwiboo>
So now I have "fit read sector 100, sectors=2, dst=d9000000, count=2, size=0x400", and then I forced it to stop processing and panic, with DRAM it may jump into U-Boot proper
<Kwiboo>
Hope that can be of any help, let me know if there is anything else I can help test/investigate :-)
camus has quit [Quit: camus]
camus has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
repk_ has quit [Server closed connection]
repk_ has joined #linux-amlogic
hexdump0815 has quit [Ping timeout: 246 seconds]
hexdump0815 has joined #linux-amlogic
buzzmarshall has quit [Quit: Konversation terminated!]
_whitelogger has joined #linux-amlogic
luka177 has quit [Ping timeout: 246 seconds]
chewitt has joined #linux-amlogic
luka177 has joined #linux-amlogic
<chewitt>
hexdump0815 I have very fuzzy recall that video is 16/24 bit not 32 bit, but I could be imagining something
<chewitt>
and I have zero code knowledge on the HDMI bits for Meson 8 .. you really need @xdarklight
<chewitt>
similar for the audio Q
<chewitt>
the dts does look like it has the dac chip plumbed .. but does your box use the same chip?
luka177 has quit [Ping timeout: 255 seconds]
<chewitt>
i've not seen any issues with ethernet, but then I only have two M8 boards (Odroid C1 and a WeTek Core S812 box)
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 255 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 255 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 255 seconds]
luka177 has joined #linux-amlogic
camus has quit [Quit: camus]
luka177 has quit [Ping timeout: 246 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 250 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 258 seconds]
f_ has joined #linux-amlogic
<f_>
hi all
* f_
checks logs once again.
<f_>
Kwiboo: Nice!
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 255 seconds]
<f_>
Just for fun let's enable CONFIG_SPL_STACK_R
<f_>
That would be *the* test to make sure DRAM works
<f_>
With this SPL will move the stack to DRAM before running board_init_r
<Kwiboo>
f_: Thanks, will soon push a new fixup commit, trying to minimize and make some of the changes to mmc parts upstreamable :)
<Kwiboo>
Hehe, yep that is a good test
<f_>
Thank you for willing to help me. :)
<f_>
I knew that config wouldn't work
<f_>
But wait...
<f_>
It doesn't init the DRAM before relocating itself?
<Kwiboo>
it should call board_init_f before board_init_r
<f_>
indeed, but I don't see any logs related to DRAM init
<f_>
ah it does init the DRAM
<f_>
I see them, they were just at the top
<f_>
board_init_f *is* being ran
<f_>
But this DRAM init code really needs some rework.
<f_>
For now: a lazy hack
<Kwiboo>
btw, that strange mmc load address what because default spl_get_load_buffer implement: CONFIG_TEXT + offset, but function is called with -64 as offset
<f_>
hah
<f_>
Explains why that weird address
<Kwiboo>
also we cannot load FIT image to TEXT_BASE, if that is where we want to put U-Boot proper
<Kwiboo>
so not sure how that can work for any configuration :S
<Kwiboo>
We may still need to have some bounce buffer handling for when dest address is tzram, mmc driver will try to read to stack or malloc memory during init, unless we get stack/malloc to relocate to DRAM
<f_>
That will happen once I fixup my DRAM init code
luka177 has joined #linux-amlogic
<f_>
I'll rewrite all this
<f_>
Split it all
<f_>
So that we have at least something a little nicer to look at
luka177 has quit [Ping timeout: 246 seconds]
<f_>
I'm still way too curious at what will happen if we make use of the i.MX DRAM init code on G12
<Kwiboo>
Hehe, I am just about to test if my odroid-c4 (sm1) still can start and get as far as my c2 (gxbb)
<f_>
Perhaps try using the imx DRAM drivers? :)
<f_>
I'm very curious at what will happen but don't have any G12/SM1 board right now
JohnnyonFlame has joined #linux-amlogic
<Kwiboo>
f_: Is it just enable a Kconfig option and try? or do I need to do much more?
<f_>
I guess you need to write some code that will interact with this driver
<f_>
ah, also include the firmware (except aml_ddr.fw)
<Kwiboo>
booting and reading from mmc seem to work on my sm1, but it then gets stuck in a reset loop when trying to reset, will add some prints to see if they still use 6 MHz rate for mmc
<f_>
Sure.
<Kwiboo>
Ahh, looks like reset_cpu does psci_system_reset call, and on gxbb it does nothing, on sm1 it triggers: "Synchronous Abort" handler, esr 0x5e000000 in a loop
<f_>
Ah, but PSCI won't work at this point
<Kwiboo>
we could probably use watchdog to do sys reset in SPL
<f_>
That's what happens in gxbb
<f_>
and many other SoCs
<f_>
they just configure the watchdog, hang, and let the watchdog reset the board
<f_>
Imagine if Amlogic sees this and starts to contribute back
<f_>
That would be funny
<f_>
But yeah you're working on MMC, I'm working on DRAM :)
<Kwiboo>
Hehe, yep, looks like on SM1 they still use same clock divider for MMC: 4, so 24 MHz / 4 = 6 MHz
<Kwiboo>
Will check emmc also to be safe, but feels like we can upstream max 6 MHz for SPL build in meson mmc driver
<Kwiboo>
Yes it is using same clock divider, readl(ffe07000): 10000204, and it can read and understand the FIT header, so mmc driver changes should not break anything :-)
<f_>
Yay!
<f_>
Great job!
<f_>
By the way, want access to my u-boot repo, on my git server?
<f_>
git.vitali64.duckdns.org
<f_>
(this is just Cgit + Gitolite, so no accounts, just ssh public keys)