u-boot.git/board, branch v2016.11 Unnamed repository; edit this file 'description' to name the repository. ARM: k2g: Update PLL Multiplier and divider values 2016-11-13T20:54:37+00:00 Lokesh Vutla lokeshvutla@ti.com 2016-11-03T10:05:02+00:00 4d0fec0e69189bd81c09909fc4eb742c63d5d7ee Only a certain set of PLLM/D values are recommended to configure the DDR at the required speeds for a given clock input frequency. Updating these values as specified in Data Sheet[1] Table 5-18 [1] http://www.ti.com/lit/ds/symlink/66ak2g02.pdf Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
Only a certain set of PLLM/D values are recommended to configure the DDR
at the required speeds for a given clock input frequency. Updating these
values as specified in Data Sheet[1] Table 5-18

[1] http://www.ti.com/lit/ds/symlink/66ak2g02.pdf

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
mx6ull_14x14_evk: Add README file 2016-11-13T20:54:35+00:00 Diego Dorta diego.dorta@nxp.com 2016-11-10T17:05:37+00:00 2ffec69b6f93459be815c64b023840c59aa4006a Add a README file to help users getting started with the board. Signed-off-by: Diego Dorta <diego.dorta@nxp.com> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Jagan Teki <jagan@openedev.com> 
Add a README file to help users getting started with the board.

Signed-off-by: Diego Dorta <diego.dorta@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
davinci: omapl138_lcdk: keep booting even when MAC address is invalid 2016-11-13T20:54:35+00:00 Fabien Parent fparent@baylibre.com 2016-11-10T16:16:35+00:00 02c2de6eb0e2b4170329a51fae3aeb955b330f7b If the MAC address specified on the EEPROM is invalid (multicast or zero address), then u-boot fails to boot. Having a bad MAC address in the EEPROM should not prevent the system from booting. This commit changes the error path to just print an error messages in case of bad MAC address. Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
If the MAC address specified on the EEPROM is invalid (multicast or
zero address), then u-boot fails to boot. Having a bad MAC address
in the EEPROM should not prevent the system from booting.

This commit changes the error path to just print an error messages
in case of bad MAC address.

Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
board: am335x/mux: Do not hang when encountering a bad EEPROM 2016-11-13T20:54:35+00:00 Alex G mr.nuke.me@gmail.com 2016-11-09T04:48:44+00:00 c19a28bc65aa27fe143e3c784d4f2e19e08810bf In most cases, the SPL and u-boot.img will be on the same boot media. Since the SPL was loaded by the boot rom, the pinmux will already have been configured for this media. This, the board will still be able to boot successfully, or at least reach the u-boot console, where more recovery options are available. I've encountered this on a beaglebone black with a corrupted EEPROM. Removing this check allowed the board to boot successfully. I've also seen this on EVM-based boards with an unprogrammed EEPROM. On those boards, for some reason there were no UART messages. This made it look as if the SOC was dead. Remove the hang(), as it is not a fatal error. Also reformat the error message to be clearer as to the cause. The original message made it appear as if the wrong binary was being loaded. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
In most cases, the SPL and u-boot.img will be on the same boot media.
Since the SPL was loaded by the boot rom, the pinmux will already have
been configured for this media. This, the board will still be able to
boot successfully, or at least reach the u-boot console, where more
recovery options are available.

I've encountered this on a beaglebone black with a corrupted EEPROM.
Removing this check allowed the board to boot successfully. I've also
seen this on EVM-based boards with an unprogrammed EEPROM. On those
boards, for some reason there were no UART messages. This made it look
as if the SOC was dead.

