Skip to content

Add disk support to orion5x and edminiv2

Rogan Dawes u-boot 3 versions New

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v7 Latest posting 3/30 of 4 patches 0 repliesNew
  2. v7 posting 2/30 of 4 patches 0 repliesSuperseded
  3. v7 posting 1/30 of 4 patches 0 repliesSuperseded

Patches in v7 posting 3/3 No applies recorded yet

None of the 4 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v7 yet.

Read the v7 thread

Cover letter [U-Boot] [PATCH V7 0/4] Add disk support to orion5x and edminiv2
Quoted 22 lines · Albert ARIBAUD

Le 05/08/2010 16:28, Rogan Dawes a ?crit :

Quoted 11 lines · Albert ARIBAUD
Quoted 3 lines

Rogan, what other code do you think you'd be duplicating?

Amicalement,

In truth, I was really thinking only of the config files, not really the code per se.

I suppose that there is not really that much else that really is common.

Rogan

As for the configs, some u-boot boards do commonalize, see for instance include/configs/spear*.h. That makes sense because there is a board family, with a common HW design and common external components.

For instance, the recently submitted patch for the kirkwood-based openrd family could probably commonalize since most of the OpenRD Base and OpenRD Client HW design is shared, and I assume Ultimate reuses it a lot too.

Quoted 7 lines

In our case, the boards are from different manufacturers, so commonalization seems less obvious to me, except for MV88E1116 if both boards have it, but the config for it is a single define (CONFIG_RESET_PHY_R) which makes putting it in a common config header overkill (but commonalization of reset code would make sense though).

Amicalement,

The DNS323 uses the Marvell 88E1111, but it is working with the same config as yours, so I suppose they are compatible.

I was really thinking in terms of all the peripheral configs, the SATA, USB, network, etc, which *should* be the same, since they are all based on the same SoC.

While your edmini only uses a single SATA port, that could easily be overcome by defining addresses for both in the board config, and just #undef'ing it for those that do not use the second port. (It seems more descriptive to have both ports defined in the same place, and then say that the edmini doesn't use the second one).

I might just be being lazy, of course :-)

Rogan
P.S. Is there any attention being paid to the ARM defconfig cleanup going on in the kernel, and thoughts of copying their approach?