[Buildroot] So what do we do about all the unmaintained boards?

[Buildroot] So what do we do about all the unmaintained boards?

[Ulf Samuelsson]

VENDOR	BOARD		KERNEL
AMD	Dbu1500		2.6.19.1
ARM	AT91SAM9260	2.6.24					REMOVE?
ARMLTD	Integrator926	2.6.22.9
Atmel	Plenty		All are or will soon be 2.6.28
Hitachi	MS7206SE01	No kernel config
jp	q5		2.4.26/29/32				REMOVE?
KWIKBYTE kb9202		2.6.24
mips	malta		2.6.21.5
Sharp	LNode80		2.4.26					REMOVE?
Soekris	net4521/4801	2.4.29					REMOVE?
Valka	v100sc2		No kernel config
Via	epia-mii	2.6.11.5				REMOVE?
x86	i386		2.6.21.5

The reason for removing the ARM directory, is that it does not make
any sense to do a "generic ARM".

You might as well build an ARMLTD or an Atmel board, without
the fancy stuff.
There is no defconfig and the linux config builds an AT91.




BR
Ulf Samuelsson

[Buildroot] So what do we do about all the unmaintained boards?

[David Anders]

Ulf,

LNODE80 can be removed

thanks
Dave Anders
AML



> VENDOR	BOARD		KERNEL
> AMD	Dbu1500		2.6.19.1
> ARM	AT91SAM9260	2.6.24					REMOVE?
> ARMLTD	Integrator926	2.6.22.9
> Atmel	Plenty		All are or will soon be 2.6.28
> Hitachi	MS7206SE01	No kernel config
> jp	q5		2.4.26/29/32				REMOVE?
> KWIKBYTE kb9202		2.6.24
> mips	malta		2.6.21.5
> Sharp	LNode80		2.4.26					REMOVE?
> Soekris	net4521/4801	2.4.29					REMOVE?
> Valka	v100sc2		No kernel config
> Via	epia-mii	2.6.11.5				REMOVE?
> x86	i386		2.6.21.5
> 
> The reason for removing the ARM directory, is that it does
> not make
> any sense to do a "generic ARM".
> 
> You might as well build an ARMLTD or an Atmel board,
> without
> the fancy stuff.
> There is no defconfig and the linux config builds an AT91.
> 
> 
> 
> 
> BR
> Ulf Samuelsson
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot


      

[Buildroot] So what do we do about all the unmaintained boards?

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 Ulf> VENDOR	BOARD		KERNEL
 Ulf> AMD	Dbu1500		2.6.19.1
 Ulf> ARM	AT91SAM9260	2.6.24					REMOVE?
 Ulf> ARMLTD	Integrator926	2.6.22.9
 Ulf> Atmel	Plenty		All are or will soon be 2.6.28
 Ulf> Hitachi	MS7206SE01	No kernel config
 Ulf> jp	q5		2.4.26/29/32				REMOVE?
 Ulf> KWIKBYTE kb9202		2.6.24
 Ulf> mips	malta		2.6.21.5
 Ulf> Sharp	LNode80		2.4.26					REMOVE?
 Ulf> Soekris	net4521/4801	2.4.29					REMOVE?
 Ulf> Valka	v100sc2		No kernel config
 Ulf> Via	epia-mii	2.6.11.5				REMOVE?
 Ulf> x86	i386		2.6.21.5

 Ulf> The reason for removing the ARM directory, is that it does not make
 Ulf> any sense to do a "generic ARM".

I have been wanting to get rid of (atleast all the really ancient)
boards for some time, I don't remember ever seeing any updates to
them.

Either we mark them as DEPRECATED and remove them after the release,
or we do it now.

-- 
Bye, Peter Korsgaard

[Buildroot] So what do we do about all the unmaintained boards?

[Ulf Samuelsson]

>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> Ulf> VENDOR BOARD KERNEL
> Ulf> AMD Dbu1500 2.6.19.1
> Ulf> ARM AT91SAM9260 2.6.24 REMOVE?
> Ulf> ARMLTD Integrator926 2.6.22.9
> Ulf> Atmel Plenty All are or will soon be 2.6.28
> Ulf> Hitachi MS7206SE01 No kernel config
> Ulf> jp q5 2.4.26/29/32 REMOVE?
> Ulf> KWIKBYTE kb9202 2.6.24
> Ulf> mips malta 2.6.21.5
> Ulf> Sharp LNode80 2.4.26 REMOVE?
> Ulf> Soekris net4521/4801 2.4.29 REMOVE?
> Ulf> Valka v100sc2 No kernel config
> Ulf> Via epia-mii 2.6.11.5 REMOVE?
> Ulf> x86 i386 2.6.21.5
> 
> Ulf> The reason for removing the ARM directory, is that it does not make
> Ulf> any sense to do a "generic ARM".
> 
> I have been wanting to get rid of (atleast all the really ancient)
> boards for some time, I don't remember ever seeing any updates to
> them.
> 
> Either we mark them as DEPRECATED and remove them after the release,
> or we do it now.
> 
> -- 
> Bye, Peter Korsgaard
>

