04:58 <punit> milkylainen: This might sound obvious but have you checked if the Image size is suitably larger when the cpio is built into the kernel. I've had instances where I had the wrong path in the config...

07:14 <milkylainen> punit I have and it is. :) Tried different compressions. Checked the CPIO on host before the kernel includes it. Seems completely fine. Tried uefi-stubbed U-boot + zboot a kernel with initrd. No go. Tried efi-stubbed kernel with builtin initrd. Same. No matter what I do I cannot get the kernel to realize that it has a builin cpio archive to use as

07:14 <milkylainen> initrd.

11:13 <broonie> Whatever the actual problem is it seems like there's also work to do improving the diagnostics, if there's a Kconfig saying there's something built in there ought to be explicit error messages if we can't find it.

11:15 <javierm> broonie: +1

11:57 <geertu> Doh, the spanish autoresponder is still subscribed to lakml.

11:57 <geertu> dwmw2 not responding to forced unsubscribe requests?

11:58 <javierm> geertu: so weird. The first time I saw that went to double check if I Cc'ed by mystake

11:58 <broonie> IIRC people did look and it's not obviously subscribed directly or something (eg, someone with a forwarder). ICBW though.

12:59 <apritzel> how much hackery is usually tolerated to avoid 64-bit (or long) divisions (which result in: "undefined reference to `__udivdi3'" on ARM)?

13:00 <arnd> apritzel: if you can prove that a 32-bit division is sufficient, doing that is usually preferred over an explicit div_u64

13:01 <apritzel> I need the "days since the epoch", so use "time64_t / 86400" atm, and changed that to: ((unsigned int)(time64_t >> 7) / 765)

13:01 <apritzel> which solves both year 2038 and the division, but I am wondering if that is too hackish

13:02 <arnd> apritzel: how perfomance-critical is it?

13:02 <apritzel> not at all, RTC

13:02 <arnd> and what do you do with that number?

13:02 <apritzel> write into some RTC MMIO register

13:03 <arnd> apritzel: would using time64_to_tm() solve your problem?

13:03 <arnd> or rtc_time64_to_tm(), alternatively

13:05 <apritzel> I actually come from a broken down struct rtc_time, and need the days since the epoch (don't ask: Allwinner ;-)

13:05 <arnd> apritzel: doing rtc_time64_to_tm() should actually be faster on pre-ARMv7VE which don't have a 32-bit integer division instruction, as that ends up using the optimized division-through-multiplcation

13:06 <arnd> ah

13:06 <apritzel> the compiler does umul anyway, in arm64 and in my "/ 765" above

13:06 <arnd> apritzel: not related to the Rockchip November-31 bug I guess?

13:07 <apritzel> no, they decided to avoid any kind of calendar in hardware, and now just count days

13:07 <apritzel> leaving the conversion to month and days to software

13:07 <apritzel> and lifting their very own year 2033 limit on the way

13:08 <arnd> ah, so you use rtc_tm_to_time64() to compute the seconds rather than having to implement the y/m/d to day conversion yourself

13:08 <apritzel> exactly

13:09 <arnd> apritzel: have you asked abelloni? He may have solved that problem elsewhere already

13:10 <arnd> if you just need to do that division, then using div_u64(time, 86400) should be obvious and reasonably fast, by degrading to a mul+shift

13:11 <apritzel> so I have now a static u32 seconds_to_days(time64_t), with a fat comment (and a single line of code), was just wondering if that problem popped up elsewhere already

13:11 <apritzel> arnd: div_u64> good idea, will look at that

13:12 <abelloni> there are couple other RTCs doing that

13:13 <abelloni> blackfin, cpcap, davinci

13:14 <apritzel> abelloni: indeed, I tried to look for that, but should have just grep'ed for 86400 ;-)

13:14 <apritzel> abelloni: thanks!

13:15 <abelloni> convert2days

13:15 <abelloni> rtc2cpcap_time

13:16 <abelloni> they are not great :)

13:17 <abelloni> set_alarm_or_time does a div_s64_rem

13:18 <abelloni> apritzel: I didn't reply to the series yet but something that would be great is to stop doing the offsetting in the driver and let the core handle that

13:19 <abelloni> i.e. getting rid of SUNXI_YEAR_OFF

13:20 <apritzel> seems like that turns into a separate series ;-), found some "long" bugs on the way ...

13:31 <arnd> abelloni, apritzel: note that the 'signed' helpers, div_s64() and div_s64_rem() are out-of-line, so these will not get the compile-time optimization for constant divisor. If you know that the dividend is positive, use the _u64 version

13:33 <apritzel> arnd: good hint, and yeah, "seconds since 1970" should be positive

13:35 <apritzel> (hopefully there are no Allwinner chips in DeLoreans ...)

13:41 <arnd> apritzel: whichever way you do the calculation, it usually makes sense to pick a range that goes as far into the future as reasonable

13:42 <arnd> apritzel: do you know the reported time on a dead battery?

13:42 <arnd> if it's constant, every other value should ideally be interpreted as later than that

13:44 <geertu> arnd: 0xffffffffU? ;-)

13:44 <apritzel> arnd: the new RTC stores 16 bits worth of days - I hope we won't have to deal with AW chips after 2149 anymore

13:44 <apritzel> and on power-up it's all zero

13:45 <apritzel> the BSP driver uses the UNIX epoch, and it's the easiest, so I just copied that

13:45 <arnd> yes, makes sense

13:46 <arnd> 128 years from now is long enough that we don't have to add any tricks to extend the range

13:47 <abelloni> but there is no trick

13:47 <apritzel> that's probably what they said about 2038 back then ;-)

13:47 <abelloni> the driver should just do what the HW supports naturally and leave any range offsetting/windowing to the core

13:48 <arnd> and also short enough that it would be a bad idea to treat the day number is 'signed', which would give you a range from 1880 to 2060

13:48 <arnd> abelloni: right, that is the most sensible way

13:50 <apritzel> arnd: but 1880 would cover Back to the Future III !!!1!!

13:51 <abelloni> and again, the RTC core already allows you to do that