Hi Tom, Daniel, all, > On 1/27/23 14:45, Tom Rini wrote: > > On Mon, Jan 23, 2023 at 02:59:05PM -0700, Simon Glass wrote: > > > >> In several places a 'select' is used to select a choice, which is not > >> supported by Kconfig. In other places, the filename for the 'source' > >> command is not in quites. > >> > >> Fix these two problems throughout the tree, so that kconfiglib does not > >> show any more warnings. > >> > >> Signed-off-by: Simon Glass <s...@chromium.org> > > > > OK, to summarize what I just said in another email and clarify future > > work. Please first split this patch in to its own series that corrects > > each type of problem, per commit. The missing quotes for example, and > > then the extra whitespace ones. Next, commenting out a select is wrong, > > and each case needs to be better understood / fixed. I'm honestly not > > sure if asking endianness for MIPS is right and if we should select that > > from boards too, like ARC, but probably. The ARC_MMU one also should > > just not be asked, I suspect, but as a separate patch where you cc > > Alexey, we'll find out :) And so on, for each. Thanks. > >
Sorry for not chiming-in sooner, but I'm here now ;) > For MIPS the endianess (and also architecture/ISA level) needs to be able to > be set > by the user via menuconfig as most MIPS cores or SoCs can support multiple > variants. > The idea is that the specific SoC or machine just sets the supported options > to > restrict the options the user can choose. The board's defconfig should set the > required default value for each option but must not *select* it. > > See the Boston board for example: > > config TARGET_BOSTON > bool "Support Boston" > ... > select SUPPORTS_BIG_ENDIAN > select SUPPORTS_CPU_MIPS32_R1 > select SUPPORTS_CPU_MIPS32_R2 > select SUPPORTS_CPU_MIPS32_R6 > select SUPPORTS_CPU_MIPS64_R1 > select SUPPORTS_CPU_MIPS64_R2 > select SUPPORTS_CPU_MIPS64_R6 > select SUPPORTS_LITTLE_ENDIAN > > > > A possible fix for ARC could be: To be honest I don't quite understand what's a problem which we try to fix here and so it's not clear what to advise. ARC cores as opposed to MIPS are configured in IP design process and so if a particular chip is designed as little-endian and already produced in silicon, it cannot be turned into big-endian. Still ARCompact (AKA ARCv1) & ARCv2 processors could be configured as either little- or big-endian, thus we used to support both variants in U-Boot. And it's still there, so hopefully we may keep it. > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -53,8 +53,6 @@ config ARC > select SUPPORT_OF_CONTROL > select SYS_CACHE_SHIFT_7 > select TIMER > - select SYS_BIG_ENDIAN if CPU_BIG_ENDIAN > - select SYS_LITTLE_ENDIAN if !CPU_BIG_ENDIAN > > config ARM > bool "ARM architecture" > @@ -490,7 +488,7 @@ endif > > source "board/keymile/Kconfig" > > -if MIPS || MICROBLAZE > +if MIPS || MICROBLAZE || ARC > > choice > prompt "Endianness selection" > @@ -502,11 +500,11 @@ choice > > config SYS_BIG_ENDIAN > bool "Big endian" > - depends on (SUPPORTS_BIG_ENDIAN && MIPS) || MICROBLAZE > + depends on (SUPPORTS_BIG_ENDIAN && MIPS) || MICROBLAZE || > (CPU_BIG_ENDIAN && ARC) > > config SYS_LITTLE_ENDIAN > bool "Little endian" > - depends on (SUPPORTS_LITTLE_ENDIAN && MIPS) || MICROBLAZE > + depends on (SUPPORTS_LITTLE_ENDIAN && MIPS) || MICROBLAZE || > (CPU_LITTLE_ENDIAN && ARC) > > endchoice > > > > A *make savedefconfig* should than automatically add > *CONFIG_SYS_LITTLE_ENDIAN=y* or > *CONFIG_SYS_BIG_ENDIAN=y* to the ARC board defconfig's. That proposal looks reasonable and allows to keep existing code as it is, but can we just have only 1 config option which is used for endianess selection? I.e. why having both "SYS_BIG_ENDIAN" & "CPU_BIG_ENDIAN"? -Alexey