I suggest we remove the boards with 2.4 kernel only today
but we should have one board per architecture we want to support.

There is no PowerPC board support at the moment. 
Can you fix since you seem to be working on this?

The BOARD_NAME, BOARD_PATH really belong
in a target/device/<subdir> directory and not in the <buildroot>/project.

Best Regards
Ulf Samuelsson

[Buildroot] So what do we do about all the unmaintained boards?

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 Ulf> I suggest we remove the boards with 2.4 kernel only today
 Ulf> but we should have one board per architecture we want to support.

 Ulf> There is no PowerPC board support at the moment. Can you fix since you
 Ulf> seem to be working on this?

Why? If the target/generic skeleton and default busybox / uclibc
configs work fine, I don't see much value in adding one.

 Ulf> The BOARD_NAME, BOARD_PATH really belong
 Ulf> in a target/device/<subdir> directory and not in the <buildroot>/project.

Huh? I don't see any references to such variables under project.

-- 
Bye, Peter Korsgaard

[Buildroot] So what do we do about all the unmaintained boards?

[Ulf Samuelsson]

>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>
> Ulf> I suggest we remove the boards with 2.4 kernel only today
> Ulf> but we should have one board per architecture we want to support.
>
> Ulf> There is no PowerPC board support at the moment. Can you fix since 
> you
> Ulf> seem to be working on this?
>
> Why? If the target/generic skeleton and default busybox / uclibc
> configs work fine, I don't see much value in adding one.
>
> Ulf> The BOARD_NAME, BOARD_PATH really belong
> Ulf> in a target/device/<subdir> directory and not in the 
> <buildroot>/project.
>
> Huh? I don't see any references to such variables under project.
>
No, but I think you suggested that if this is to be general thing,
it could be a configuration item under /project.

The way BOARD_NAME is implemented today
is that you select a board and maybe set some options,
and then Kconfig deduces the board name from that
so it is really not something the user inputs.

Therefore I think it belongs in target/device/VENDOR/Config.in and not in 
project.


Best Regards
Ulf Samuelsson


> -- 
> Bye, Peter Korsgaard
> 

[Buildroot] So what do we do about all the unmaintained boards?

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 >> Huh? I don't see any references to such variables under project.
 >> 
 Ulf> No, but I think you suggested that if this is to be general thing,
 Ulf> it could be a configuration item under /project.

 Ulf> The way BOARD_NAME is implemented today
 Ulf> is that you select a board and maybe set some options,
 Ulf> and then Kconfig deduces the board name from that
 Ulf> so it is really not something the user inputs.

So what's the BR2_BOARD_NAME thing for? Having it like you just
described is no good for people building stuff without having one of
those boards selected as they then cannot set BOARD_NAME.

Individual boards may want to override the setting, but it should
still be available.

-- 
Bye, Peter Korsgaard

[Buildroot] So what do we do about all the unmaintained boards?

[Ulf Samuelsson]

tor 2009-01-29 klockan 17:47 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
>  >> Huh? I don't see any references to such variables under project.
>  >> 
>  Ulf> No, but I think you suggested that if this is to be general thing,
>  Ulf> it could be a configuration item under /project.
> 
>  Ulf> The way BOARD_NAME is implemented today
>  Ulf> is that you select a board and maybe set some options,
>  Ulf> and then Kconfig deduces the board name from that
>  Ulf> so it is really not something the user inputs.
> 
> So what's the BR2_BOARD_NAME thing for? Having it like you just
> described is no good for people building stuff without having one of
> those boards selected as they then cannot set BOARD_NAME.
> 

?It is also used to define which directory
contains other configuration items.

BR2_BOARD_PATH="target/device/Atmel/$(BOARD_NAME)

As you see, there is only a small number of acceptable values.

It is also used for U-Boot.
make $(BOARD_NAME)_config

so you do not have to specify manually the boardname.

For the SAM9263 you can build several u-boot targets like

?at91sam9263ek_dataflash_cs0
?at91sam9263ek_dataflash_cs1
?at91sam9263ek_nandflash

and this list will grow as support for different bootoptions
becomes more advanced.

It is too much to expect that people should remember
the exact name of such configurations.


> Individual boards may want to override the setting, but it should
> still be available.
> 


BR
Ulf Samuelsson