00:26 <smaeul> mirko: hmm, I don't know of any reason why H6 boards would randomly crash. I'm assuming you have a UART hooked up before the crash, so you would see if Linux was panicking?

00:28 <smaeul> any non-environmental hardware issues (i.e. marginal cpufreq voltages) wouldn't show up on multiple different boards

00:29 <smaeul> and any software problem _should_ log something to UART

17:18 <pentabarf1> smaeul: i would be very greatful if you could have a look at my code for checking the rotpk from "normal world". Is this the right approach or am i totally wrong? https://gist.github.com/pentabarf/8695459ce25b289ae068fd6091502c9c maybe it is just not working on H3

17:27 <mirko> smaeul: uart connected, literally nothing

17:28 <mirko> put a heat sink on it in case it's an overheating issue after all, same

17:38 <kilobyte_ch> We are unfortunately still using the 3.4 Sunxi Kernel with NAND as Storage Medium. Any idea if there is a way to "stress test"/"benchmark"/verify the NAND Chip in such a Device?

17:39 <kilobyte_ch> Testin in terms of if it flips bits or does other funky stuff which the Allwinner NAND implementation can't deal with properly.

17:52 <mirko> kilobyte_ch: maybe not quite helpful, but different nand chips handle ECC differently. e.g.: does it have an OOB area? is metadata about bad blocks / write counts stored in there? if that's the case, the driver needs to be (made) aware of that. what i'm trying to say i guess is, that if you're suspecting it not being able to deal with it, you should check 3 things: nand flash's datasheet about expected

17:52 <mirko> write cycles per block and/or page, whether the driver makes use of the hardware's OOB space and what filesystem you use on top of the MTD layer (which i suppose you use rather than the block layer)

17:58 <kilobyte_ch> mirko: Unfortunately there is no MTD Layer with the 3.4 Sunxi NAND. I think theres also no Metadata available in the 3.4 Sunxi NAND implementation. Thus my idea to stress test chips.

18:03 <mirko> kilobyte_ch: what are you trying to achieve? wearing out blocks? that will happen either way. or do you want to verify whether it meets the minimum erase cycles promised by the datasheet?

18:03 <mirko> you *will* see blocks becoming bad - that's for sure

18:04 <kilobyte_ch> mirko: sure, no question that this implementation -will- fail at some point as it lacks proper ECC. The only thing i want to achieve is to find "bad" chips with flaky bits or other defects.

18:05 <kilobyte_ch> One idea is to write patterns like 0xFF, 0x00, 0xAA to the Chip and verify that it holds it on all cells. But I'm not sure how to achieve that in an easy manner.

18:09 <mirko> kilobyte_ch: current NAND flash chips have bad blocks right from the beginning, coming out of the factory

18:09 <mirko> you will always encounter NAND chips with bad blocks - which is considered totally normal

18:10 <mirko> there's usually an area at the very beginning of the chip which is guaranteed not to be bad - which bootloader/kernel should reside in, so booting from it is guaranteed

18:10 <mirko> from there on - nothing is.

18:12 <mirko> software is supposed to deal with it - be it the file system or whatever is in between (e.g. NAND flash driver, ..). This includes wear levelling. Your software stack needs to match the underlying hardware constraints.

18:16 <kilobyte_ch> The part with the area in the beginning is interesting, didn't know that

18:16 <kilobyte_ch> Also matches our experience with this (badly designed) device that the bootloader is always working, but it fails at some point during starting linux stuff.

18:17 <mirko> kilobyte_ch: datasheet of flash chip should mention the amount of blocks guaranteed not being bad - if you provide manufacturer and model i can take a look

18:18 <mirko> kilobyte_ch: than the area might be too small to already have code loaded dealing with bad blocks - or you're doing it too late

18:18 <mirko> bootloader + kernel + initramfs usually exceeds what's guaranteed

18:18 <mirko> so you better have ECC functionality working as soon as possible

18:19 <kilobyte_ch> The issue is that I can't really change anything on the device. Thus also my idea with the testing to do a kind of "burn in" test do sort out "bad" NAND chips with higher chance for flipping bits.

18:19 <mirko> (especially if the bootloader loads a huge initramfs)

18:19 <mirko> kilobyte_ch: that sounds like a very bad approach. better get your ECC working as early as possible

18:20 <mirko> or reduce all the "loaded by bootloader" stuff to fit into mentioned safe space, so bootloader doesn't need it but kernel is certain to be read and started correctly

18:21 <mirko> (clumsy grammar/wording, hope you still get the point)

18:21 <kilobyte_ch> At least we have two root partitions which the bootloader can switch if it doesn't boot successful for a couple of times.

18:22 <kilobyte_ch> Don't get me wrong, I fully agree with all your points and would also implement them if I would be able/allowed to do. But unfortunately I'm not.

18:22 <mirko> all in all, it has nothing to do with linux-sunxi / allwinner - but i'm not gonna play moderator here :)

18:22 <mirko> kilobyte_ch: two root partitions also sounds like a bad approachs, given that it's not unlikely there's bad blocks in both of them

18:23 <mirko> i use ping-pong rather for ensuring updates don't brick devices (fall back to working volume/partition, if boot wasn't successful after upgrade and/or upgrade failed)

18:24 <mirko> it's not supposed to help against bad blocks for reasons stated above

18:25 <mirko> but yeah, as initially stated: my answer(s) might not be heplful for what you actually wanna do, which I'm pretty convinced is not the right approach anyaway

18:28 <kilobyte_ch> Thanks for the explanation

18:30 <mirko> kilobyte_ch: first i'd check how much space / many blocks is guaranteed to be working for at least how many writes and then start finding solutions and/or workarounds from there

22:17 <smaeul> pentabarf: your code looks fine. most likely it means H3 does not support that function