Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

The new MMU setup will need SDRAM base addresses and sizes.
For this reason convert the MMU enabled ARM boards:

- move mem setup to mem_initcall. This is early but
  still makes sure that we already have the console available
- move MMU setup in this initcall temporary as after the mmu_init will generic

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

this will automaticaly register the device to armlinux_add_dram

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

pass the hccr and hcor register base via resource

instroduce add_generic_usb_echi_device with hccr = base + 0x100 and
hcor = base + 0x140

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

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

Add a helper function for boards to register their memory
devices. This makes the board code smaller and also helps
getting rid of map_base and struct memory_platform_data.

And switch all of the memory to it

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

we keep struct memory_platform_data for now on we will switch off the memories
resources to struct resource

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

Often enough the exception vectors are not on TEXT_BASE (for example
on i.MX SoCs in internal boot mode), so the board specific code did
not map the exception vectors to 0x0 but whatever happens to be on
TEXT_BASE. Also, the current section-only mapping requires the
exception vectors to be on a 1MB boundary.
Instead, create the possibility to create second level tables and
use this to map a copy of the exception vectors in a board
independent way.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Changing PLL settings is somehow tricky on the i.MX27: Whenever the clock
speed of the main PLL is changed, the clock stops for about 100 us until the
PLL locks into the new frequency. While this clock stop, also the SDRAM
controller cannot refresh the memory, because it uses the same clock source.
This can lead into data loss and random system crashes.

This patch divides the PLL setting in two steps. First step is to re-program
the PLL and clock settings to values possible at a core supply of 1.25 V.
Second step is to increase the core power supply to 1.45 V and switch the
CPU clock to the specified 400 MHz.

Signed-off-by: Juergen Beisert <jbe@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

before if you specify id = 0 the next available id will be taken
otherwise fail if already registered now as in linux we use -1

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

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

this will allow each arch to handle the boards more simply and depending on
there need

the env var BOARD will refer to the current board dirent

for sandbox as we have only one board the board dirent is arch/sandbox/board

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>