[PATCH 0/6] siemens,am335x: clean up the draco board family

[Heiko Schocher]

Hello Tom,

On 08.11.23 17:11, Tom Rini wrote:
> On Wed, Nov 08, 2023 at 03:53:16PM +0100, Enrico Leto wrote:
> 
>> The boards were not maintained upstream since the development phase.
>>
>> Restore SPL and remove unused settings. We need i2c to read the DDR
>> settings from EEPROM, get u-boot from NAND, the console output and the
>> watchdog.
>>
>> Restore u-boot up to the user prompt. The complete functionality will
>> be restored in future patches.
>>
>> Signed-off-by: Enrico Leto <enrico.leto at siemens.com>
> 
> I'm glad to see this series and in general it looks fine and is a good
> start. As some parts of the future cleanup work I'd love to see a file
> under doc/board/siemens for the family and moving to plain text
> environment, both of which iot2050 do so there's some in-house
> experience I am hopeful you can leverage as well if needed. It would
> also be good to reduce the include/configs/ files to as little as
> possible, I believe there's a number of dead-comments there, and other
> defines that are only needed in a local context and can move to a
> specific file or other header.  Thanks!

Yep, good points!

I tried this patchset on my dxr2 thuban board, and see a problem when
booting from NAND.

SPL fails to load u-boot.img (wrong ecc calculation)

reverting commit:

commit 04fcd2587321: ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction")

from Roger Quadros <rogerq at kernel.org> (as for this reason added to cc)

and SPL/U-Boot 2023.10 comes up fine with Enricos patchset!

remark: for plain U-Boot 2023.10 even SPL does not boot, so Enricos
  patchset is a big step in getting back a working board again, thanks!

So first, I wonder, if there is any am335x based board booting from
NAND with the above commit in?


If the above commit is in U-Boot, the following patch helps also
to get this board back booting:
"""
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index 1a5ed0de31..d1c73b389c 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -644,7 +644,11 @@ static int omap_correct_data_bch(struct mtd_info *mtd, uint8_t *dat,

        /* check calculated ecc */
        for (i = 0; i < ecc->bytes && !ecc_flag; i++) {
+#ifdef CONFIG_SPL_BUILD
+               if (calc_ecc[i] != read_ecc[i])
+#else
                if (calc_ecc[i] != 0x00)
+#endif
                        goto not_ecc_match;
        }
        return 0;
"""

but of course, this is not the solution ...

Any ideas are welcome, Thanks!

bye,
Heiko

(Damn, that I have not longer automated testing up and running for
this board)
-- 
DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de