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>
Use the standard lowercase "xx" capitalization that other Freescale
architectures use for CPU defines to prevent confusion and errors
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
and fix comment
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Adjusted Copyright message.
Signed-off-by: Wolfgang Denk <wd@denx.de>
This patch moves the malloc initialization before calling flash_init().
Upcoming changes to the NOR FLASH common CFI driver with optional
MTD infrastructure and MTD concatenation support will call malloc().
And nothing really speaks against enabling malloc just a little earlier
in the boot stage. Some architectures already enable malloc before
calling flash_init() so they don't need any changes here.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Scott McNutt <smcnutt@psyent.com>
Cc: Shinya Kuribayashi <shinya.kuribayashi@necel.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Daniel Hellstrom <daniel@gaisler.com>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: John Rigby <jcrigby@gmail.com>
We had a bug on 86xx in which the boot page used to bring up secondary
cores was being overwritten and used for the malloc region in u-boot.
We need to reserve the region of memory that the boot page is going to
be put at so nothing uses it.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Becky Bruce <beckyb@kernel.crashing.org>
The environment is the canonical storage location of the mac address, so
we're killing off the global data location and moving everything to
querying the env directly.
In the ppc case, these things are part of the legacy ABI, so keep them
around but mark them as legacy so no new code will touch them.
Also stop calling load_sernum_ethaddr() since all boards now implement
this as a stub.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Ben Warren <biggerbadderben@gmail.com>
The environment is the canonical storage location of the mac address, so
we're killing off the global data location and moving everything to
querying the env directly.
Rather than have common ppc code call a board-specific function like
load_sernum_ethaddr(), have each board call it in its own board-specific
misc_init_r() function.
The boards that get converted here are:
- kup4k/kup4x
- pcs440ep
- tqm8xx
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Ben Warren <biggerbadderben@gmail.com>
CC: Stefan Roese <sr@denx.de>
The environment is the canonical storage location of the mac address, so
we're killing off the global data location and moving everything to
querying the env directly.
Rather than have the common ppc code have board-specific hooks, move the
board_get_enetaddr() function into the board-specific init functions.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Ben Warren <biggerbadderben@gmail.com>
The environment is the canonical storage location of the mac address, so
we're killing off the global data location and moving everything to
querying the env directly.
For the nx823, the serial number is moved out of load_sernum_ethaddr() and
into misc_init_r() as is the env setup. This lets us kill off the former
function in the process.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Ben Warren <biggerbadderben@gmail.com>
Here's a new framework (based roughly off the linux one) for managing
MMC controllers. It handles all of the standard SD/MMC transactions,
leaving the host drivers to implement only what is necessary to
deal with their specific hardware.
This also hooks the infrastructure into the PowerPC board code
(similar to how the ethernet infrastructure now hooks in)
Some of this code was contributed by Dave Liu <daveliu@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Moved CONFIG_MAX_MEM_MAPPED to the asm/config.h so its kept consistent
between the two current users (lib_ppc/board.c, 44x SPD DDR2).
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Stefan Roese <sr@denx.de>
Rather than have the board code initialize SATA automatically during boot,
make the user manually run "sata init". This brings the SATA subsystem in
line with common U-Boot policy.
Rather than having a dedicated weak function "is_sata_supported", people
can override sata_initialize() to do their weird board stuff. Then they
can call the actual __sata_initialize().
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Doing trap_init immediately once we're running from RAM
means we're no longer dependent on the physical location of
the flash on non-BookE platforms. Before trap_init, those
platforms switch to real mode and go to 0xfff00100 on exception.
After the switch, they go to 0x00000100 This makes it easier to
move the flash location.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Added as a convenience for other platforms that uses MPC8360 (has 8 UCC).
Six eth interface is chosen because the platform I am using combines
UCC1&2 and UCC3&4 as 1000 Eth and the other four UCCs as 10/100 Eth.
Signed-off-by: Richard Retanubun <RichardRetanubun@RugggedCom.com>
Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
SGMII and SATA share the serdes on MPC8536 CPU, When SATA disabled and the
driver still try to access the SATA registers, the cpu will hangup.
This patch try to fix this by reading the serdes status before the SATA
initialize.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
Acked-by: Andy Fleming <afleming@freescale.com>
ARM, i386, m68k and ppc all have identical implementations of strmhz().
Other architectures don't provide this function at all.
This patch moves strmhz() into lib_generic, reducing code duplication
and providing a more unified API across architectures.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
This change helps with better handling with others
Xilinx based platform.
Signed-off-by: Michal Simek <monstr@monstr.eu>
Acked-by: Stefan Roese <sr@denx.de>
Make it so we keep track of which LAWs have allocated and provide
a function (set_next_law) which can allocate a LAW for us if one is
free.
In the future we will move to doing more "dynamic" LAW allocation
since the majority of users dont really care about what LAW number
they are at.
Also, add CONFIG_MPC8540 or CONFIG_MPC8560 to those boards which needed them
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Add logbuffer to reserved LMB areas to prevent initrd allocation
from overlaping with it.
Make sure to use correct logbuffer base address.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Add logbuffer to reserved LMB areas to prevent initrd allocation
from overlaping with it.
Make sure to use correct logbuffer base address.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
This reverts commit 70431e8a73 which has
proven problematic getting right from the start at least on 83xx and
4xx.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
The patch 70431e8a73 (Make MPC83xx one step
closer to full relocation.) doesn't use CFG_MONITOR_BASE anymore. But
on 4xx systems _start currently cannot be used for this calculation.
So revert back to the original version for now.
Signed-off-by: Stefan Roese <sr@denx.de>
Remove a few absolute references to CFG_MONITOR_BASE for ppc/mpc83xx
and use GOT relative reference.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
This patch fixes eeprom page size so that you can now write more than
64 bytes at a time.
It also makes the board take MAC addresses, if found, from EEPROM.
User should place up to 4 addresses at offset 0x7f00, for
eth{,1,2,3}addr. Any unused addresses should be zero. This group of
four six-byte values should have it's CRC at the end. crc32 and
eeprom commands can be used to accomplish this.
If CRC fails, MAC addresses come from the environment. If CRC
succeeds, the environment is overwritten at startup.
Signed-off-by: Michael Barkowski <michael.barkowski@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
If CFG_MEM_TOP_HIDE is defined in the board config header, this specified
memory area will get subtracted from the top (end) of ram and won't get
"touched" at all by U-Boot. By fixing up gd->ram_size the Linux kernel
should gets passed the now "corrected" memory size and won't touch it
either. This should work for arch/ppc and arch/powerpc. Only Linux board
ports in arch/powerpc with bootwrapper support, which recalculate the
memory size from the SDRAM controller setup, will have to get fixed
in Linux additionally.
This patch enables this config option on some PPC440EPx boards as a workaround
for the CHIP 11 errata. Here the description from the AMCC documentation:
CHIP_11: End of memory range area restricted access.
Category: 3
Overview:
The 440EPx DDR controller does not acknowledge any
transaction which is determined to be crossing over the
end-of-memory-range boundary, even if the starting address is
within valid memory space. Any such transaction from any PLB4
master will result in a PLB time-out on PLB4 bus.
Impact:
In case of such misaligned bursts, PLB4 masters will not
retrieve any data at all, just the available data up to the
end of memory, especially the 440 CPU. For example, if a CPU
instruction required an operand located in memory within the
last 7 words of memory, the DCU master would burst read 8
words to update the data cache and cross over the
end-of-memory-range boundary. Such a DCU read would not be
answered by the DDR controller, resulting in a PLB4 time-out
and ultimately in a Machine Check interrupt. The data would
be inaccessible to the CPU.
Workaround:
Forbid any application to access the last 256 bytes of DDR
memory. For example, make your operating system believe that
the last 256 bytes of DDR memory are absent. AMCC has a patch
that does this, available for Linux.
This patch sets CFG_MEM_TOP_HIDE for the following 440EPx boards:
lwmon5, korat, sequoia
The other remaining 440EPx board were intentionally not included
since it is not clear to me, if they use the end of ram for some
other purpose. This is unclear, since these boards have CONFIG_PRAM
defined and even comments like this:
PMC440.h:
/* esd expects pram at end of physical memory.
* So no logbuffer at the moment.
*/
It is strongly recommended to not use the last 256 bytes on those
boards too. Patches from the board maintainers are welcome.
Signed-off-by: Stefan Roese <sr@denx.de>
For historical reasons we limited the stack to 256M because some boards
could only map that much via BATS. However newer boards are capable of
mapping more memory (for example 85xx is capble of doing up to 2G).
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
To enable this, alternative, configuration the U-Boot board configuration
file for lwmon5 includes the definitions of alternative addresses for header
(CONFIG_ALT_LH_ADDR) and buffer (CONFIG_ALT_LB_ADDR).
The Linux shall be configured with the CONFIG_ALT_LB_LOCATION option set,
and has the BOARD_ALT_LH_ADDR and BOARD_ALT_LB_ADDR constants defined in the
lwmon5 board-specific header (arch/ppc/platforms/4xx/lwmon5.h).
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
