History log of /rk3399_rockchip-uboot/board/lg/sniper/sniper.c (Results 1 – 5 of 5)
Revision Date Author Comments
# 00caae6d 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Rename getenv/_f() to env_get()

We are now using an env_ prefix for environment functions. Rename these
two functions for consistency. Also add function comments in common.h.

Quite a few place

env: Rename getenv/_f() to env_get()

We are now using an env_ prefix for environment functions. Rename these
two functions for consistency. Also add function comments in common.h.

Quite a few places use getenv() in a condition context, provoking a
warning from checkpatch. These are fixed up in this patch also.

Suggested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...


# 382bee57 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Rename setenv() to env_set()

We are now using an env_ prefix for environment functions. Rename setenv()
for consistency. Also add function comments in common.h.

Suggested-by: Wolfgang Denk <wd

env: Rename setenv() to env_set()

We are now using an env_ prefix for environment functions. Rename setenv()
for consistency. Also add function comments in common.h.

Suggested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...


# d5abcf94 01-Feb-2017 Jean-Jacques Hiblot <jjhiblot@ti.com>

ti: boot: Register the MMC controllers in SPL in the same way as in u-boot

To keep a consistent MMC device mapping in SPL and in u-boot, let's
register the MMC controllers the same way in u-boot and

ti: boot: Register the MMC controllers in SPL in the same way as in u-boot

To keep a consistent MMC device mapping in SPL and in u-boot, let's
register the MMC controllers the same way in u-boot and in the SPL.
In terms of boot time, it doesn't hurt to register more controllers than
needed because the MMC device is initialized only prior being accessed for
the first time.
Having the same device mapping in SPL and u-boot allows us to use the
environment in SPL whatever the MMC boot device.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

show more ...


# 17fa0326 18-Jan-2017 Heiko Schocher <hs@denx.de>

serial, ns16550: bugfix: ns16550 fifo not enabled

commit: 65f83802b7a5b "serial: 16550: Add getfcr accessor"
breaks u-boot commandline working with long commands
sending to the board.

Since the abo

serial, ns16550: bugfix: ns16550 fifo not enabled

commit: 65f83802b7a5b "serial: 16550: Add getfcr accessor"
breaks u-boot commandline working with long commands
sending to the board.

Since the above patch, you have to setup the fcr register.

For board/archs which enable OF_PLATDATA, the new field
fcr in struct ns16550_platdata is not filled with a
default value ...

This leads in not setting up the uarts fifo, which ends
in problems, when you send long commands to u-boots
commandline.

Detected this issue with automated tbot tests on am335x
based shc board.

The error does not popup, if you type commands. You need
to copy&paste a long command to u-boots commandshell
(or send a long command with tbot)

Possible boards/plattforms with problems:
./arch/arm/cpu/arm926ejs/lpc32xx/devices.c
./arch/arm/mach-tegra/board.c
./board/overo/overo.c
./board/quipos/cairo/cairo.c
./board/logicpd/omap3som/omap3logic.c
./board/logicpd/zoom1/zoom1.c
./board/timll/devkit8000/devkit8000.c
./board/lg/sniper/sniper.c
./board/ti/beagle/beagle.c
./drivers/serial/serial_rockchip.c

Signed-off-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Tested-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

show more ...


# 41582e2e 29-Mar-2016 Paul Kocialkowski <contact@paulk.fr>

sniper: Change vendor name from lge to lg, matching devicetree vendor prefix

This moves the sniper board from the lge to lg, in order to match the devicetree
vendor prefix already defined in the ker

sniper: Change vendor name from lge to lg, matching devicetree vendor prefix

This moves the sniper board from the lge to lg, in order to match the devicetree
vendor prefix already defined in the kernel.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

show more ...