Some boards (e.g. lwmon5) may use rather small watchdog intervals, so
causing it to reboot the board if U-Boot does a long busy-wait with
udelay(). Thus, for these boards we have to restart WD more
frequently.
This patch splits the busy-wait udelay() into smaller, predefined,
intervals, so that the watchdog timer may be resetted with the
configurable (CONFIG_WD_PERIOD) interval.
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
Adds configuration option for ATI Radeon 9200 card
support to sequoia config file. If CONFIG_VIDEO
is enabled, TEXT_BASE should be changed to 0xFFF80000.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
For historical reasons we limited the stack to 256M because some boards
could only map that much via BATS. However newer boards are capable of
mapping more memory (for example 85xx is capable of doing up to 2G).
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This bumps the autoconf.mk include step above board/cpu/arch/etc... so that
those .mk files can have make if statements based on the current config.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
If any of the steps for generating autoconf.mk fail currently, they go
unnoticed. To fix, we can simply add 'set -e' to the long list of commands.
This is simpler and more robust than placing '|| exit $$?' after every line.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
By adding VERSION_FILE to the PHONY targets the script
/tools/setlocalversion is always called and version_autogenerated.h
is replaced only if the script find a modified source file.
Signed-off-by: Stefano Babic <sbabic@denx.de>
- Fix flash_init call when CFG_NO_FLASH is used
- Remove no more needed flash.c for qemu-mips
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Michael Hennerich added support for outputting an image in RGB format rather
than forcing YUYV all the time. This makes obvious sense if the display you
have takes RGB input rather than YUYV.
Rather than hack in support for options, I've converted it to use getopt and
cleaned up the argument parsing in the process.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
If the $(LDSCRIPT) does not exist (normally it's board/$(BOARD)/u-boot.lds),
then change into the board directory and try and create it. This allows you
to generate the linker script on the fly based upon board defines (like the
Blackfin boards do).
There should be no regressions due to this change as the normal case is to
already have a u-boot.lds file. If that's the case, then there's nothing to
generate, and so make will always exit. The fix here is that if the linker
script does not exist, the implicit rules take over and attempt to guess how
to generate the file.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Do not use uninitialized cmd_reset; issue both AMD and Intel reset
commands instead
From a short test, it looks like AMD-style flash roms treat *any* unknown
command write as a reset, at least when in CFI Query mode, so issuing the
Intel reset command to AMD-style flashs seems safe (from the small sample I
have), plus the 3-cycle magic sequence should kick the state machine into
the right state even without a reset command. Since the AMD-style flashs
require the unlock sequence for real operation, I chose to try the AMD reset
command first, so that Intel flashs do no see an invalid command prior to
the CFI query.
I have tested the patch on AM29LV320-style flashs from Fujitsu and Macronix,
plus Intel StrataFlash.
Signed-off-by: Michael Schwingen <michael@schwingen.org>
Signed-off-by: Stefan Roese <sr@denx.de>
The CPU POST test code (run from cpu_post_exec_31()) doesn't follow the
ABI carefully, at least the CR3, CR4, and CR5 fields of CR are clobbered
by it. The gcc-4.2 with its more aggressive optimization exposes this fact.
This patch just saves the CR value before running the test code, so allowing
it to do anything it wants with CR.
Signed-off-by: Dmitry Rakhchev <rda@emcraft.com>
Acked-by: Yuri Tikhonov <yur@emcraft.com>
--
Back in commit 975a083a5e where
I tried to "8610HPCD: Fix typos in two PCI setup registers", I
botched it due to not realizing that 8610 and 8641 had different
Global Utility Register defintions, one of which was like 85xx,
and the other wasn't. Correct this problem by introducing two
symbols, one for each 86xx SoC, but neither of which is named
anything like 85xx.
My bad. Lovely Wednesday with git bisect. You know.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Without an actual supported video card hooked up, enabling
the CONFIG_VIDEO by default just makes it look broken by
routing all console output to the video card. Don't.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
The two symbols MPC86xx_PORDEVSR_IO_SEL and MPC86xx_PORBMSR_HA
were erroneously present as 85xx names and values, leftover from
the clone wars. Fix this by removing the 85xx cruft from the
86xx codebase.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
This is the proper fix for a missing closing brace in the function
ft_cpu_setup() noticed by joe.hamman <at> embeddedspecialties.com.
The ft_cpu_setup() function in mpc8641hpcn.c should have been
removed earlier as it was under the obsolete CONFIG_OF_FLAT_TREE,
but was missed. Only, the sbc8641d was nominally still using it.
It all got ripped out, and the funcality that was in ft_board_setup()
was refactored to remove the CPU portions into the new file
cpu/mpc86xx/fdt.c instead. Make sbc8641d use this now.
Based loosely on an original patch from joe.hamman@embeddedspecialties.com
Signed-off-by: Jon Loeliger <jdl@freescale.com>
The option CONFIG_I2C_MULTI_BUS does not have any effect on Sequoia, the
PPC440EPx reference platform, because IIC1 is never enabled. Add Sequoia board
code to turn on IIC1 if CONFIG_I2C_MULTI_BUS is selected.
Signed-off-by: Mike Nuss <mike@terascala.com>
Cc: Stefan Roese <sr@denx.de>
This patch tries to get rid of some assembler warnings about
changed .got2 section type while compiling x86 bios emulator
code.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
This patch extends PCI device id table of the
radeon driver so that the driver will also support
Radeon Mobility 9200 (M9+) based boards.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
