u-boot.git/include/configs/mp2usb.h, branch master Unnamed repository; edit this file 'description' to name the repository. mp2usb: remove board support 2011-04-11T20:44:02+00:00 Eric BĂ©nard eric@eukrea.com 2011-01-25T22:31:23+00:00 ee986e2a7d1fd38568e2e5f83563b7bc4f607963 this board was cancelled long time ago so remove it as it won't be maintained anymore Signed-off-by: Eric Bénard <eric@eukrea.com> 
this board was cancelled long time ago so remove it as it won't
be maintained anymore

Signed-off-by: Eric Bénard <eric@eukrea.com>
Drop support for CONFIG_SKIP_RELOCATE_UBOOT 2010-10-29T19:40:08+00:00 Wolfgang Denk wd@denx.de 2010-10-28T18:52:49+00:00 e03f31697478e9edd523f34b1ed54b6ff2cb7242 For ARM systems, before ELF relocation was introduced, CONFIG_SKIP_RELOCATE_UBOOT coul be used to prevent *COPYING* the U-Boot image from whereever it was loaded to it's link address (CONFIG_SYS_TEXT_BASE). The name was badly chosen, as no relocation was performed at all, it was just a memcpy(). With ELF relocation, this does not work like that any more, and related boards need to be fixed anyway. So don't keep this relict any longer. Signed-off-by: Wolfgang Denk <wd@denx.de> Tested-by: Heiko Schocher <hs@denx.de> Tested-by: Reinhard Meyer <u-boot@emk-elektronik.de> 
For ARM systems, before ELF relocation was introduced,
CONFIG_SKIP_RELOCATE_UBOOT coul be used to prevent *COPYING* the
U-Boot image from whereever it was loaded to it's link address
(CONFIG_SYS_TEXT_BASE).  The name was badly chosen, as no relocation
was performed at all, it was just a memcpy().

With ELF relocation, this does not work like that any more, and
related boards need to be fixed anyway.  So don't keep this relict any
longer.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Tested-by: Heiko Schocher <hs@denx.de>
Tested-by: Reinhard Meyer <u-boot@emk-elektronik.de>
Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value 2010-10-26T19:05:30+00:00 Wolfgang Denk wd@denx.de 2010-10-26T12:34:52+00:00 25ddd1fb0a2281b182529afbc8fda5de2dc16d96 CONFIG_SYS_GBL_DATA_SIZE has always been just a bad workarond for not being able to use "sizeof(struct global_data)" in assembler files. Recent experience has shown that manual synchronization is not reliable enough. This patch renames CONFIG_SYS_GBL_DATA_SIZE into GENERATED_GBL_DATA_SIZE which gets automatically generated by the asm-offsets tool. In the result, all definitions of this value can be deleted from the board config files. We have to make sure that all files that reference such data include the new <asm-offsets.h> file. No other changes have been done yet, but it is obvious that similar changes / simplifications can be done for other, related macro definitions as well. Signed-off-by: Wolfgang Denk <wd@denx.de> Acked-by: Kumar Gala <galak@kernel.crashing.org> 
CONFIG_SYS_GBL_DATA_SIZE has always been just a bad workarond for not
being able to use "sizeof(struct global_data)" in assembler files.
Recent experience has shown that manual synchronization is not
reliable enough.  This patch renames CONFIG_SYS_GBL_DATA_SIZE into
GENERATED_GBL_DATA_SIZE which gets automatically generated by the
asm-offsets tool.  In the result, all definitions of this value can be
deleted from the board config files.  We have to make sure that all
files that reference such data include the new <asm-offsets.h> file.

No other changes have been done yet, but it is obvious that similar
changes / simplifications can be done for other, related macro
definitions as well.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
add new CONFIG_AT91_LEGACY 2010-02-12T18:31:54+00:00 Jens Scharsig js_at_ng@scharsoft.de 2010-02-03T21:45:42+00:00 425de62d40f84524b90e776b141b060cd438a9fe * add's the new temporary CONFIG_AT91_LEGACY to all board configs This will need for backward compatiblity, while change the SoC access to c structures. If CONFIG_AT91_LEGACY is defined, the deprecated SoC is used. Signed-off-by: Jens Scharsig <js_at_ng@scharsoft.de> 
* add's the new temporary CONFIG_AT91_LEGACY to all board configs
 This will need for backward compatiblity, while change the SoC access
 to c structures. If CONFIG_AT91_LEGACY is defined, the deprecated
 SoC is used.

Signed-off-by: Jens Scharsig <js_at_ng@scharsoft.de>
new at91_emac network driver (NET_MULTI api) 2010-02-01T06:37:12+00:00 Jens Scharsig js_at_ng@scharsoft.de 2010-01-23T11:03:45+00:00 c041e9d212162f6c85cd3b6a40ad6ba9d9292451 * add's at91_emac (AT91RM9200) network driver (NET_MULTI api) * enable driver with CONFIG_DRIVER_AT91EMAC * generic PHY initialization * modify AT91RM9200 boards to use NET_MULTI driver * the drivers has been tested with LXT971 Phy and DM9161 Phy at MII and RMII interface Signed-off-by: Jens Scharsig <js_at_ng@scharsoft.de> Signed-off-by: Ben Warren <biggerbadderben@gmail.com> 
* add's at91_emac (AT91RM9200) network driver (NET_MULTI api)
* enable driver with CONFIG_DRIVER_AT91EMAC
* generic PHY initialization
* modify AT91RM9200 boards to use NET_MULTI driver
* the drivers has been tested with LXT971 Phy and DM9161 Phy at
  MII and RMII interface

