On Thursday 12 May 2022 12:01:26 Tom Rini wrote: > On Sun, May 01, 2022 at 12:17:51PM -0400, Tom Rini wrote: > > On Sun, May 01, 2022 at 05:33:19PM +0200, Pali Rohár wrote: > > > On Sunday 01 May 2022 11:14:21 Tom Rini wrote: > > > > On Sun, May 01, 2022 at 04:44:16PM +0200, Pali Rohár wrote: > > > > > On Sunday 01 May 2022 10:39:39 Tom Rini wrote: > > > > > > On Sun, May 01, 2022 at 04:23:52PM +0200, Pali Rohár wrote: > > > > > > > > > > > > > This reverts commit c7fad78ec0ee41b72a58bebb61959570eb937ab1. > > > > > > > > > > > > > > This commit made configuration, understanding, maintenance, > > > > > > > debugging and > > > > > > > future development of the powerpc/mpc85xx Local Bus Controller on > > > > > > > P1/P2 > > > > > > > boards impossible. > > > > > > > > > > > > > > All preliminary Base and Option registers depends on other code > > > > > > > and C > > > > > > > macros generated at C compile time and they comes from the other > > > > > > > macros. > > > > > > > > > > > > > > For example, NOR base address and NOR options are set via macros > > > > > > > CONFIG_SYS_FLASH_BR_PRELIM and CONFIG_SYS_FLASH_OR_PRELIM. And > > > > > > > then based > > > > > > > on other logic are filled correct values in to the correct macros > > > > > > > CONFIG_SYS_BR*_PRELIM and CONFIG_SYS_OR*_PRELIM. > > > > > > > > > > > > > > These config options are not user configurable options and > > > > > > > therefore > > > > > > > should not appear in menuconfig. Moreover for P1/P2 boards they > > > > > > > have > > > > > > > nothing with DDR driver, so they should not appear in drivers/ddr. > > > > > > > > > > > > > > This change was completely wrong direction, so revert it. It > > > > > > > allows to > > > > > > > start fixing issues with FLASH, NOR, NAND and CPLD LBC > > > > > > > configuration. > > > > > > > In current state it is impossible. > > > > > > > > > > > > > > See also thread for more details: > > > > > > > https://lore.kernel.org/u-boot/20220426181740.o2n7xfg46ytljcdx@pali/t/#u > > > > > > > > > > > > > > Signed-off-by: Pali Rohár <p...@kernel.org> > > > > > > > > > > > > NAK. We are not moving things back in to board config headers under > > > > > > CONFIG namespace. Some other solution is required. > > > > > > > > > > I spend time on this and I do not see any other solution. As explained > > > > > that commit just introduced more issues then what it brought, so it > > > > > was > > > > > step backward, not forward. So please show other solution, if you do > > > > > not > > > > > like this one. > > > > > > > > Anything that I suggested in the previous thread about moving to board > > > > Kconfig files. > > > > > > Kconfig does not support evaluating C macros from C header files. So it > > > would not work. > > > > Document how to derive them using tools like 'printf' when adding more > > boards, which should not be a common case anyhow. > > > > > > Or move it to some other header and out of CONFIG namespace. > > > > > > This is board specific setting, used by drivers and arch code. So it > > > needs to be in some board location, like the config header file. > > > > But all include/config/*.h files are destined to be removed, so they > > cannot live there. Everything in the CONFIG namespace needs to be in > > Kconfig. Nothing outside of CONFIG namespace belongs under > > include/configs/. > > > > > > Or if dtoc (doc/develop/driver-model/of-plat.rst) isn't > > > > sufficient today to pull out the infos to use at build time, expand it > > > > to cover this case as it would be useful for large numbers of other > > > > cases. > > > > > > This would mean to rewrite completely everything about LBC configuration > > > and its peripherals. I really do not have energy nor time for it. > > > > Neither apparently has anyone else for the last far far too long. > > > > > There are issues which needs to be fixed first, then some "code cleanup" > > > and "non-functional" changes could be done. > > > > > > But that your commit c7fad78ec0ee41b72a58bebb61959570eb937ab1 make it > > > impossible to do anything with LBC, neither new development, nor doing > > > bug fixes. So it is in the worst state in which it can be. > > > > How? Derive the correct hex value and put it in. > > > > > That commit has same effect as conservation of the code and putting it > > > into the state to disallow future development in this area. Because > > > everybody who wants to touch it, has to first do what you wrote above. > > > > Yes. The code is sub-standard and needs improvement. > > > > > But this is such giant work which nobody is going to do, just for fixing > > > small bug, which is completely unrelated to that work. And that work is > > > only refactor/code cleanup which does not bring any functional value. > > > Nothing so fancy, that somebody would do in spare time. > > > > > > So I hope that this was not your intension. > > > > My intention is to get the PowerPC code up to modern U-Boot standards. > > Or, to get it removed since there's not enough interest in maintaining > > and updating it. > > > > To re-iterate, I agree that it would be good to construct the values at > > build time using macros. No one likes looking at raw magic values. But > > for an otherwise dead end platform, documenting how these magic values > > are constructed (something under doc/arch/ or doc/board/) for anyone in > > the future doing more work is Good Enough for me. Alternatively, > > re-working things so that instead of being pulled from > > include/configs/board-config.h they come from board/.../something.h is > > Good Enough, so long as they are NOT using the CONFIG prefix. They can > > use CFG_ or just LBC_ or anything else that makes sense. > > Getting back to this. I see 13 more "LBC" CONFIG symbols that need > something done to them. I'm sure most or all of them are in the same > situation as the PRELIM ones in this thread. Have you attempted to move > them out of the CONFIG namespace by chance? If not, I might start > looking soon at where to move them to, rather than migrate to Kconfig. > Thanks.
No, have not looked at this. I was fixing SDHC issues (patches are now on ML).