When putting pointers into a format string use %p to ensure that they
are printed correctly regardless of bitsize. This fixes warnings on
sandbox on 64bit systems.
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Gerald Van Baren <vanbaren@cideas.com>
Signed-off-by: Tom Rini <trini@ti.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Without this, fstypes[].probe points at the wrong place, so calling the
function results in undefined behaviour.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Andreas Bießmann <andreas.devel@googlemail.com>
When BUILD_NBUILDS is > 1 we run the tidy command. With the addition of
DocBook this now includes a -C doc/DocBook and a 'entering/leaving' pair
of messages happen. Since we don't want to see what's being cleaned
here, we can just invoke make -s like we do when building.
Signed-off-by: Tom Rini <trini@ti.com>
Fix the following error in the ext4 command:
cmd_ext4.c:110:3: error: format '%lu' expects argument of type
'long unsigned int', but argument 4 has type 'int' [-Werror=format]
Signed-off-by: Simon Glass <sjg@chromium.org>
Deassert the CONFIG pin before asserting it again. This assures that the
FPGA will be resetted and therefore configuration will be correctly
enabled.
This is also already done on other FPGA's, e.g. Stratix.
Signed-off-by: Stephan Gatzka <stephan.gatzka@hbm.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Implement "ls" and "fsload" commands that act like {fat,ext2}{ls,load},
and transparently handle either file-system. This scheme could easily be
extended to other filesystem types; I only didn't do it for zfs because
I don't have any filesystems of that type to test with.
Replace the implementation of {fat,ext[24]}{ls,load} with this new code
too.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
This makes the FAT and ext4 filesystem implementations build if
CONFIG_FS_{FAT,EXT4} are defined, rather than basing the build on
whether CONFIG_CMD_{FAT,EXT*} are defined. This will allow the
filesystems to be built separately from the filesystem-specific commands
that use them. This paves the way for the creation of filesystem-generic
commands that used the filesystems, without requiring the filesystem-
specific commands.
Minor documentation changes are made for this change.
The new config options are automatically selected by the old config
options to retain backwards-compatibility.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
fs/Makefile is unused. The top-level Makefile sets LIBS-y += fs/xxx and
hence causes make to directly descend two directory levels into each
individual filesystem, and it never descends into fs/ itself.
So, delete this useless file.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Acked-by: Simon Glass <sjg@chromium.org>
This patch remove the env saving in NAND as so far the
NAND driver is not ported to the M54418TWR platform.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
The M54418TWR lds file need to update since commit:
8b493a5236
common: Discard the __u_boot_cmd section
The command declaration now uses the new LG-array method to generate
list of commands. Thus the __u_boot_cmd section is now superseded and
redundant and therefore can be removed. Also, remove externed symbols
associated with this section from include/command.h .
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
Once more, some of the previous changes caused the code to grow, which
causes errors like
u-boot.lds:74 cannot move location counter backwards (from 40008384 to 40008000)
when building with some older tool chains (like ELDK 4.2).
Adjust the linker script to make fit again.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Conn Clark <clark@esteem.com>
Once more, some of the previous changes caused the code to grow, which
causes errors like
u-boot.lds:80 cannot move location counter backwards (from 400082a4 to 40008000)
when building with some older tool chains (like ELDK 4.2).
Adjust the linker script to make fit again.
Signed-off-by: Wolfgang Denk <wd@denx.de>
These boards have long reached EOL, and there has been no indication
of any active users of such hardware for years. Get rid of the dead
weight.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Wolfgang Grandegger <wg@denx.de>
When -ffunction-sections or -fdata-section are used, symbols are placed
into sections such as .data.eserial1_device and .bss.serial_current.
Update the linker script to explicitly include these. Without this
change (at least with my gcc-4.5.3 built using crosstool-ng), I see that
the sections do end up being included, but __bss_end__ gets set to the
same value as __bss_start.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Allen Martin <amartin@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Added clock settings for MFC, FIMC, FB and G3D. They are clocked to
maximum respective frequencies as per datasheet.
Signed-off-by: Annamalai Lakshmanan <annamalai.lakshmanan@linaro.org>
Signed-off-by: Giridhar Maruthy <giridhar.maruthy@linaro.org>
Signed-off-by: Inderpal Singh <inderpal.singh@linaro.org>
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
SX1 does not build properly by itself, is not built
as part of MAKEALL arm or MAKEALL -a arm, and is only
present in Makefile, not boards.cfg. As it also has no
entry in MAINTAINERS, it is orphan and non-functional.
Remove it.
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Remove calls to serial_assign() that are failing now that it returns a
proper error code. This calls were not actually doing anything
because they passed the name of a stdio_dev when a serial_device name
is exptectd.
Signed-off-by: Allen Martin <amartin@nvidia.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
This makes the FAT filesystem API more consistent with other block-based
filesystems. If in the future standard multi-filesystem commands such as
"ls" or "load" are implemented, having FAT work the same way as other
filesystems will be necessary.
Convert cmd_fat.c to the new API, so the code looks more like other files
implementing the same commands for other filesystems.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
cur_part_info.{name,type} are strings. So, we don't need to memset()
the entire thing, just put the NULL-termination in the first byte.
Add missing initialization of the bootable and uuid fields.
None of these fields are actually used by fat.c. However, since it
stores the entire disk_partition_t, we should make sure that all fields
are valid.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
A future patch will implement the more standard filesystem API
fat_set_blk_dev(). This API has no way to know which partition number
the partition represents. Equally, future DM rework will make the
concept of partition number harder to pass around.
So, simply remove cur_part_nr from fat.c; its only use is in a
diagnostic printf, and the context where it's printed should make it
obvious which partition is referred to anyway (since the partition ID
would come from the user command-line that caused it).
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
serial_ns16550.c:222:1: warning: symbol 'eserial1_init' was not declared. Should it be static?
serial_ns16550.c:222:1: warning: symbol 'eserial1_setbrg' was not declared. Should it be static?
serial_ns16550.c:222:1: warning: symbol 'eserial1_getc' was not declared. Should it be static?
serial_ns16550.c:222:1: warning: symbol 'eserial1_tstc' was not declared. Should it be static?
serial_ns16550.c:222:1: warning: symbol 'eserial1_putc' was not declared. Should it be static?
serial_ns16550.c:222:1: warning: symbol 'eserial1_puts' was not declared. Should it be static?
serial_ns16550.c:225:1: warning: symbol 'eserial2_init' was not declared. Should it be static?
serial_ns16550.c:225:1: warning: symbol 'eserial2_setbrg' was not declared. Should it be static?
serial_ns16550.c:225:1: warning: symbol 'eserial2_getc' was not declared. Should it be static?
serial_ns16550.c:225:1: warning: symbol 'eserial2_tstc' was not declared. Should it be static?
serial_ns16550.c:225:1: warning: symbol 'eserial2_putc' was not declared. Should it be static?
serial_ns16550.c:225:1: warning: symbol 'eserial2_puts' was not declared. Should it be static?
serial_ns16550.c:228:1: warning: symbol 'eserial3_init' was not declared. Should it be static?
serial_ns16550.c:228:1: warning: symbol 'eserial3_setbrg' was not declared. Should it be static?
serial_ns16550.c:228:1: warning: symbol 'eserial3_getc' was not declared. Should it be static?
serial_ns16550.c:228:1: warning: symbol 'eserial3_tstc' was not declared. Should it be static?
serial_ns16550.c:228:1: warning: symbol 'eserial3_putc' was not declared. Should it be static?
serial_ns16550.c:228:1: warning: symbol 'eserial3_puts' was not declared. Should it be static?
serial_ns16550.c:231:1: warning: symbol 'eserial4_init' was not declared. Should it be static?
serial_ns16550.c:231:1: warning: symbol 'eserial4_setbrg' was not declared. Should it be static?
serial_ns16550.c:231:1: warning: symbol 'eserial4_getc' was not declared. Should it be static?
serial_ns16550.c:231:1: warning: symbol 'eserial4_tstc' was not declared. Should it be static?
serial_ns16550.c:231:1: warning: symbol 'eserial4_putc' was not declared. Should it be static?
serial_ns16550.c:231:1: warning: symbol 'eserial4_puts' was not declared. Should it be static?
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
fsl_i2c.c:217:14: warning: symbol 'get_i2c_clock' was not declared. Should it be static?
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Acked-by: Heiko Schocher <hs@denx.de>
Move the hardcoded ddr2/ddr3 settings for the ti boards to board code,
so other boards can use different types/timings.
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
[trini: Make apply with rtc32k_enable() in the file]
Signed-off-by: Tom Rini <trini@ti.com>
The i2c header is specific to ti(-derived) boards, and not generic for all
am335x boards.
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
[trini: Make re-apply with rtc32k_enable() applied]
Signed-off-by: Tom Rini <trini@ti.com>
Add the required config.mk logic for this SoC as well as the BOOT_DEVICE
define. Finally, enable the options on the am335x_evm.
Signed-off-by: Tom Rini <trini@ti.com>
D0/D1 Swapped or not is a board property, not anything specific to
the am33xx SoC, so add a custom define for it.
At the same time correct the bit handling for the swapped mode
(DPE0 should be cleared and SI/DPE1 set).
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
Some GPIOs differ in the new revision board.
Previous revision are considered obsolete and
they will not anymore supported.
Signed-off-by: Stefano Babic <sbabic@denx.de>
The mcx board was slightly modified and the pinmux must be updated.
There is no need to support the old board, that becomes obsolete.
Signed-off-by: Stefano Babic <sbabic@denx.de>
In order to support low power state, you must source kernel system
timers to persistent clock, available across suspend/resume. In case of
AM335x device, the only source we have is, RTC32K, available in
wakeup/always-on domain. Having said that, during validation it has
been observed that, RTC clock need couple of seconds delay to stabilize
the RTC OSC clock; and such a huge delay is not acceptable in kernel
especially during early init and also it will impact quick/fast boot
use-cases.
So, RTC32k OSC enable dependency has been shifted to
SPL/first-bootloader.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
Add Freescale MCF54418TWR ColdFire development board support.
Signed-off-by: TsiChung Liew <tsicliew@gmail.com>
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
Signed-off-by: Alison Wang <b18965@freescale.com>
Add MCF5441x CPU support.
The MCF5441x devices are a family of highly-integrated 32-bit
microprocessors based on the Version 4m ColdFire microarchitecture,
comprising of the V4 integer core, memory management unit(MMU) and
enchanced multiply-accumulate unit(EMAC).
Signed-off-by: TsiChung Liew <tsicliew@gmail.com>
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
Signed-off-by: Alison Wang <b18965@freescale.com>
