<maz>
ah, got my rv1106 boards. 2017 vintage u-boot, 5.10 kernel. all good fun!
<CounterPillow>
ianh: that's the rockchip soc specific maintainer tree, which gets pulled into the arm maintainer trees. Development should be based against either mainline or linux-next and happens on the mailing lists that ./scripts/get_maintainer.pl returns for a patchset
<CounterPillow>
get_maintainer can also tell you which subsystem trees are preferred to base patches on for a specific file/dir
<CounterPillow>
A tool like b4 can help you manage patchsets and the submission process, though I've never used it myself (but plan on it)
<qschulz>
it adds the proper number for the current version too
<qschulz>
if you start working on v2, I suggest to regularly run b4 trailers -u to update the commits with the various Acked-by, Reviewed-by, Tested-by and all
<qschulz>
directly gotten from the ML
<qschulz>
and something else I use very often is b4 shazam --add-link --add-my-sob <lore.kernel.org patch URL> to port patches before they are merged
<Kwiboo>
macromorgan: sorry for taking long time to look at your memory/atag pathes, mostly looks okay, few quick notes: better to return e.g. -EINVAL instead of 1 when something is not successful, you could probably use SDRAM_MAX_SIZE instead of 0xf0000000
Stat_headcrabed has joined #linux-rockchip
<Kwiboo>
also look like your patches will not overlap with some rework I started playing with to improve boot performance, fdt_parent_offset is killing boot performance in u-boot
<qschulz>
I haven't started to look into it, but is there really no way to avoid hardcoding the TF-A reserved memory area if not provided by atags?
<Kwiboo>
on my rk3399 u-boot proper pre-reloc took around 750ms-1s probing ram-size and serial, and fdt_parent_offset takes crazy long time with a big fdt, 40-60ms each call
<Kwiboo>
using of_live and skipping entire use of driver model in pre-reloc stage, and my boot time in u-boot proper is down from 3-4s to 4-500ms
<CounterPillow>
Early driver model proves to be a mistake once again :D
<qschulz>
Mmmm, won't be able to use that on RK3399 Puma then considering we need DM in pre-reloc for our logic around boot medium detection
<Kwiboo>
hehe, yep, my small rk3308 rock-pi-s board went from around 1s to 200ms after also disabling net drivers
<CounterPillow>
qschulz: why is pre-reloc doing the boot medium detection? Is u-boot proper not on the same storage device?
<Kwiboo>
yeah, need to see and understand why we need to init env in pre-reloc, it could also be done after relocation
<qschulz>
yeah, if we could move this to after pre-reloc, it'd be nice... but the whole env "subsystem" is full of cornercases and special usecases :/
<Kwiboo>
dm in pre-reloc fells like a bad desing when a simple and very quick reading of ram size from a hw reg turns into a 2-300ms operation, and similar for serial/pinctrl
<macromorgan>
okay, I'll try to revise that a bit more and push upstream
<ianh>
CounterPillow, diederik, qschulz: thank yall. yeah i'm not sure if my changes would even be big enough to be worthy of a commit tbh. it's basically just putting the gmac in RGMII mode, mapping the RTL8211F reset line on the GMAC instead of the PHY, throwing in the pinctrls etc. but maybe i should, it would be good for both ethernet interfaces on the board to be enabled by default
<ianh>
i spent forever banging my head unable to figure out why the PHY couldn't be found on the mdio bus and eventually putting the reset stuff on the gmac as snps,reset-gpio did the trick
<qschulz>
Kwiboo: we've had this issue on Tiger and Jaguar RK3588 with clocks instead of resets and our patch for the MDIO subsystem to handle PHY clocks got denied
<qschulz>
So now we just enable the clock before booting the kernel instead :/
<qschulz>
the same logic applies for resets
crabbedhaloablut has quit []
crabbedhaloablut has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
crossdev has quit [Read error: Connection reset by peer]
crossdev has joined #linux-rockchip
crossdev has quit [Remote host closed the connection]
<ianh>
Kwiboo: yeah i was reading that earlier, it helped me a lot with understanding what was going on
<ianh>
in that case it definitely sounds like the "right" solution is waiting for the GMAC driver in u-boot and i can just use the deprecated snps properties as a hack to get it working until the uboot driver shows up
eballetbo has quit [Quit: Connection closed for inactivity]