[U-Boot] [PATCH v1 0/2] spl: move SPL_OS_BOOT and SYS_OS_BASE to Kconfig

[Tom Rini]

On Thu, Oct 06, 2016 at 11:29:27AM -0500, Andrew F. Davis wrote:
> On 10/06/2016 12:55 AM, Heiko Schocher wrote:
> > This 2 patches move SPL_OS_BOOT and SYS_OS_BASE
> > to Kconfig. Checked with tbot testcase:
> > https://github.com/hsdenx/tbot/blob/master/src/tc/uboot/tc_uboot_check_kconfig.py
> > 
> > result:
> > 
> > Boards      : 1213
> > compile err : 13
> > not checked : 1
> > U-Boot good : 1185 bad 14
> > SPL good    : 1199 bad 0
> > 
> > Boards not checked, as they had compile errors:
> > ['adp-ag101p', 'bf533-stamp', 'cm-bf527', 'colibri_pxa270', 'omap4_sdp4430', 'openrisc-generic', 'qemu-x86_efi_payload64', 'sandbox', 'sandbox_noblk', 'sandbox_spl', 'smdk5250', 'snow', 'spring']
> > 
> > Boards not checked, as no toolchain:
> > ['xtfpga']
> > 
> > Boards which have differences in the resulting U-Boot bin:
> > ['am335x_baltos', 'am335x_evm_spiboot', 'am335x_igep0033', 'cm_t335', 'cm_t43', 'cm_t54', 'duovero', 'k2e_evm', 'k2g_evm', 'k2hk_evm', 'k2l_evm', 'omap3_pandora', 'omap3_zoom1', 'pepper']
> > 
> > I looked into the Boards with differences in the resulting U-Boot bin,
> > but could not find the reason, why they are different :-(
> > 
> > for example am335x_baltos:
> > 
> > $ make am335x_baltos_defconfig
> > $ cp .config config_org
> > $ make mrproper
> > - applied the 2 patches
> > $ make am335x_baltos_defconfig
> > $ diff -pruN config_org .config > gnlmpf
> > $ cat gnlmpf
> > 
> > --- config_org  2016-10-06 06:58:01.636514195 +0200
> > +++ .config     2016-10-06 06:58:36.459726538 +0200
> > @@ -270,6 +270,7 @@ CONFIG_SPL_MTD_SUPPORT=y
> >  # CONFIG_SPL_NO_CPU_SUPPORT is not set
> >  # CONFIG_SPL_NOR_SUPPORT is not set
> >  # CONFIG_SPL_ONENAND_SUPPORT is not set
> > +# CONFIG_SPL_OS_BOOT is not set
> >  # CONFIG_SPL_POST_MEM_SUPPORT is not set
> >  # CONFIG_SPL_SATA_SUPPORT is not set
> >  # CONFIG_SPL_USBETH_SUPPORT is not set
> > 
> > change in this patchserie for this board:
> > diff --git a/include/configs/baltos.h b/include/configs/baltos.h
> > index 58df571..e69c1b6 100644
> > --- a/include/configs/baltos.h
> > +++ b/include/configs/baltos.h
> > @@ -54,7 +54,6 @@
> >  #undef CONFIG_SYS_OMAP24_I2C_SPEED
> >  #define CONFIG_SYS_OMAP24_I2C_SPEED 1000
> > 
> > -#undef CONFIG_SPL_OS_BOOT
> >  #ifdef CONFIG_NAND
> >  #define CONFIG_SYS_NAND_U_BOOT_OFFS    0x00080000
> >  #ifdef CONFIG_SPL_OS_BOOT
> > 
> > Seems Ok to me, but I get a different md5sum for the U-Boot bin ...
> > 
> > Or for example the omap3_pandora board:
> > $ make omap3_pandora_defconfig
> > $ cp .config config_org
> > $ make mrproper
> > - applied the 2 patches
> > $ make omap3_pandora_defconfig
> > $ diff -pruN config_org .config > gnlmpf
> > $ cat gnlmpf
> > $
> > 
> > No difference in the .config before and after this patch,
> > but a difference in the resulting binary ... ?
> > 
> > Seems to me SPL_OS_BOOT, which is a SPL config option
> > has somewhere an influence to the U-Boot binary ...
> > 
> > Any ideas whats going on here?
> > 
> 
> No idea, all I know is that some config headers with long histories are
> full of hacky ifdef tricks and bugs. IMHO the best thing we can do is to
> quickly move everything to Kconfig and sort it out then, instead of
> battling the config logic in the header files with every change as we go.
> 
> I will try to help test these changes with the boards I have, but  I
> haven't been able to get any of my omap3 boards to boot correctly in a
> while :(. I'll see if anyone else here has one working they can test this.

FWIW, omap3_beagle (and it's an xM) is part of my current lab and tested
every time.  I'm FAT booting mine not raw mode.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161006/07202e40/attachment.sig>