06:28 <chewitt> pmjdebruijn this should be a cleaner patch https://github.com/chewitt/linux/commit/65992f2c8da10274d6618eb5f19cde01775b7d1b

11:53 <pmjdebruijn> chewitt: thanks, I was going to ask for an updated patch indeed!

11:54 <pmjdebruijn> chewitt: wrt compatible = "haoyu,hym8563"; it's a cloned pcf8563 ?

11:56 <pmjdebruijn> I've also noticed some mouse lag

11:56 <pmjdebruijn> some seems to suggest it might be due to XHCI?

12:46 <pmjdebruijn> I also noticed my sdcard sometime is mmcblk0 and sometimes it's mmcblk1

12:59 <chewitt> I might have copy/pasted it from VIM3 in which case it's wrong (but change the compatible)

13:00 <chewitt> mmc naming and probe order seems to change doctrine every couple of years

13:00 <chewitt> the best advice is "never hardcode /dev/device names"

13:04 <pmjdebruijn> well, how do I let uboot find the proper node then?

13:06 <pmjdebruijn> most example I find use hardcoded device nodes

13:07 <chewitt> see http://ix.io/2LE0

13:07 <pmjdebruijn> root=LABEL= presumes the use of an initramfs

13:08 <pmjdebruijn> doesn't it?

13:08 <chewitt> I'm probably not the one to ask

13:12 <pmjdebruijn> ok

13:13 <pmjdebruijn> though I think the mmc devices can be alised

13:13 <pmjdebruijn> since these are hardwired onto the board, aliasing doesn't seem like such a bad idea, replicating the order from uboot

13:20 <chewitt> I think it depends on the SoC and maintainers

13:20 <chewitt> aliases worked last time I tried it

13:21 <chewitt> some maintainers are fine with it

13:21 <chewitt> others are like "burn the heretic" when you suggest it :)

13:21 <pmjdebruijn> it's dogma great :)

13:21 <pmjdebruijn> isn't*

13:22 <pmjdebruijn> in principle I kinda agree though

13:22 <pmjdebruijn> though requiring an initramfs is a rather large requirement

13:22 <pmjdebruijn> so there a lot of nuance to be found

13:24 <chewitt> fixed https://github.com/chewitt/linux/commit/9c4e99077a99752ce160dda76ad47707866b8b35

13:25 <chewitt> (also moved to the dtsi so it works on N2 as well)

13:27 <pmjdebruijn> ah

13:27 <pmjdebruijn> I just did that locally as well

13:28 <pmjdebruijn> I'll test your patch later today

13:33 <chewitt> It works

16:27 <chewitt> benoitm974 IIRC this is the cause of the booti problem https://www.spinics.net/lists/arm-kernel/msg832306.html

16:27 <chewitt> the solution is to use bootm

16:28 <chewitt> some of the vendor kernels patch it back

16:29 <chewitt> I'd be interested to know if this image boots https://chewitt.libreelec.tv/testing/9.80/LibreELEC-AMLGX.arm-9.80.8-box.img.gz

16:29 <chewitt> set the dtb name in uEnv.ini

17:37 <benoitm974> Chewitt you're wondering if it boots with booti or bootm ?

17:37 <benoitm974> booti I get a Bad Linux ARM64 Image magic!

17:38 <benoitm974> bootm I get this https://pastebin.com/9vy4CWSy

17:41 <benoitm974> By the way looking at the pastebin I'm wondering in those case if it is the kernle not booting or the serial not defined in the dtb and the earlyprintk and console linux not geting output ?

17:51 <benoitm974> Ok so confirmed it booted intouboot time: 201316608 us

17:51 <benoitm974> [ 0.504295] debugfs: Directory 'ff800280.cec' with parent 'regmap' already present!

17:51 <benoitm974> [ 0.993386] meson8b-dwmac ff3f0000.ethernet: The only allowed RGMII RX delays values are: 0ps, 2000ps

17:54 <benoitm974> you saved my night It was a problem of tty name that I found in your uEnv.... the kernel does boot inded

17:54 <benoitm974> gigabit ethernet workds too

18:00 <benoitm974> chewitt https://pastebin.com/txaL5ZA7