00:00 <fpp> and also, i had to reboot the tablet to get the bootinfo and script files, and now it wont boot. On serial it gets stuck at Starting kernel

00:02 <fpp> I can see that when boot1 starts, it spits some information about the nand "log block" that i dont remember seeing before. here you can see those messages: https://pastebin.pl/view/a70d5da9

00:51 <fpp> I was able to boot the tablet, but the "FATAL: kernel too old

00:52 <fpp> " still appears when running meminfo. The tablet is running android 4.0.4, linux 3.0.8+

05:29 <Jookia> just a question for anyone working on u-boot with the t113/d1: is SPI NAND support a WIP? is there a big obstacle to it? or is it just work that needs doing?

09:04 <apritzel> Jookia: there is https://patchwork.ozlabs.org/project/uboot/list/?series=322733, which adds SPI NAND support in general

09:04 <Jookia> interesting! i'll try and glue it together

09:04 <Jookia> regarding the t113 patches with some work i got it booting

09:05 <apritzel> Jookia: I am almost there with a v2 series for the t113 ;-)

09:05 <Jookia> does it include psci? :D

09:06 <Jookia> i had to add some stuff for serial for the board i was using, uart3 is not ideal on the mango pi as it unsoldered

09:06 <apritzel> yes, it will include the PSCI patches

09:14 <apritzel> Jookia: so what's your UART, then?

09:14 <Jookia> apritzel: uart1 or uart2, haven't decided

09:15 <apritzel> does the BSP use one of them? typically boards tend to dedicate one particular UART for debug

09:15 <Jookia> apritzel: here's a diff if you're interested, it may have a fix https://paste.xogium.me/0j.txt

09:15 <Jookia> i'm not sure i've never used the BSP for it, but the uart2 is marked on the board

09:18 <apritzel> Jookia: you can send a patch with a last hunk and the pinmux setup change, the rest would be board specific and would need to come with a series adding support (DT) for your board

09:19 <Jookia> i won't worry about it for now

09:26 <szemzoa> I try to write a remoteproc driver for v85x, what is working more or less. (https://pastebin.com/brX2Ndkj). But I've to ioremap one gate/reset register in the driver, becose it has some reset bits, but the upper 16 bits in this register is a fixed keyword. Is there any way to use it with standard reset api?

18:28 <smaeul> szemzoa: are you ioremapping part of the CCU space? or is it a separate MMIO space for the E907?

18:29 <smaeul> for the CCU, you could add a flag in `struct ccu_reset_map` (drivers/clk/sunxi-ng/ccu_reset.h) and add logic to set the key field in ccu_reset_assert()/ccu_reset_deassert()

18:29 <smaeul> we already have this for clocks as CCU_FEATURE_KEY_FIELD