00:37 <zpiro> hays: rule of thumb for linux, is tmpfs for half of RAM, and for lowerr limit as you say, the size of ROM. From principle it should always be possible to load from lower level boot order to this. ROM is also, and what it should be, BL0 written into microprocessor and chip, or BL1 or BL32, but in theory it dan be done.

00:39 <zpiro> the idea is thought, BL0 is the IC, it is literally etched in silicon, the rest is what you have to work with - where the cool question is how much cache before reaching DRAM.

00:42 <zpiro> hays: don't know, but, asking about errors and showing you can use a debugger is likely to lead to useful anwers for someones interest.

00:48 <zpiro> Just to be boring pendantic, ROM can be what is written to an IC, and what cannot be changed at all. To ROM that only can be written or changed when powered down.

00:50 <zpiro> EEPROM and all such things, come with ROM, it is not RAM.

03:40 <hays> anyone else have minicom not allow ctrl-o in nano?

09:04 <Dhruvag2000[m]> Hey, I was wondering if while generating the DTB is there a rule to enforce size padding to have even number of bytes?

09:06 <Dhruvag2000[m]> I am trying to build on an ARM device, I get the following output:... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/f46950ea703ce1cabd93584a1eb38ed67623e6ef>)

09:08 <marex> dtc -a maybe

09:10 <Dhruvag2000[m]> forgot to mention, this is part of a larger FIT image whose its again is generated by a script. So iff there was some Makefile option in general it would help more.

09:16 <Dhruvag2000[m]> is ``arch/arm/dts/Makefile:DTC_FLAGS += -a 4`` the correct way

09:21 <Dhruvag2000[m]> I tried adding a ``468 DTC_FLAGS += -a 4`` in main Makefile, didn't seem to help

13:49 <qschulz> fitimage support in extlinux is half-broken

13:50 <qschulz> I don't understand why fdtcontroladdr environment variable is passed to bootm if there's currently no third argument

13:50 <qschulz> considering that this variable is automatically set by U-Boot if U-Boot is built with FDT support (which is the case for most boards I would assume ?)

14:00 <qschulz> narmstrong: you actually reported this before, so looking if there's any patch somewhere

14:01 <narmstrong> qschulz: yep I pushed a fix but it broke some random tests, and I failed to find time finding why

14:04 <qschulz> narmstrong: https://lore.kernel.org/u-boot/20220527143725.131742-1-narmstrong@baylibre.com/ I guess.. Nothing new or another patch?

14:05 <narmstrong> qschulz: yep I don't see how to solve this except revert the offending commit

14:06 <qschulz> narmstrong: I'll revert in our BSP branch and we'll try to see if there's anything I can do

14:06 <qschulz> thanks :)

14:08 <narmstrong> at some point this would need to be fixed and someone will need to add a temporary fix in Yocto/OE aswell

14:11 <qschulz> narmstrong: good point, I could send a patch for u-boot in oe-core

14:11 <qschulz> until we get this fixed properly :)

15:17 <tlwoerner> (in U-Boot's Makefile...) is LDR a tool that is used outside ADI/BlackFin?