Freescale's T1040qds board may be configured to have up to
5 FMAN ports (FM1@DTSEC1 to FM1@DTSEC5). From these 5 ports,
2 of them may be fixed-links (FM1@DTSEC1 annd FM1@DTSEC2),
connected to other two ports from an intergrated
VSC9953 L2 Switch (switch ports 8 and 9). These fixed-link
ports have no PHYs attatched, so they don't have a
corresponding MDIO.
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
This patch initializes VSC9953 L2 Switch for boards that have
CONFIG_VSC9953 defined in their config file.
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@freescale.com>
Implement MIPS specific setup of the gd_t structure to support
pre-relocation malloc. If CONFIG_SYS_MALLOC_F_LEN is specified,
a memory area will be reserved after the initial stack area and
the gd->malloc_base pointer will be initialized.
After this patch the new driver model can be used on MIPS.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Support the existing config option CONFIG_SYS_INIT_SP_ADDR on
MIPS. This allows to move the initial stack to other places
than the beginning of RAM.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Conditionally set head-y and lib-y with boolean Kconfig symbols
for selected CPU. This deprecates the usage of the $(CPU) variable.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
The common code just needs the C0_COUNT as free running counter,
without the need of writing and checking C0_COMPARE.
The function get_tbclk() is still implemented here instead of changing
all places of CONFIG_SYS_MIPS_TIMER_FREQ to CONFIG_SYS_TIMER_RATE.
The change was tested on a MIPS32 system, but as the MIPS64 code
was/is the same, this should be no problem.
Signed-off-by: Thomas Langer <thomas.langer@lantiq.com>
Add the initial code to prepare a flattened device tree for
the kernel like relocating the FDT blob and fixing up the
/chosen and /memory nodes.
The final hand over to the kernel is not yet implemented. After
the community agreed on the MIPS boot interface for device trees,
the corresponding code will be added.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
If the user wants to boot a kernel without legacy environment,
information like memory size, initrd address and size should be
handed over to the kernel in the command line.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Move preparation of Linux kernel environment in a separate
function and mark it as legacy. Add a Kconfig option to make
that legacy mode configurable.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Move preparation of Linux kernel command line in a separate
function and mark it as legacy. Add a Kconfig option to make
that legacy mode configurable.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
This patch fix the compilation warning
w+../drivers/net/xilinx_ll_temac.c: In function 'll_temac_init':
w+../drivers/net/xilinx_ll_temac.c:235:3: warning: format '%X' expects
argument of type 'unsigned int', but argument 4 has type 'phys_addr_t'
[-Wformat]
introduced by
"net: Declare physical address as phys_addr_t unsigned type"
(sha1: 16ae782722).
Reported-by: Tom Rini <trini@ti.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Show fpga_op->info even if desc->iface_fns is not defined.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This problem is reported by checkpatch.pl
Warnings:
CHECK: extern prototypes should be avoided in .h files
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
For case where CMD_FPGA_LOADMK is enabled and GZIP disable.
Warning log:
common/built-in.o: In function `do_fpga':
/mnt/disk/u-boot/common/cmd_fpga.c:218: undefined reference to `gunzip'
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The global_data pointer (gd) has already been set before board_init_f()
is called. We should not assign it again. We should also not use gdata since
it is going away.
Signed-off-by: Simon Glass <sjg@chromium.org>
The global_data pointer (gd) has already been set before board_init_f()
is called. We should not assign it again. We should also not use gdata since
it is going away.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Stefano Babic <sbabic@denx.de>
The global_data pointer (gd) has already been set before board_init_f()
is called. We should not assign it again. We should also not use gdata since
it is going away.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Nikita Kiryanov <nikita@compulab.co.il>
Acked-by: Nikita Kiryanov <nikita@compulab.co.il>
The global_data pointer (gd) has already been set before board_init_f()
is called. We should not assign it again. We should also not use gdata since
it is going away.
Signed-off-by: Simon Glass <sjg@chromium.org>
Wider bus widths (larger than default 1 bit) appeared in MMC standard
version 4.0. So, for MMC cards of any earlier version trying to change
the bus width (including ext_csd comparison) does not make any sense.
It may work incorrectly and at least cause unnecessary timeouts.
So, just skip the entire bus width related activity for earlier versions.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Tested-by: Alexey Brodkin <abrodkin@synopsys.com>
If all the commands switching an MMC card to 4- or 8-bit bus width fail,
and the bus width for the controller and the driver is still set
to default 1 bit, there is no need to send one more command to switch
the card to 1-bit bus width. Also, if the card or host controller do not
support wider bus widths, there is no need to send a switch command at all.
However, if one of switch commands succeeds, but the subsequent ext_csd
fields comparison fails, the card should be switched to some other bus width
(next in the list for the loop), or to default 1-bit bus width as a last
resort. That's why it would be incorrect to just remove the 1-bit bus width
case from the list, it should still be processed in some cases.
panto: Minor cosmetic edit removing superfluous parentheses.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Tested-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
This extends the mmcinfo hardware partition info output to show
partitions with write reliability enabled with the "WRREL" string.
If the partition does not have write reliability enabled the "WRREL"
string is omitted; this is analogous to the ehhanced attribute.
Example output:
Device: OMAP SD/MMC
Manufacturer ID: fe
OEM: 14e
Name: MMC16
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.41
High Capacity: Yes
Capacity: 13.8 GiB
Bus Width: 4-bit
Erase Group Size: 8 MiB
HC WP Group Size: 16 MiB
User Capacity: 13.8 GiB ENH WRREL
User Enhanced Start: 0 Bytes
User Enhanced Size: 512 MiB
Boot Capacity: 16 MiB ENH
RPMB Capacity: 128 KiB ENH
GP1 Capacity: 64 MiB ENH WRREL
GP2 Capacity: 64 MiB ENH WRREL
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
This change extends the mmc hwpartition sub-command to change the
per-partition write reliability settings. It also changes the
syntax used for the enhanced user data area slightly to better
accomodate the write reliability option.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
The eMMC partition write reliability settings are to be set while
partitioning a device, as per the eMMC spec, so changes to these
attributes needs to be done in the hardware partitioning API.
This commit adds such support.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
Adds the mmc hwpartition sub-command to perform eMMC hardware
partitioning on an mmc device. The number of arguments can be
large for a complex partitioning, but as the partitioning has
to be done in one go it is difficult to make it simpler.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
This adds an API to do hardware partitioning on eMMC devices. The
new mmc_hwpart_config() function does the partitioning in one go.
As the different attributes and partitioning options on eMMC may
be interdependent validation has to be done based on the complete
partitioning configuration. The function accepts three modes:
- MMC_HWPART_CONF_CHECK: just validates that the configuration
is valid.
- MMC_HWPART_CONF_SET: validates and sets all the fields in
EXT_CSD but without setting the "partitioning completed" bit,
and thus is reversible.
- MMC_HWPART_CONF_COMPLETE: does everything and is thus not
reversible.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
The mmc_startup() function uses the ext_csd data even if reading it
from the mmc device failed. This bug was introduced in commit
bc897b1d4d. We now bail out if
reading it fails, this should not be a problem as ext_csd was
introduced in MMC 4.0 and this code is conditional on MMC >= 4.0.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
The eMMC spec says that partitioning is only effective after the
PARTITION_SETTING_COMPLETED is set in EXT_CSD (and a power cycle was done,
but that we cannot know). Thus the partition sizes and attributes should
be ignored when that bit is not set, otherwise the various capacities
are not coherent (e.g., the user data capacity will be that of the
unpartitioned device while partition sizes would be non-zero).
Prescence of non-zero partitioning data is nevertheless still used to
activate the high-capacity size definitions (EXT_CSD_ERASE_GROUP_DEF)
as it is necessary to set that to write any of the partitioning fields
in EXT_CSD, so having partitioning data means someone previously
activated that and we should keep it activated.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
This adds the erase group size and high-capacity WP group size to
mmcinfo's output. The erase group size is necessary to properly align
erase requests on eMMC. The high-capacity WP group size is necessary
to properly align partitions on eMMC.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
Read the eMMC high capacity write protect group size at mmc device
initialization. This is useful to correctly partition an eMMC device,
as partitions need to be aligned to this size.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
The erase_grp_size in struct mmc is to be a size in 512-byte sectors
but the code used to compute it for eMMC when EXT_CSD_ERASE_GROUP_DEF is
enabled computed it as bytes, leading to erase sizes and alignment
much larger than what is actually required by the mmc device.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
Codrin Ciubotariu
Daniel Schwierzeck
Thomas Langer
Michal Simek
Siva Durga Prasad Paladugu
Tom Rini
Sinan Akman
Simon Glass
Andrew Gabbasov
Diego Santa Cruz