01:56 <xypron> Tartarus: Long ago you reviewed https://lore.kernel.org/u-boot/20180826231332.2491-2-erosca@de.adit-jv.com/ ("UBSAN: run-time undefined behavior sanity checker"). Was there any specific reason not to merge this facility? To me it looks like a helpful tool for checking our code.

10:42 <Clamor> marex: yes, UA has xmas 25th like all other world

10:43 <Clamor> May someone who works with android clarify how binaries are licensed?

11:06 <mkorpershoek> I don't know, but maybe try #aosp-developers on OFTC?

11:07 <Clamor> mkorpershoek: thanks. Sorry for off topic

13:29 <IoT-Maker> i flashed my SPI eeprom using sf erase 0x0 0x800000; sf write 0x2000000 0x0 8388608, i loaded the image in openocd to 0x2000000 before writing in u-boot. i checked if writing was successful using sf read 0x3000000 0x0 0x800000 and md 0x3000000. It looked like the the file content. After reset i got an Bootrom: Invalid header checksum and Bad header at offset 002000000 and on. How can i fix this?

13:30 <IoT-Maker> how is the header checksum calculated?

13:38 <IoT-Maker> or, how does the system determine a correct checksum.

14:07 <IoT-Maker> I read the first 4 byte are the magic number, the next 4 byte are the CRC32 checksum for byte 0 up to 64. But that doesn't match the the files i testet. The original (untouched and working) SPI content has a CRC32 checksum for the first 64 bytes of 578196cd. But the Value of Byte 4 to 7 is 18E30B00. I let Malcat or ImHex do the calculation. I just marked the bytes.

14:24 <IoT-Maker> Magic Number is 5A 00 00 00 in all the dump files i got. I guess it's correct.

14:28 <marex> IoT-Maker: which board is that ? U-Boot version ?

14:28 <marex> probably use mkimage to generate the right image with the right header

14:28 <marex> kwb is the marvell stuff iirc

14:28 <IoT-Maker> Marvell U-boot 2.33, Marvell Armada XP SoC

14:29 <marex> ok, ask marvell for support then

14:32 <IoT-Maker> i don't have the tools to make a new image. I just changed some values inside the dump. There is a very long bootargs_g1 line in printenv that i tried to change. But it seems u-boot cut off my pasted line after 80 characters. My idea was just to change the value in the SPI dump and upload it.

14:35 <CounterPillow> If your workflow ever requires you to binary edit a rom dump and hack in new checksums it is the wrong workflow

14:36 <CounterPillow> U-Boot is GPL, you should have received the tools to build a new image and the source code with your binary.

14:44 <IoT-Maker> <CounterPillow: Yes, you are right. If i were a developer, i would to so. But i'm someone who tries to recover a Drobo NAS after failed firmware update (not my fault, not my device). So i'm looking for the easiest way to bring up this device, even if it means cheating.

14:47 <CounterPillow> Clearly there's a disconnect here if you think this path is easier

14:53 <f_> IoT-Maker: You should've received marvell U-Boot's source code.

15:14 <marex> IoT-Maker: isnt there an update package for the device somewhere on the vendor website ? If it is, extract the bootloader image and write it into SPI NOR ?

15:19 <Tartarus> xypron: Changes requested to https://patchwork.ozlabs.org/project/uboot/patch/20180826231332.2491-7-erosca@de.adit-jv.com/ and never followed up on

15:58 <IoT-Maker> marex: I got working bootloaders. But i want to change 2 values. And i can't do it in u-boot itself because the env argument exceeds the character limit

17:47 <rfs613> am looking at options to replace some board-specific "feature select" defines

17:47 <rfs613> https://github.com/renesas-rz/rzn1_u-boot/blob/rzn1-stable/include/configs/rzn1d400-db.h#L44-L52

17:48 <rfs613> I could use CONFIG_NET, CONFIG_USB, CONFIG_MMC for some of them

17:48 <rfs613> I don't see anything obviousl for GPIO, I2C, QSPI. I guess I could create my own Kconfig symbols for them.

17:50 <rfs613> (oh and happy new year!)

18:16 <marex> rfs613: just set the options in Kconfig as needed ?

18:18 <rfs613> marex: that works for some, yes. I'm wondering about how to handle for example GPIO. There is no generic "CONFIG_GPIO", only device specific one (like CONFIG_DWAPB_GPIO in my case).

18:19 <rfs613> and there are also the DM ones, like CONFIG_DM_GPIO, which I suppose I could piggy-back on... although that seems wrong ;-)

18:25 <Tartarus> er, there is CONFIG_GPIO

18:26 <Tartarus> drivers/gpio/Kconfig:menuconfig GPIO

18:26 <Tartarus> "menuconfig FOO" is just a special case of "config FOO"

18:29 <rfs613> Tartarus: okay, that was added in 2021.10, and i was looking at 2021.01

18:30 <rfs613> looks like there is also one for I2C now

18:33 <rfs613> so the only hold-outs for now are QSPI and NAND

18:33 <Clamor> Spi and nand are present as well

18:36 <rfs613> i'm doing git grep 'config NAND' and I see a bunch of drivers (CONFIG_NAND_xyz) as well as CONFIG_NAND_BOOT

18:57 <rfs613> well, anyhow, I think the answer is clear, I can mostly replace the board-specific #defines by existing Kconfig symbols

19:22 <marex> rfs613: time to upgrade ?

19:23 <rfs613> marex: i get to maintain the existing older version, in parallel with trying to upstream enough of it to be able to update to mainline

20:30 <marex> rfs613: but a version that old ... ugh !

20:30 <marex> rfs613: cant you #undef CONFIG_GPIO in yourboard.h ?

20:31 <rfs613> marex: the repo I pointed at is the original version, i'm actually on 2021.01, so not *that* old ;-)

20:32 <rfs613> I can #define or #undef the symbols in my header file, that works, but requires changing source code.

20:33 <rfs613> the goal is to be able to build u-boot with and without network support, for example.

20:33 <rfs613> ideally just by changing the defconfig

20:54 <marex> rfs613: if you want working Kconfig, update

20:54 <marex> rfs613: you cant have it all -- ancient version, all the bugfixes, working kconfig