narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki http://linux-meson.com/ - ml linux-amlogic@lists.infradead.org - official channel moved from Freenode - publicly logged on https://libera.irclog.whitequark.org/linux-amlogic
montjoie has quit [Ping timeout: 252 seconds]
montjoie has joined #linux-amlogic
jacobk has quit [Ping timeout: 255 seconds]
jacobk has joined #linux-amlogic
vagrantc has joined #linux-amlogic
hexdump0815 has quit [Ping timeout: 240 seconds]
hexdump0815 has joined #linux-amlogic
JohnnyonFlame has joined #linux-amlogic
buzzmarshall has quit [Quit: Konversation terminated!]
vagrantc has quit [Quit: leaving]
wens has quit [Ping timeout: 252 seconds]
wens has joined #linux-amlogic
cottsay has quit [Ping timeout: 252 seconds]
cottsay has joined #linux-amlogic
JohnnyonFlame has quit [Read error: Connection reset by peer]
f_ has joined #linux-amlogic
hexdump0815 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #linux-amlogic
<f_> Made some changes to then support gxl
<f_> e.g. moved binman configuration to meson-gx-u-boot.dtsi
<f_> I also updated the kii-pro defconfig
<f_> Hopefully I didn't break gxbb support :D
<f_> (quickly tested, I didn't)
<f_> I think porting to gxl will be a little more complicated than what I thought
<f_> e.g. bit 22 in gxbb sets the rank mode while in gxl it enables DDR4 IIRC
* f_ looks at lepotato acs
<f_> I assume that using one rank should work everywhere
<f_> (lepotato)
<f_> huh
<f_> CPU clock is set to 1200 MHz?
luka177 has quit [Ping timeout: 258 seconds]
<lvrp16> Yes the stock clocks are set to 1.2Ghz
<f_> We hardcoded the clock to 1.5 GHz with the assumption that all gxbb and gxl would work normally
<f_> Seems like that's not the case :D
<lvrp16> The datasheet mentioned something about dropping below 1.2ghz between > 1.2ghz transitions.
<f_> Makes me remember about this: 06:35 <lvrp16> i'm surprised S905 is able to get to 1.75GHz with overvolting. S905X breaks down not much after 1.45GHz.
<lvrp16> Yeah at the stock PWM voltages, even if you max out, it cannot go much higher than 1.5GHz.
chewitt has joined #linux-amlogic
<f_> Anyway, let's hardcode it to 1.2 GHz!
<lvrp16> I think with PWM going at full, it is 1.140V
<f_> Even if it can do 1.5 GHz I would still prefer using the stock values.
<lvrp16> Rockchip sets voltages much higher for RK3328
<lvrp16> I think 1.4GHz on RK3328 is 1.35V or something like that.
<f_> I still assume the stock values have been tested to an extent by either Amlogic or at your factory
<f_> So I'll stick to these for now
<f_> I guess I'll probably need to reverse gxl BL2 for dram init, even for lepotato
Danct12 has quit [Quit: What if we rewrite the code?]
<f_> Seeing how DMC_DDR_CTRL differs makes me think that they modified some other registers as well
luka177 has joined #linux-amlogic
Danct12 has joined #linux-amlogic
<lvrp16> Yeah they provide the reference DDR design so the software will just work.
* f_ looks at lepotato bl21
<f_> Oh well
<f_> I need to support VCCK being set at 1120 mv
<f_> Should be straightforward.
<f_> Done
<f_> Now syncing libretech-cc_defconfig with videostrong-kii-pro_defconfig
<f_> Am just enabling SPL stuff
<f_> Kwiboo: gxl starts BL2 at EL1 I think
<f_> Definitely doesn't start at EL3.
<f_> ^ lepotato also failing to init the DRAM
<f_> Also noticed hoe lepotato BL1 is stuck at trying to boot from SPI for a little less than one second
<f_> *how
<f_> hmm
<f_> Might be stuck on pll init after all
<f_> Power init works (obviously) but PLL init doesn't
<f_> hm
<narmstrong> clock stuff changed a bit between gxbb and gxl
<Kwiboo> f_: nice that nothing changed to restart execution at EL3, btw also pushed my TF-A changes to https://github.com/Kwiboo/arm-trusted-firmware/commits/amlogic, looked at gxl and it looks like scp is loaded from BL31 only on gxl
<f_> So no need to manually send the firmware from SPL?
<Kwiboo> it depends on how we do it, guess it can be done from spl or bl31, gxbb use mailbox and gxl use scpi
<f_> But how does it read the SCP firmware then? Is it read by BL2 and the address passed as an argument or something?
<Kwiboo> yes, it use a non standard struct (extended) passed to tf-a
<Kwiboo> looks like open source tf-a does not do anything for scp in g12a plat
<f_> hm
<f_> Could probably make our job easier or harder in a way
<Kwiboo> In https://github.com/Kwiboo/arm-trusted-firmware/commit/c92e1666273985a12fbb48f4bb6d1e622edd8034 I tried to make it skip loding scp if struct size passed by spl/bl2 is not large enough, no idea if that works
<Kwiboo> but at least it should make it optional if we want to load it from spl or not
<Kwiboo> you can see that struct gxl_bl31_param contains an extra image_info_t *scp_image_info[]; at the end compared to the standard v1 parameter
<f_> Indeed
<Kwiboo> so I just assume that on gxl bl2 read bl30.bin into some memory and pass the address to tf-a, that expects it in bl30/bl301 parts
<f_> Probably. Let's see.
<f_> >Load bl30 from SD, src: 0x00010200, des: 0x013c0000, size: 0x0000d600, part: 0
<f_> It does seem to load BL30 somewhere
<Kwiboo> hehe, yeah does random logs usually help a lot at some times :-)
<f_> They help in reversing too!
<f_> lol
<f_> Reversing how BL2 loads images should be trivial
<Kwiboo> one option could be to switch to v2 parameter, should have better support for sending multiple images, and move gxbb mailbox send into tf-a
<Kwiboo> will give more code size for other stuff in spl :-)
<f_> makes sense, but then we'll probably break support for proprietary BL2
<Kwiboo> that is why I was thinking of using v2 params, aml use v1 params, if v1 use old behavior, else use v2 and new behavior
<f_> But how can we detect that?
<f_> But then again, I think most people would probably want to use SPL+TF-A BL31 rather than AmlBL2+TF-A BL31
<f_> Kwiboo: Ah!
<f_> Sure
<Kwiboo> the parameter send to tf-a contains a small header struct at from_bl2->h, version, size and attr, so we can just put something special there :)
<f_> :)
<Kwiboo> and v2 format should have support for multiple nodes, so we can just pick some value for scp, unless they already have one defined: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/common/desc_image_load.c#n343
<Kwiboo> SCP_BL2U_IMAGE_ID
<Kwiboo> that was for the update, SCP_BL2_IMAGE_ID :)
<f_> Wanna work on that?
<f_> (booting SCP from BL31)
<Kwiboo> I can take a closer look at how to best load scp
<f_> Sure
<Kwiboo> sort of looks like it does something very similar one does in SPL and other in TF-A, but will investigate closer
luka177 has quit [Ping timeout: 240 seconds]
luka177 has joined #linux-amlogic
<f_> <narmstrong> clock stuff changed a bit between gxbb and gxl
<f_> Just saw this
<f_> Now that I think about it
<f_> 16:43 <f_> https://github.com/libre-computer-project/libretech-amlogic-boot.git bl33/arch/arm/cpu/armv8/gxl/pll.c
<f_> 16:47 <f_> AFAICT they just copied BL2 code and split it into multiple functions
<f_> We can use this
<f_> Hmm CNTL differs depending on clock?
<f_> Does it?
<f_> narmstrong: the register offsets changed
<f_> So the offsets in clock-gx.h are wrong, for gxl
<f_> Upstream clock-gx.h
luka177 has quit [Ping timeout: 258 seconds]
<f_> Oh well.
<f_> Either their datasheets are wrong, or I'm dumb
<f_> HHI_SYS_PLL_CNTL1 offset is 0xbf
<f_> But then you got HHI_SYS_PLL_CNTL at offset 0xc0
buzzmarshall has joined #linux-amlogic
ungeskriptet has joined #linux-amlogic
<f_> Oh, by the way, hexdump0815 want to test gxbb U-Boot SPL?
asriel has joined #linux-amlogic
<f_> chewitt: looked at WeTek sources and:
<f_> $ diff wetek_play2/firmware/timing.c gxb_p200_v1/firmware/timing.c
<f_> $
<f_> In the config they just set the size and rank mode
<f_> But apart from that p200 acs and WP2 acs are identical
<f_> p200 bl21 is identical to WP2 p200
f_ has quit [Ping timeout: 252 seconds]
jacobk has quit [Ping timeout: 240 seconds]
jacobk has joined #linux-amlogic
hexdump0815 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #linux-amlogic
<hexdump0815> f_[xmpp]: i'll test your stuff for sure at some point, but i'm busy with other stuff right now
<hexdump0815> f_[xmpp]: my gxbb box has nand, so testing it will not be trivial - but i think using a hdmi dongle i can force it to boot from sd card maybe
<hexdump0815> f_[xmpp]: i just checked - i have created boot blocks got gxbb as well when i did all my u-boot builds, so i guess i successfully tested it with the hdmi dongle on gxbb back then as well
JohnnyonFlame has joined #linux-amlogic