Remove the hang(), as it is not a fatal error. Also reformat the error
message to be clearer as to the cause. The original message made it
appear as if the wrong binary was being loaded.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
igep00x0: add Hynix timings 2016-11-13T20:54:34+00:00 Ladislav Michl ladis@linux-mips.org 2016-11-04T11:59:46+00:00 4fa72bd3fc7755777be0850a99b91d2efad6740b Tested on IGEPv2 with Micron MT29F4G16ABBDA3W and Hynix H27S4G6F2DKA-BM Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Reviewed-by: Javier Martinez Canillas <javier@samsung.com> Tested-by: Javier Martinez Canillas <javier@samsung.com> 
Tested on IGEPv2 with Micron MT29F4G16ABBDA3W and
Hynix H27S4G6F2DKA-BM

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Reviewed-by: Javier Martinez Canillas <javier@samsung.com>
Tested-by: Javier Martinez Canillas <javier@samsung.com>
igep00x0: disable CONFIG_DISPLAY_BOARDINFO 2016-11-13T20:54:34+00:00 Ladislav Michl ladis@linux-mips.org 2016-11-04T11:55:21+00:00 ad560f87e0eb5c82a4f6393b6f873fa737556a59 As a single U-Boot binary can now run on various board modifications, drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information too early to give us chance to easily detect it. Also saves few bytes as a bonus. Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Reviewed-by: Javier Martinez Canillas <javier@samsung.com> Tested-by: Javier Martinez Canillas <javier@samsung.com> 
As a single U-Boot binary can now run on various board modifications,
drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information
too early to give us chance to easily detect it. Also saves few bytes
as a bonus.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Reviewed-by: Javier Martinez Canillas <javier@samsung.com>
Tested-by: Javier Martinez Canillas <javier@samsung.com>
wandboard: Make Ethernet functional again 2016-11-06T12:40:40+00:00 Fabio Estevam fabio.estevam@nxp.com 2016-11-01T16:58:16+00:00 dac09fc10b71045ac261a9b8a05d34029ebec2ae Since commit ce412b79e7255770 ("drivers: net: phy: atheros: add separate config for AR8031") ethernet does not work on mx6sabresd. This commit correctly assigns ar8031_config() as the configuration function for AR8031 in the same way as done in the Linux kernel. However, on wandboard design we need some additional configuration, such as enabling the 125 MHz AR8031 output that needs to be done in the board file. This also aligns with the same method that the kernel performs the AR8031 fixup in arch/arm/mach-imx/mach-imx6q.c. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com> 
Since commit ce412b79e7255770 ("drivers: net: phy: atheros: add separate
config for AR8031") ethernet does not work on mx6sabresd.

This commit correctly assigns ar8031_config() as the configuration
function for AR8031 in the same way as done in the Linux kernel.

However, on wandboard design we need some additional configuration,
such as enabling the 125 MHz AR8031 output that needs to be done
in the board file.

This also aligns with the same method that the kernel performs
the AR8031 fixup in arch/arm/mach-imx/mach-imx6q.c.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
mx6sabresd: Make Ethernet functional again 2016-11-06T11:59:27+00:00 Fabio Estevam fabio.estevam@nxp.com 2016-10-24T12:22:06+00:00 4b6035da482cccda06aeb419634f99937c9fc783 Since commit ce412b79e7255770 ("drivers: net: phy: atheros: add separate config for AR8031") ethernet does not work on mx6sabresd. This commit correctly assigns ar8031_config() as the configuration function for AR8031 in the same way as done in the Linux kernel. However, on mx6sabresd design we need some additional configuration, such as enabling the 125 MHz AR8031 output that needs to be done in the board file. This also aligns with the same method that the kernel performs the AR8031 fixup in arch/arm/mach-imx/mach-imx6q.c. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> 
Since commit ce412b79e7255770 ("drivers: net: phy: atheros: add separate
config for AR8031") ethernet does not work on mx6sabresd.

This commit correctly assigns ar8031_config() as the configuration
function for AR8031 in the same way as done in the Linux kernel.

However, on mx6sabresd design we need some additional configuration,
such as enabling the 125 MHz AR8031 output that needs to be done
in the board file.

This also aligns with the same method that the kernel performs
the AR8031 fixup in arch/arm/mach-imx/mach-imx6q.c.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
engicam: icorem6: Fix config files 2016-11-05T14:09:10+00:00 Jagan Teki jagan@amarulasolutions.com 2016-10-29T19:44:31+00:00 97bb1f0bcc2d400347528b759e5ef289f163704a Config file names on MAINTAINERS and README in board/engicam/icorem6 seems to be wrong, hence fixed the same. Cc: Stefano Babic <sbabic@denx.de> Cc: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> 
Config file names on MAINTAINERS and README in
board/engicam/icorem6 seems to be wrong, hence fixed the same.

Cc: Stefano Babic <sbabic@denx.de>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Fix spelling of "occur". 2016-10-31T14:13:16+00:00 Vagrant Cascadian vagrant@debian.org 2016-10-24T03:45:17+00:00 82bd2f29ea6e98ae689b26d793d432ac171d56dc Signed-off-by: Vagrant Cascadian <vagrant@debian.org> Acked-by: Angelo Dureghello <angelo@sysam.it> Reviewed-by: Simon Glass <sjg@chromium.org> 
Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
Acked-by: Angelo Dureghello <angelo@sysam.it>
Reviewed-by: Simon Glass <sjg@chromium.org>