[U-Boot] Refactoring of U-Boot directory structure
Hi.
In U-Boot, the directory structure under arch/ is like this arch/${ARCH}/cpu/${CPU}/${SOC}
Exception: - ${CPU} is missing for some architectures such as blackfin, sandbox, etc. - There are many boards without ${SOC}
My question is, ${SOC} should always depend on ${CPU} ?
I think it is reasonable to migrate to the structure like this:
arch/${ARCH}/cpu/${CPU} /mach-${foo} /mach-${bar}
I think arch/${ARCH}/cpu/${CPU}/${SOC} structure have given us a lot of pain.
The problems I want to solve are:
[1] Do not split the similar SoC family to various directories
at91 SoC directory exists under arm920t, arm926ejs, armv7 directory.
./arch/arm/cpu/arm920t/at91 ./arch/arm/cpu/arm926ejs/at91 ./arch/arm/cpu/armv7/at91
It looks reasonable to collect at91 sources into a single place, arch/arm/mach-at91
[2] Collect C/ASM sources and headers into a single place
Now SoC-specific sources are under ./arch/${ARCH}/cpu/${CPU}/${SOC}/
But headers are ./arch/${ARCH}/include/asm/arch-${SOC}/
In the new structure, ./arch/arm/mach-${SOC}/ : C/ASM files ./arch/arm/mach-${SOC}/include/ : Header files
[3] Do not create a symbolic link to header dicrectory
mkconfig creates a symbolic link to arch/asm/include/asm/arch-${SOC}
I dislike creating a symbolic link by configuration and remove it by mrproper.
Linux Kernel did that long time ago, but they did away with it.
[4] Stop Tegra
Tegra uses different CPU for SPL and Normal U-boot. That's why Tegra directories are sprinkled under arch/arm/:
arch/arm/cpu/arm720t/tegra-common/ arch/arm/cpu/arm720t/tegra20/ arch/arm/cpu/arm720t/tegra30/ arch/arm/cpu/arm720t/tegra114/ arch/arm/cpu/arm720t/tegra124/ arch/arm/cpu/armv7/tegra-common/ arch/arm/cpu/armv7/tegra20/ arch/arm/cpu/armv7/tegra30/ arch/arm/cpu/armv7/tegra114/ arch/arm/cpu/armv7/tegra124/ arch/arm/include/asm/arch-tegra/ arch/asm/include/asm/arch-tegra20/ arch/asm/include/asm/arch-tegra30/ arch/asm/include/asm/arch-tegra114/ arch/asm/include/asm/arch-tegra124/
They can be refactored
arch/arm/mach-tegra/ : tegra common part arch/arm/mach-tegra/tegra20/ : tegra20-specific arch/arm/mach-tegra/tegra30/ : tegra30-specific arch/arm/mach-tegra/tegra114/ : tegra114-specific arch/arm/mach-tegra/tegra124/ : tegra124-specific
or maybe
arch/arm/plat-tegra/ : tegra common part arch/arm/mach-tegra20/ : tegra20-specific arch/arm/mach-tegra30/ : tegra30-specific arch/arm/mach-tegra114/ : tegra114-specific arch/arm/mach-tegra124/ : tegra124-specific
Your comments are welcome!
Best Regards Masahiro Yamada
Dear Masahiro,
In message 20140612131050.963A.AA925319@jp.panasonic.com you wrote:
[1] Do not split the similar SoC family to various directories
at91 SoC directory exists under arm920t, arm926ejs, armv7 directory.
To me this actually makes sense, as they are using different CPU cores (ARMv4t vs. ARMv5te vs. ARMv7).
./arch/arm/cpu/arm920t/at91 ./arch/arm/cpu/arm926ejs/at91 ./arch/arm/cpu/armv7/at91
It looks reasonable to collect at91 sources into a single place, arch/arm/mach-at91
Did you look at the code? Files like lowlevel_init.S, reset.c or timer.c look pretty much specific to the respective architecture. What would be the benefit of mixing all this different stuff in a single directory?
That's why Tegra directories are sprinkled under arch/arm/:
arch/arm/cpu/arm720t/tegra-common/ arch/arm/cpu/arm720t/tegra20/ arch/arm/cpu/arm720t/tegra30/ arch/arm/cpu/arm720t/tegra114/ arch/arm/cpu/arm720t/tegra124/ arch/arm/cpu/armv7/tegra-common/ arch/arm/cpu/armv7/tegra20/ arch/arm/cpu/armv7/tegra30/ arch/arm/cpu/armv7/tegra114/ arch/arm/cpu/armv7/tegra124/ arch/arm/include/asm/arch-tegra/ arch/asm/include/asm/arch-tegra20/ arch/asm/include/asm/arch-tegra30/ arch/asm/include/asm/arch-tegra114/ arch/asm/include/asm/arch-tegra124/
They can be refactored
arch/arm/mach-tegra/ : tegra common part arch/arm/mach-tegra/tegra20/ : tegra20-specific arch/arm/mach-tegra/tegra30/ : tegra30-specific arch/arm/mach-tegra/tegra114/ : tegra114-specific arch/arm/mach-tegra/tegra124/ : tegra124-specific
Again, we have different CPU cores here, and thus pretty much different code - what would be the benefit of mixing unrelated code in a single directory?
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Thu, 12 Jun 2014 06:41:45 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Masahiro,
In message 20140612131050.963A.AA925319@jp.panasonic.com you wrote:
[1] Do not split the similar SoC family to various directories
at91 SoC directory exists under arm920t, arm926ejs, armv7 directory.
To me this actually makes sense, as they are using different CPU cores (ARMv4t vs. ARMv5te vs. ARMv7).
./arch/arm/cpu/arm920t/at91 ./arch/arm/cpu/arm926ejs/at91 ./arch/arm/cpu/armv7/at91
It looks reasonable to collect at91 sources into a single place, arch/arm/mach-at91
Did you look at the code? Files like lowlevel_init.S, reset.c or timer.c look pretty much specific to the respective architecture. What would be the benefit of mixing all this different stuff in a single directory?
No. I am discussing from the generic view.
In the current structure, there is no place which at91-common part should go to.
Splitting code into various directories loses the motivation of consolidating the common part even if it exists.
(Again, just in case, this is generalities. I am not familiar with the at91-specific implementation.)
That's why Tegra directories are sprinkled under arch/arm/:
arch/arm/cpu/arm720t/tegra-common/ arch/arm/cpu/arm720t/tegra20/ arch/arm/cpu/arm720t/tegra30/ arch/arm/cpu/arm720t/tegra114/ arch/arm/cpu/arm720t/tegra124/ arch/arm/cpu/armv7/tegra-common/ arch/arm/cpu/armv7/tegra20/ arch/arm/cpu/armv7/tegra30/ arch/arm/cpu/armv7/tegra114/ arch/arm/cpu/armv7/tegra124/ arch/arm/include/asm/arch-tegra/ arch/asm/include/asm/arch-tegra20/ arch/asm/include/asm/arch-tegra30/ arch/asm/include/asm/arch-tegra114/ arch/asm/include/asm/arch-tegra124/
They can be refactored
arch/arm/mach-tegra/ : tegra common part arch/arm/mach-tegra/tegra20/ : tegra20-specific arch/arm/mach-tegra/tegra30/ : tegra30-specific arch/arm/mach-tegra/tegra114/ : tegra114-specific arch/arm/mach-tegra/tegra124/ : tegra124-specific
Again, we have different CPU cores here, and thus pretty much different code - what would be the benefit of mixing unrelated code in a single directory?
At lease, they are developed by the same LSI vendor. And the code is maintained by the same person:
Besides, arch/arm/cpu/armv7/tegra30/ arch/arm/cpu/armv7/tegra114/ arch/arm/cpu/armv7/tegra124/
are empty. These directories exist just to meet the requirement of arch/${ARCH}/cpu/${CPU}/${SOC} structure.
Without those dummy directories, build fails.
Best Regards Masahiro Yamada
Hi all,
On 06/12/2014 08:32 AM, Masahiro Yamada wrote:
On Thu, 12 Jun 2014 06:41:45 +0200 Wolfgang Denk wd@denx.de wrote:
In message 20140612131050.963A.AA925319@jp.panasonic.com you wrote:
[1] Do not split the similar SoC family to various directories
at91 SoC directory exists under arm920t, arm926ejs, armv7 directory.
To me this actually makes sense, as they are using different CPU cores (ARMv4t vs. ARMv5te vs. ARMv7).
./arch/arm/cpu/arm920t/at91 ./arch/arm/cpu/arm926ejs/at91 ./arch/arm/cpu/armv7/at91
It looks reasonable to collect at91 sources into a single place, arch/arm/mach-at91
I thought about that before when introducing at91-common.
Did you look at the code? Files like lowlevel_init.S, reset.c or timer.c look pretty much specific to the respective architecture. What would be the benefit of mixing all this different stuff in a single directory?
No. I am discussing from the generic view.
In the current structure, there is no place which at91-common part should go to.
Splitting code into various directories loses the motivation of consolidating the common part even if it exists.
That's true. Currently there are some old files which are almost the same in arch/arm/cpu/*/at91 Especially the arm920t and arm926ejs files are mostly the same. For example the clock.c:
---8<--- abiessmann@punisher % diff -Nrupa arch/arm/cpu/arm920t/at91/clock.c arch/arm/cpu/arm926ejs/at91/clock.c | diffstat clock.c | 38 +++++++++++++++++++++++++++++++++++--- 1 file changed, 35 insertions(+), 3 deletions(-) abiessmann@punisher % cat arch/arm/cpu/arm920t/at91/clock.c | wc -l 157 abiessmann@punisher % cat arch/arm/cpu/arm926ejs/at91/clock.c | wc -l 189 --->8---
The differences are just features of the newer IP revision in SoC, so that could be consolidated into one file.
lowlevel_init.S is another thing. There should be something done before. We have started to do clock and RAM initialization in C-code for armv7 targets (sama5) and some arm926ejs targets (g45). This could also be done for the ancient (but still available) devices like sam926x, maybe also for the really prehistoric rm9200.
So I think it is doable to consolidate the directory structure. It would even be really useful for the generic code. But we need to plan this step before thoroughly. Especially required adoptions like rework of lowlevel_init.S should be done before.
Best regards
Andreas Bießmann
On 06/11/2014 10:10 PM, Masahiro Yamada wrote: ...
Tegra uses different CPU for SPL and Normal U-boot. That's why Tegra directories are sprinkled under arch/arm/:
arch/arm/cpu/arm720t/tegra-common/ arch/arm/cpu/arm720t/tegra20/ arch/arm/cpu/arm720t/tegra30/ arch/arm/cpu/arm720t/tegra114/ arch/arm/cpu/arm720t/tegra124/ arch/arm/cpu/armv7/tegra-common/ arch/arm/cpu/armv7/tegra20/ arch/arm/cpu/armv7/tegra30/ arch/arm/cpu/armv7/tegra114/ arch/arm/cpu/armv7/tegra124/ arch/arm/include/asm/arch-tegra/ arch/asm/include/asm/arch-tegra20/ arch/asm/include/asm/arch-tegra30/ arch/asm/include/asm/arch-tegra114/ arch/asm/include/asm/arch-tegra124/
This is a deliberate split so that we can control the code/data size of the arm720t (SPL) parts of the code.
They can be refactored
arch/arm/mach-tegra/ : tegra common part arch/arm/mach-tegra/tegra20/ : tegra20-specific arch/arm/mach-tegra/tegra30/ : tegra30-specific arch/arm/mach-tegra/tegra114/ : tegra114-specific arch/arm/mach-tegra/tegra124/ : tegra124-specific
or maybe
arch/arm/plat-tegra/ : tegra common part arch/arm/mach-tegra20/ : tegra20-specific arch/arm/mach-tegra30/ : tegra30-specific arch/arm/mach-tegra114/ : tegra114-specific arch/arm/mach-tegra124/ : tegra124-specific
If we refactor into that structure, the SPL/non-SPL separation will be much less clear.
Hi Stephen,
On Thu, 12 Jun 2014 09:16:14 -0600 Stephen Warren swarren@wwwdotorg.org wrote:
On 06/11/2014 10:10 PM, Masahiro Yamada wrote: ...
Tegra uses different CPU for SPL and Normal U-boot. That's why Tegra directories are sprinkled under arch/arm/:
arch/arm/cpu/arm720t/tegra-common/ arch/arm/cpu/arm720t/tegra20/ arch/arm/cpu/arm720t/tegra30/ arch/arm/cpu/arm720t/tegra114/ arch/arm/cpu/arm720t/tegra124/ arch/arm/cpu/armv7/tegra-common/ arch/arm/cpu/armv7/tegra20/ arch/arm/cpu/armv7/tegra30/ arch/arm/cpu/armv7/tegra114/ arch/arm/cpu/armv7/tegra124/ arch/arm/include/asm/arch-tegra/ arch/asm/include/asm/arch-tegra20/ arch/asm/include/asm/arch-tegra30/ arch/asm/include/asm/arch-tegra114/ arch/asm/include/asm/arch-tegra124/
This is a deliberate split so that we can control the code/data size of the arm720t (SPL) parts of the code.
They can be refactored
arch/arm/mach-tegra/ : tegra common part arch/arm/mach-tegra/tegra20/ : tegra20-specific arch/arm/mach-tegra/tegra30/ : tegra30-specific arch/arm/mach-tegra/tegra114/ : tegra114-specific arch/arm/mach-tegra/tegra124/ : tegra124-specific
or maybe
arch/arm/plat-tegra/ : tegra common part arch/arm/mach-tegra20/ : tegra20-specific arch/arm/mach-tegra30/ : tegra30-specific arch/arm/mach-tegra114/ : tegra114-specific arch/arm/mach-tegra124/ : tegra124-specific
If we refactor into that structure, the SPL/non-SPL separation will be much less clear.
In that case, you can create a subdirectory under mach-tegra/ to separate SPL code from the others.
Best Regards Masahiro Yamada
Hi Stephen,
On 13 June 2014 08:18, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi Stephen,
On Thu, 12 Jun 2014 09:16:14 -0600 Stephen Warren swarren@wwwdotorg.org wrote:
On 06/11/2014 10:10 PM, Masahiro Yamada wrote: ...
Tegra uses different CPU for SPL and Normal U-boot. That's why Tegra directories are sprinkled under arch/arm/:
arch/arm/cpu/arm720t/tegra-common/ arch/arm/cpu/arm720t/tegra20/ arch/arm/cpu/arm720t/tegra30/ arch/arm/cpu/arm720t/tegra114/ arch/arm/cpu/arm720t/tegra124/ arch/arm/cpu/armv7/tegra-common/ arch/arm/cpu/armv7/tegra20/ arch/arm/cpu/armv7/tegra30/ arch/arm/cpu/armv7/tegra114/ arch/arm/cpu/armv7/tegra124/ arch/arm/include/asm/arch-tegra/ arch/asm/include/asm/arch-tegra20/ arch/asm/include/asm/arch-tegra30/ arch/asm/include/asm/arch-tegra114/ arch/asm/include/asm/arch-tegra124/
This is a deliberate split so that we can control the code/data size of the arm720t (SPL) parts of the code.
They can be refactored
arch/arm/mach-tegra/ : tegra common part arch/arm/mach-tegra/tegra20/ : tegra20-specific arch/arm/mach-tegra/tegra30/ : tegra30-specific arch/arm/mach-tegra/tegra114/ : tegra114-specific arch/arm/mach-tegra/tegra124/ : tegra124-specific
or maybe
arch/arm/plat-tegra/ : tegra common part arch/arm/mach-tegra20/ : tegra20-specific arch/arm/mach-tegra30/ : tegra30-specific arch/arm/mach-tegra114/ : tegra114-specific arch/arm/mach-tegra124/ : tegra124-specific
If we refactor into that structure, the SPL/non-SPL separation will be much less clear.
In that case, you can create a subdirectory under mach-tegra/ to separate SPL code from the others.
Does Masahiro's proposed approach work for you? The second one seems good to me - I quite like the plat-tegra idea for completely common code, and the flatter directory structure.
Also if Tegra starts supporting an ARMv7/8 CPU for start-up, then a spl/ subdirectory would be needed anyway, to separate out the code.
Regards, Simon
On 07/27/2014 09:31 PM, Simon Glass wrote:
Hi Stephen,
On 13 June 2014 08:18, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi Stephen,
On Thu, 12 Jun 2014 09:16:14 -0600 Stephen Warren swarren@wwwdotorg.org wrote:
On 06/11/2014 10:10 PM, Masahiro Yamada wrote: ...
Tegra uses different CPU for SPL and Normal U-boot. That's why Tegra directories are sprinkled under arch/arm/:
arch/arm/cpu/arm720t/tegra-common/ arch/arm/cpu/arm720t/tegra20/ arch/arm/cpu/arm720t/tegra30/ arch/arm/cpu/arm720t/tegra114/ arch/arm/cpu/arm720t/tegra124/ arch/arm/cpu/armv7/tegra-common/ arch/arm/cpu/armv7/tegra20/ arch/arm/cpu/armv7/tegra30/ arch/arm/cpu/armv7/tegra114/ arch/arm/cpu/armv7/tegra124/ arch/arm/include/asm/arch-tegra/ arch/asm/include/asm/arch-tegra20/ arch/asm/include/asm/arch-tegra30/ arch/asm/include/asm/arch-tegra114/ arch/asm/include/asm/arch-tegra124/
This is a deliberate split so that we can control the code/data size of the arm720t (SPL) parts of the code.
They can be refactored
arch/arm/mach-tegra/ : tegra common part arch/arm/mach-tegra/tegra20/ : tegra20-specific arch/arm/mach-tegra/tegra30/ : tegra30-specific arch/arm/mach-tegra/tegra114/ : tegra114-specific arch/arm/mach-tegra/tegra124/ : tegra124-specific
or maybe
arch/arm/plat-tegra/ : tegra common part arch/arm/mach-tegra20/ : tegra20-specific arch/arm/mach-tegra30/ : tegra30-specific arch/arm/mach-tegra114/ : tegra114-specific arch/arm/mach-tegra124/ : tegra124-specific
If we refactor into that structure, the SPL/non-SPL separation will be much less clear.
In that case, you can create a subdirectory under mach-tegra/ to separate SPL code from the others.
Does Masahiro's proposed approach work for you? The second one seems good to me - I quite like the plat-tegra idea for completely common code, and the flatter directory structure.
Also if Tegra starts supporting an ARMv7/8 CPU for start-up, then a spl/ subdirectory would be needed anyway, to separate out the code.
I guess I'd be fine with something like:
arch/arm/mach-tegra/*.c arch/arm/mach-tegra/spl/*.c
and if needed an SoC-specific directory under each:
arch/arm/mach-tegra/*.c arch/arm/mach-tegra/tegra20/*.c arch/arm/mach-tegra/tegra30/*.c ... arch/arm/mach-tegra/spl/*.c arch/arm/mach-tegra/spl/tegra20/*.c arch/arm/mach-tegra/spl/tegra30/*.c ...
I don't think a completely flat directory structure would work, since there are probably some alternative implementations of files/functions for different SoCs and/or SPL-vs-non-SPL.
Hi Masahiro,
On 12 June 2014 05:10, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi.
In U-Boot, the directory structure under arch/ is like this arch/${ARCH}/cpu/${CPU}/${SOC}
Exception: - ${CPU} is missing for some architectures such as blackfin, sandbox, etc. - There are many boards without ${SOC}
My question is, ${SOC} should always depend on ${CPU} ?
I think it is reasonable to migrate to the structure like this:
arch/${ARCH}/cpu/${CPU} /mach-${foo} /mach-${bar}I think arch/${ARCH}/cpu/${CPU}/${SOC} structure have given us a lot of pain.
The problems I want to solve are:
[1] Do not split the similar SoC family to various directories
at91 SoC directory exists under arm920t, arm926ejs, armv7 directory.
./arch/arm/cpu/arm920t/at91 ./arch/arm/cpu/arm926ejs/at91 ./arch/arm/cpu/armv7/at91
It looks reasonable to collect at91 sources into a single place, arch/arm/mach-at91
This does make it clear that the chips are in a single family. We can have different files for the chip-specific stuff such as low-level code. But this approach makes it easier to use common code I think.
[2] Collect C/ASM sources and headers into a single place
Now SoC-specific sources are under ./arch/${ARCH}/cpu/${CPU}/${SOC}/
But headers are ./arch/${ARCH}/include/asm/arch-${SOC}/
In the new structure, ./arch/arm/mach-${SOC}/ : C/ASM files ./arch/arm/mach-${SOC}/include/ : Header files
This seems better to me.
[3] Do not create a symbolic link to header dicrectory
mkconfig creates a symbolic link to arch/asm/include/asm/arch-${SOC}
I dislike creating a symbolic link by configuration and remove it by mrproper.
Linux Kernel did that long time ago, but they did away with it.
OK
Regards, Simon
participants (5)
-
Andreas Bießmann -
Masahiro Yamada -
Simon Glass -
Stephen Warren -
Wolfgang Denk