07:31 <conchuod> mvaittin: is a dh2228fv a product Rohm ever sold, or is it likely a typo of bh2228fv?

12:04 <Xogium> is ubiblock still maintained ?

12:05 <Xogium> and or still a good idea if you want to use squashfs on a qspi flash ? The one I was looking at is 16 mbytes only so it wouldn't make sense to use ubifs on it, I believe

13:52 <ajb-linaro> /kvm-unit-tests.git/lib/arm/mmu.c:216: assert failed: system_supports_granule(PAGE_SIZE): Unsupported translation granule 4096

13:52 <ajb-linaro> seems unlikely?

13:57 <maz> ajb-linaro: indeed. probably 52bit is enabled, and the test tests the wrong values.

13:59 <ajb-linaro> ahh -cpu max vs something else

14:46 <ukleinek> Xogium: 16 Megabytes, or 16 Millibytes?

14:47 <ukleinek> if it's 16 Millibytes, I agree, that's too small for ubifs :-)

14:48 <Xogium> :D

14:48 <Xogium> I meant megabytes

14:49 <Xogium> I wasn't aware mbytes could be interpreted as millibytes

14:49 <ukleinek> Xogium: reasonable persons don't :-)

14:53 <Xogium> fair ;)

14:54 <Xogium> still, 16 megabytes, isn't that a bit on the small side for ubifs ?

15:04 <cambrian_invader> why does it matter?

15:04 <cambrian_invader> fwiw ubifs also does transparent compression

15:05 <Xogium> I've heard that ubifs is more suitable on larget size of flash due to the way it works

15:05 <Xogium> *larger

15:07 <broonie> Xogium: I think that's more of a "scales up better" thing than a "doesn't scale down" thing.

15:13 <Xogium> UBI works by implementing “Logical Erase Blocks” (LEBs), mapping to “Physical Erase Blocks” (PEBs). The upper layers only see LEBs. If an LEB gets written to too often, UBI can decide to swap pointers, to replace the “hot” PEB by a “cold” one. This mechanism requires a few free PEBs to work efficiently, and this overhead makes UBI less appropriate for small devices with just a few MB of

15:13 <Xogium> space.

15:37 <Xogium> I'm unsure if it's a good idea to use ubi/ubifs or not given this statement -- that document is very old by now given it talks about logfs

15:37 <Xogium> so maybe things have changed

15:57 <arnd> Xogium: it depends on the write patterns. If writing to the file system is both rare and local to a couple of files, the combination of a read-only squashfs plus a writable jffs2 may be simpler.

15:57 <arnd> One downside of that is that the wear leveling only happens within the jffs2 then, but this can be ok if the total writes inside of the jffs2 are well below the rated number of writes per erase block

15:58 <arnd> with ubifs, you can use a large writable partition and it will try to rotate the read-only blocks as well so the wear is spread over all blocks equally

16:04 <milkylainen> Xogium: Hi. What are you doing?

16:04 <milkylainen> :)

16:06 <cambrian_invader> write leveling works better with more free space, since there are more options to choose from\

16:06 <cambrian_invader> but it doesn't matter if you use squashfs or ubifs with ubi, since ubi does the same wear leveling for both

16:08 <Xogium> cambrian_invader: I see

16:15 <Xogium> I suppose it doesn't get much better than ubi, since it does perform wear leveling at the ubi level and not the filesystem level

21:29 <cambrian_invader> how do I determine where to put thermal trip points?

21:30 <cambrian_invader> one might think to put the critical point right at the max junction temperature

21:31 <cambrian_invader> but I've also seen boards put it 10 degrees below

21:31 <cambrian_invader> and what about the passive cooling trip point?