02:37 <Tartarus> sjg1: Then rockchip needs an update to follow best practices for the conversion, and we need docs that explain what best practices and likely solutions are

02:37 <Tartarus> It seems that given Fabio's patches, yes, all that's missing is good examples and documentation about them.

02:38 <Tartarus> Since it's NOT ok to just assume commits are enough, or we'd not have the follow-up cleanup patches Fabio also posted

03:36 <sjg1> Tartarus: OK let me have a look. Rockchip was done after driver model so has all the driver model stuff. What sort of update does it need?

14:21 <kallisti5[m]> does u-boot provide the bl1/bl2 things needed by Samsung Exynos5 boards?

14:21 <kallisti5[m]> I've found https://github.com/hardkernel/u-boot/raw/odroidxu4-v2017.05/sd_fuse/bl1.bin.hardkernel (stock) and https://pwhalen.fedorapeople.org/arndale/arndale-bl1.bin but both feel sketchy

14:27 <marex> kallisti5[m]: isnt bl1 bootrom ? (so no)

14:27 <marex> and I think on some exynos boards, bl2 was what, sboot ?

14:28 <kallisti5[m]> marex: found a (seemingly) outdated doc here: doc/README.odroid iROM->BL1->(BL2 + TrustZone)->U-BOOT

14:33 <kettenis> some (all?) exynos boards can only boot signed binaries

14:38 <kettenis> that's why hardkernel ships that binary that can run an unsigned u-boot in non-secure mode

14:40 <marex> heh

15:20 <rfs613> Looking at tools/patman/README, it suggests the tool works for both U-boot and Linux. Is there any special setup for the latter? Or do I just call u-boot's patman while PWD=Linux-kernel ?

15:22 <rfs613> I suppose I could just do 'python setup.py install', but I'm not entirely comfortable with that (bad past experience), so hoping for alternatives...

15:32 <kallisti5[m]> kettenis: aah ok. I was wondering about signing u-boot or something

15:32 <kallisti5[m]> kettenis: so what i'm hearing is I should slap the hardkernel bits on the sdcard, and then write the latest u-boot and hope for the best :-D

15:32 <kallisti5[m]> aka https://github.com/haiku/firmware/blob/master/u-boot/manifest.json#L100 :-)

15:34 <Tartarus> rfs613: sjg1 would be the best person to ask I think as I know there's a few people using it actively for kernel work

15:40 <hthiery> marex: did you test the clock driver for the imx8mq that angus provided?

15:40 <hthiery> or anyone else here?

16:08 <MiNuS_89> Hello, I just built a u-boot for an Archer C7 V5, just had to change one parameter to make it boot my linux but the kernel crash during the PCIe detection. May someone already hit this issue ?

16:09 <MiNuS_89> I have a CH341 programmer so I can try different configs and so far after playing around I did not manage to fix this PCIe issue

16:10 <MiNuS_89> U-Boot 2022.04-rc4 (Mar 15 2022 - 16:56:25 +0100)

16:11 <MiNuS_89> [ 1.770010] 8021q: 802.1Q VLAN Support v1.8

16:11 <MiNuS_89> [ 1.775142] PCI host bridge /ahb/pcie-controller@18250000 ranges:

16:12 <MiNuS_89> [ 1.781508] MEM 0x0000000012000000..0x0000000013ffffff

16:12 <MiNuS_89> [ 1.786923] IO 0x0000000000000000..0x0000000000000000

16:12 <MiNuS_89> [[ 1.998826] rr724x-pci11825000..pcie-cnntrolee:: PCIe iink is oonn

16:12 <MiNuS_89> 244244 P htt iiggeoo ss 0::0

16:12 <MiNuS_89> [[ .86557]ci_s 00:0: N bsnesurc fun fo rt us wl uee[b 00ff [ 2.884066pccbus 0000::rt s ssor [[mm 12000000x11fffff

16:12 <MiNuS_89> [[ .8874] ctoys uabl toopen tc evic (rt0) 28758] pi_s 00:0 bsn_re [bs 0-f] d s pdtedto00

16:14 <MiNuS_89> I passed the last few lines of the kernel boot that shown the issue (characters goes wrond and it freeze after)

17:37 <cambrian_invader> rfs613: nope, just cd into your linux source

17:38 <cambrian_invader> it will even use Linux's checkpatch/get_maintainer iirc

17:38 <rfs613> cambrian_invader: okay thanks, i'll give it a try for my next set of patches.

19:12 <marex> MiNuS_89: that is ar93xx MIPS ?

20:10 <Tartarus> sjg1: I wanna poke you about There is a certain amount of holy shit, we could be ending daylight savings stuff to all this

20:10 <Tartarus> Bah

20:10 <Tartarus> sjg1: https://patchwork.ozlabs.org/project/uboot/patch/20220311121248.2801589-3-trini@konsulko.com/

20:10 <Tartarus> stupid copy/paste

20:44 <marex> Tartarus: language

21:35 <MiNuS_89> marex: it's an AP152, CPU is a QCA956x

21:38 <MiNuS_89> I included Ethernet stack and it work well, I can tftp transfer and so on. It only freeze when I load OpenWRT. Maybe a missing step in the PCIe initialization but looked a bit averywhere in the code and docs, found nothing. I may missed something so if someone can guide me a bit I would more than appreciate.

21:42 <MiNuS_89> marex: the target is ATH79 in which QCA95XX and AR93XX, ... are

22:36 <marex> hah

22:36 <marex> nice to see the thing is being used again