Signed-off-by: Jens Scharsig <js_at_ng@scharsoft.de>
Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
rm9200 lowevel_init: don't touch reserved/readonly registers 2009-08-03T07:26:26+00:00 David Brownell david-b@pacbell.net 2009-07-17T01:40:55+00:00 06bffc6ea52d4b390843d295d438b2037d12e5fd For some reason the AT91rm9200 lowlevel init writes to a bunch of reserved or read-only addresses. All the boards seem to define the value-to-be-written values as zero ... but they shouldn't actually be writing *anything* there. No documented erratum justifies these accesses. It looks like maybe some pre-release BDI-2000 setup code has been carried along by cargo cult programming since at least late 2004 (per GIT history). Here's a patch disabling what seems to be bogosity. Tested on a csb337; there were no behavioral changes. Signed-off-by: David Brownell <david-b@pacbell.net> on RM9200ek Tested-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> 
For some reason the AT91rm9200 lowlevel init writes to a bunch of
reserved or read-only addresses.  All the boards seem to define the
value-to-be-written values as zero ... but they shouldn't actually
be writing *anything* there.

No documented erratum justifies these accesses.  It looks like maybe
some pre-release BDI-2000 setup code has been carried along by cargo
cult programming since at least late 2004 (per GIT history).

Here's a patch disabling what seems to be bogosity.  Tested on a
csb337; there were no behavioral changes.

Signed-off-by: David Brownell <david-b@pacbell.net>

on RM9200ek
Tested-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
stdio/device: rework function naming convention 2009-07-17T22:27:46+00:00 Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com 2009-05-16T10:14:54+00:00 52cb4d4fb3487313f5a72ea740f527a4aefaa365 So far the console API uses the following naming convention: ======Extract====== typedef struct device_t; int device_register (device_t * dev); int devices_init (void); int device_deregister(char *devname); struct list_head* device_get_list(void); device_t* device_get_by_name(char* name); device_t* device_clone(device_t *dev); ======= which is too generic and confusing. Instead of using device_XX and device_t we change this into stdio_XX and stdio_dev This will also allow to add later a generic device mechanism in order to have support for multiple devices and driver instances. Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Edited commit message. Signed-off-by: Wolfgang Denk <wd@denx.de> 
So far the console API uses the following naming convention:

	======Extract======
	typedef struct device_t;

	int	device_register (device_t * dev);
	int	devices_init (void);
	int	device_deregister(char *devname);
	struct list_head* device_get_list(void);
	device_t* device_get_by_name(char* name);
	device_t* device_clone(device_t *dev);
	=======

which is too generic and confusing.

Instead of using device_XX and device_t we change this
into stdio_XX and stdio_dev

This will also allow to add later a generic device mechanism in order
to have support for multiple devices and driver instances.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

Edited commit message.

Signed-off-by: Wolfgang Denk <wd@denx.de>
at91rm9200: move serial driver to drivers/serial 2009-04-04T18:42:20+00:00 Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com 2009-03-27T22:26:43+00:00 beebd851cdbc9dd070bcdfec1fd8f17e3cc91bc0 add CONFIG_AT91RM9200_USART to activate the driver Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> 
add CONFIG_AT91RM9200_USART to activate the driver

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Add "source" command; prepare removal of "autoscr" command 2009-04-03T20:01:42+00:00 Wolfgang Denk wd@denx.de 2009-04-01T21:34:12+00:00 74de7aefd79690bae8cf5a5120f5962d444be089 According to the doc/feature-removal-schedule.txt, the "autoscr" command will be replaced by the "source" command in approximately 6 months from now. This patch prepares this change and starts a 6 month transition period as follows: - The new "source" command has been added, which implements exactly the same functionlaity as the old "autoscr" command before - The old "autoscr" command name is kept as an alias for compatibility - Command sequences, script files atc. have been adapted to use the new "source" command - Related environment variables ("autoscript", "autoscript_uname") have *not* been adapted yet; these will be renamed resp. removed in a separate patch when the support for the "autoscr" command get's finally dropped. Signed-off-by: Wolfgang Denk <wd@denx.de> 
According to the doc/feature-removal-schedule.txt, the "autoscr"
command will be replaced by the "source" command in approximately 6
months from now.

This patch prepares this change and starts a 6 month transition
period as follows:

- The new "source" command has been added, which implements exactly
  the same functionlaity as the old "autoscr" command before
- The old "autoscr" command name is kept as an alias for compatibility
- Command sequences, script files atc. have been adapted to use the
  new "source" command
- Related environment variables ("autoscript", "autoscript_uname")
  have *not* been adapted yet; these will be renamed resp. removed in
  a separate patch when the support for the "autoscr" command get's
  finally dropped.

Signed-off-by: Wolfgang Denk <wd@denx.de>
usb.h: use standard __LITTLE_ENDIAN from Linux headers 2009-01-28T18:57:29+00:00 Mike Frysinger vapier@gentoo.org 2009-01-01T23:27:27+00:00 c7d703f3f3c3d6b020bda4cf633f8a6167c3cd2a Rather than forcing people to define a custom "LITTLEENDIAN", just use the __LITTLE_ENDIAN one from the Linux byteorder headers that every arch is already setting up. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Remy Bohmer <linux@bohmer.net> 
Rather than forcing people to define a custom "LITTLEENDIAN", just use the
__LITTLE_ENDIAN one from the Linux byteorder headers that every arch is
already setting up.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Remy Bohmer <linux@bohmer.net>