All of lore.kernel.org
 help / color / mirror / Atom feed
* [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-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
* [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
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.