* [U-Boot] Refactoring of U-Boot directory structure
@ 2014-06-12 4:10 Masahiro Yamada
2014-06-12 4:41 ` Wolfgang Denk
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Masahiro Yamada @ 2014-06-12 4:10 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 9+ messages in thread* [U-Boot] Refactoring of U-Boot directory structure
2014-06-12 4:10 [U-Boot] Refactoring of U-Boot directory structure Masahiro Yamada
@ 2014-06-12 4:41 ` Wolfgang Denk
2014-06-12 6:32 ` Masahiro Yamada
2014-06-12 15:16 ` Stephen Warren
2014-07-28 3:26 ` Simon Glass
2 siblings, 1 reply; 9+ messages in thread
From: Wolfgang Denk @ 2014-06-12 4:41 UTC (permalink / raw)
To: u-boot
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
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Boykottiert Microsoft - Kauft Eure Fenster bei OBI!
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Refactoring of U-Boot directory structure
2014-06-12 4:41 ` Wolfgang Denk
@ 2014-06-12 6:32 ` Masahiro Yamada
2014-06-12 7:46 ` Andreas Bießmann
0 siblings, 1 reply; 9+ messages in thread
From: Masahiro Yamada @ 2014-06-12 6:32 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 9+ messages in thread* [U-Boot] Refactoring of U-Boot directory structure
2014-06-12 6:32 ` Masahiro Yamada
@ 2014-06-12 7:46 ` Andreas Bießmann
0 siblings, 0 replies; 9+ messages in thread
From: Andreas Bießmann @ 2014-06-12 7:46 UTC (permalink / raw)
To: u-boot
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 at 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 at 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Refactoring of U-Boot directory structure
2014-06-12 4:10 [U-Boot] Refactoring of U-Boot directory structure Masahiro Yamada
2014-06-12 4:41 ` Wolfgang Denk
@ 2014-06-12 15:16 ` Stephen Warren
2014-06-13 7:18 ` Masahiro Yamada
2014-07-28 3:26 ` Simon Glass
2 siblings, 1 reply; 9+ messages in thread
From: Stephen Warren @ 2014-06-12 15:16 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Refactoring of U-Boot directory structure
2014-06-12 15:16 ` Stephen Warren
@ 2014-06-13 7:18 ` Masahiro Yamada
2014-07-28 3:31 ` Simon Glass
0 siblings, 1 reply; 9+ messages in thread
From: Masahiro Yamada @ 2014-06-13 7:18 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Refactoring of U-Boot directory structure
2014-06-13 7:18 ` Masahiro Yamada
@ 2014-07-28 3:31 ` Simon Glass
2014-07-28 17:24 ` Stephen Warren
0 siblings, 1 reply; 9+ messages in thread
From: Simon Glass @ 2014-07-28 3:31 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Refactoring of U-Boot directory structure
2014-07-28 3:31 ` Simon Glass
@ 2014-07-28 17:24 ` Stephen Warren
0 siblings, 0 replies; 9+ messages in thread
From: Stephen Warren @ 2014-07-28 17:24 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Refactoring of U-Boot directory structure
2014-06-12 4:10 [U-Boot] Refactoring of U-Boot directory structure Masahiro Yamada
2014-06-12 4:41 ` Wolfgang Denk
2014-06-12 15:16 ` Stephen Warren
@ 2014-07-28 3:26 ` Simon Glass
2 siblings, 0 replies; 9+ messages in thread
From: Simon Glass @ 2014-07-28 3:26 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-07-28 17:24 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-12 4:10 [U-Boot] Refactoring of U-Boot directory structure Masahiro Yamada
2014-06-12 4:41 ` Wolfgang Denk
2014-06-12 6:32 ` Masahiro Yamada
2014-06-12 7:46 ` Andreas Bießmann
2014-06-12 15:16 ` Stephen Warren
2014-06-13 7:18 ` Masahiro Yamada
2014-07-28 3:31 ` Simon Glass
2014-07-28 17:24 ` Stephen Warren
2014-07-28 3:26 ` Simon Glass
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.