ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
hanetzer has quit [Ping timeout: 252 seconds]
kevery has joined #linux-rockchip
hanetzer has joined #linux-rockchip
hanetzer has quit [Ping timeout: 248 seconds]
hanetzer has joined #linux-rockchip
stikonas has quit [Ping timeout: 265 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 248 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 264 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 264 seconds]
kevery1 is now known as kevery
Tenkawa has quit [Quit: Was I really ever here?]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
kevery has quit [Remote host closed the connection]
kevery1 has joined #linux-rockchip
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 246 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
Rathann has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
camus1 has joined #linux-rockchip
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
kevery has quit [Ping timeout: 252 seconds]
naoki has quit [Quit: naoki]
clarity has quit [Ping timeout: 268 seconds]
clarity has joined #linux-rockchip
clarity has quit [Ping timeout: 260 seconds]
clarity has joined #linux-rockchip
camus has quit [Quit: camus]
ldevulder has quit [Remote host closed the connection]
ldevulder has joined #linux-rockchip
Tenkawa has joined #linux-rockchip
tomeu has quit [Quit: The Lounge - https://thelounge.chat]
<CounterPillow> Kwiboo: btw do you plan to upstream rk356x stuff for u-boot? I know macromorgan was working on this and pgwipeout kind of gave up on it after not receiving much of a response
<Kwiboo> CounterPillow: some parts at least, unsure about the state of pgwipeout commits at the moment
<CounterPillow> He told me if he were to pick it up again he'd probably just completely rewrite them
<Kwiboo> I have following u-boot series in mind/wip atm: 1. rockchip-tpl v2, 2. efuse for rk32/rk33 and otp for rk35, 3. emmc for rk3588
<CounterPillow> sounds good. If the rockchip tpl stuff lands I'll probably send my PINE64 stuff upstream once I write it
<macromorgan> yes, I do plan on doing that. Honestly I'm waiting for the GPIO stuff to settle down in upstream linux first.
<macromorgan> There's a change to how the GPIO banks are selected going into upstream linux, that I want to be reflected in the GPIO driver for the rk3568
<CounterPillow> I hope me and naoki can figure out why big device trees don't work :(
<macromorgan> which while not a prerequisite, is easier than hard-coding the necessary pin configs in the board.c file
<CounterPillow> Hmmm, so the pin conigs could then be part of the soc specific driver?
<macromorgan> yeah
<macromorgan> the pin configs for the 356x and 3588 have additional registers
<CounterPillow> Sounds good, would save me duplicating a lot of code across these 5 boards I plan on supporting
<macromorgan> but the main issue is that right now the GPIO banks are numbered arbitrarily, those upstream linux fixes should solve that
<macromorgan> which will change the devicetrees
<macromorgan> which U-Boot will want to/need to account for if we want to stay in sync with Linux (which I kind of do)
<CounterPillow> Yeah
<CounterPillow> I think the ideal state is where we can just copy paste device trees from Linux, as they're intended to be independent of kernels
<macromorgan> I've also been following the upstream A-TF progress: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16952
<CounterPillow> What's the impact of SCMI clock functions not being present? No reclocking?
<macromorgan> the latest v5 patchset works fine for me on my test devices, except it's lacking control for the CPU clock like the vendor A-TF has
<macromorgan> correct
<CounterPillow> Hmmm, yeah that's kind of a blocker for me using that, but might still be handy for debugging why the jump to atf dies
<macromorgan> though in theory since reclocking that specific clock was done previously by the BSP driver and removed, the information necessary to implement it yourself should be publicly available in one form or another
<macromorgan> did you reorder your A-TF binaries?
<CounterPillow> I use whatever order is in kwiboo's branch, so probably. It only dies on large device trees (above 62000 bytes in size)
<macromorgan> for some reason U-boot lays them out one way in the u-boot.its file, but the BSP U-boot lays them out differently
<macromorgan> hmm... that's curious
<CounterPillow> this is the dumpimage -l output of my fit image https://gist.github.com/CounterPillow/b2b64922b88960dbb738147c56aa286f
<CounterPillow> this is the boot log with debug on https://gist.github.com/CounterPillow/f678a086fc0aa47b24433fdb729162c2
<macromorgan> wrong order
<Kwiboo> the load order should not matter in normal case, but can matter if the data should be loaded next to each other and the data is unaligned to block size
<macromorgan> try reordering your u-boot.its, regenerating the u-boot.itb, and use that new one to see if it works: https://gist.github.com/macromorgan/80bd5231256ba0e4077f5b3b7d84cd7e
<macromorgan> okay, gotcha
<macromorgan> actually you might exclude Optee from that thing I just posted, but otherwise that's how I get it to work
<Kwiboo> I recommend passing -B 200 to mkimage command if you use old its file, "MKIMAGEFLAGS_u-boot.itb += -B 0x200", should take care of aligning external data
<CounterPillow> right I totally forgot to test that with this current branch I'm working off of, let's hope that fixes it
<CounterPillow> unfortunately that didn't fix it :/
<Kwiboo> I see now that your fit will load dst=68000 size=1e34 before dst=6a000 and the size is smaller so should not overlap even if the data was unaligned and spl fit loader would have to memcpy data around
<CounterPillow> yeah I don't think this is an issue with things overlapping, it might be an issue with it running into some fixed upper limit for memory that it's allowed to use or something
<Kwiboo> regarding dtb size limit issue, doesnt u-boot use two different fdt, one size reduced for SPL and another one for u-boot proper?
<CounterPillow> correct, and the latter is the problem
<Kwiboo> try with CONFIG_ATF_NO_PLATFORM_PARAM=y, will skip sending fdt_addr to atf
<Kwiboo> should be CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
<CounterPillow> !!!!!! that worked
<diederik> \o/
<CounterPillow> thanks, now I can have overlays which was my one big missing thing \o/
Rathann has quit [Ping timeout: 246 seconds]
<Kwiboo> great that is works now :-)
Rathann has joined #linux-rockchip
Kwiboo has quit [Quit: .]
Kwiboo has joined #linux-rockchip
Kwiboo has quit [Client Quit]
Kwiboo has joined #linux-rockchip
vagrantc has joined #linux-rockchip
naoki has joined #linux-rockchip
<naoki> oooooooooh
<naoki> CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y ?
stikonas has joined #linux-rockchip
<CounterPillow> yeah
<naoki> it seems RK3308, RK3328, and RK3399 use it
<naoki> should it be in arch/arm/mach-rockchip/Kconfig ?
<Kwiboo> unsure, it is needed for broken vendor blobs, but this options is probably not needed with upstream atf or if a fixed vendor atf blob become available
naoki has quit [Quit: naoki]
naoki has joined #linux-rockchip
naoki has quit [Client Quit]
naoki has joined #linux-rockchip
naoki has quit [Quit: naoki]
Rathann has quit [Ping timeout: 265 seconds]
UndrWater has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
UndrWater has joined #linux-rockchip
naoki has joined #linux-rockchip
Tenkawa has quit [Quit: Was I really ever here?]
vagrantc has quit [Quit: leaving]