[RFCv2] doc: develop: Describe system configuration

[Tom Rini]

On Thu, Jul 28, 2022 at 09:43:23PM +0200, Pali Rohár wrote:
> On Thursday 28 July 2022 15:26:08 Tom Rini wrote:
> > On Thu, Jul 28, 2022 at 09:21:52PM +0200, Pali Rohár wrote:
> > > On Thursday 28 July 2022 15:18:03 Tom Rini wrote:
> > > > On Thu, Jul 28, 2022 at 09:05:07PM +0200, Pali Rohár wrote:
> > > > > On Thursday 28 July 2022 14:53:49 Tom Rini wrote:
> > > > [snip]
> > > > > > +When it has been determined that the practical solution for where to have
> > > > > > +something is in the ``CFG`` namespace, the next decision is where to place these
> > > > > > +settings. It is strongly encouraged to place these in the architecture header
> > > > > > +files, if they are generic to a given SoC, or under the board directory if board
> > > > > > +specific. Placing them under the board.h file in the *include/configs/*
> > > > > > +directory should be seen as a last resort.
> > > > > 
> > > > > Sounds good.
> > > > > 
> > > > > The only missing bit of information for me, which I really do not know
> > > > > still remain... Where, how and in which format to store board specific
> > > > > CFG option which is required for architecture or SoC for proper setup?
> > > > > 
> > > > > It cannot be in board/ subdir because arch/ code cannot use it (and even
> > > > > do not know which include file should use). It cannot be in arch/ subdir
> > > > > because it is SoC specific (e.g. arch would have to use long spaghetti
> > > > > #if defined(BOARD_1) ... #elif defined(BOARD_2) ... #endif block). And
> > > > > it cannot be in include/configs/ because you do not like it and do not
> > > > > want it here.
> > > > > 
> > > > > Currently this issue is _un_solved by using CONFIG option either in
> > > > > Kconfig or in include/configs/ ... and both options are not ideal.
> > > > > 
> > > > > I just do not see how to solve this problem.
> > > > 
> > > > I think it's fine to have things in quite literally <asm/arch/soc.h>
> > > > (which we have a few of already) and then as needed #if / #elif / #endif
> > > > for SoC changes.  Much of this _could_ be instead pulled from device
> > > > trees.  But that's unlikely to happen for a number of platforms.  And
> > > > for the board specific cases which are not converted to come out of
> > > > device tree, include/configs/board.h isn't going to be able to go away
> > > > for that platform just yet.
> > > > 
> > > > So in a round about way, yes, I'm just punting on the problem because I
> > > > suspect the "right" answer is converting to driver model in a more
> > > > complete way and pulling the information from the device tree.  But I
> > > > accept there's not a desire on anyones part to invest that much time in
> > > > a dead end platform.
> > > 
> > > Driver model and device tree is probably the better place. But in case
> > > such option is required for SoC setup to allow U-Boot to access device
> > > tree then it cannot be in device tree...
> > 
> > I guess I need an example value or two please, that can't reside in
> > <arch/asm/soc.h> nor can be delayed long enough to come from the device
> > tree instead.
> 
> For example those powerpc preliminary local bus settings which
> configures boot device memory mappings. Boot source is chosen by user
> (currently by selecting appropriate defconfig file). It is something
> which is board specific (based on board wiring), for each boot source
> different and instruct u-boot in early stage to correctly map remaining
> part of u-boot binary where is stored DTB blob.
> 
> I can imagine such #if / #elif / #elfi / .... block in som arch/ file
> with more extensions to include also sub-#if block for boot source...
> but well such monster #ifdef hell is unmaintainable.
> 
> Look for example how many defconfig files are there for P[12]* boards.
> For every one you would have to introduce #elif chain.
> 
> But this is just an example. I can imagine similar issues on other
> platforms which have RDB boards with tons of boot source options.
> 
> I know also ARM64 based boards which have boot strapping options to skip
> integrated BootROM and start booting directly from CS or other device
> local bus.

Alright.  We know what the boot source is, since it's also a Kconfig
option.  If they're SoC specific, because we need to write in specific
values to say "boot MMC #1", hex under arch/.../Kconfig that depends on
SOC && BOOTMODE_FOO.  If they're board specific, because it's something
like "we need to set timing value 0x100 because of the lengths of the
traces on the PCB", hex under board/.../Kconfig that depends on
BOOTMODE_FOO.

And if it becomes a matter of "OR together these 5 different values"
then maybe we just can't kill off include/config/board.h after all, and
that just has to be where the board specific CFG_FOO things live.

> > One thing that we can and do in some platforms do today is have SPL use
> > a correct-enough simplified device tree so we always enable enough
> > clocks/mux to have GPIOs work to determine the real rev we're on and
> > pass the correct tree to full U-Boot.  I don't think we have the hooks
> > to re-evaluate the tree in full U-Boot, but perhaps we do need that.
> 
> We have such hooks, in proper U-Boot it is possible to do small
> modifications in DTB blob prior binding drivers. I'm preparing patches
> for Omnia board which use this feature. So it is not only possible but
> it is already working.

Maybe it was some other case that was being asked about where it was
wanting to re-process the whole device tree, not just modify some nodes.

> But in case device tree is not accessible yet (due to very early stage)
> then such hooks do not help.

This should be solved either by CFG_FOO or CONFIG_FOO that's not
prompted for.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220728/450fb800/attachment.sig>