Before that moment our defconfigs were manually modified with addition
of new options. That means once anybody wants to add another option and
re-genarate defconfig with "make defconfig" there will be lots of
differences. So to make future modifications more clean we'll do bulk
re-generation right away.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Intention behind this work was elimination of as much assembly-written
code as it is possible.
In case of ARC we already have relocation fix-up implemented in C so why
don't we use C for U-Boot copying, .bss zeroing etc.
It turned out x86 uses pretty similar approach so we re-used parts of
code in "board_f.c" initially implemented for x86.
Now assembly usage during init is limited to stack- and frame-pointer
setup before and after relocation.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
This separation makes maintenance of code easier because those low-level
interrupt- or exception handling routines are pretty static and usually
require not much care while start-up code is a subject of modifications
and enhancements.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Even though ARCompact and ARCv2 are not binary compatible most of
assembly instructions are used in both. With this change we'll get rid
of duplicate code.
Still IVTs are implemented differently so we're keeping them in separate
files.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
always
Make both invalidate_icache_all() and invalidate_dcache_all() available
even if U-Boot is configured with CONFIG_SYS_DCACHE_OFF and/or
CONFIG_SYS_ICACHE_OFF.
This is useful because configuration of U-Boot may not match actual
hardware features. Real board may have cache(s) but for some reason we
may want to run U-Boot with cache(s) disabled (for example if some
peripherals work improperly with existing drivers if data cache is
enabled). So board may start with cache(s) enabled (that's the case for
ARC cores with built-in caches) but early in U-Boot we disable cache(s)
and make sure all contents of data cache gets flushed in RAM.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Being global variable with 0 value it falls into .bss area which we may
only use after relocation to RAM. And right afetr relocation we zero
.bss - effectively cleaing register address set for early console.
Now with pre-set value "regs" variable is no longer in .bss and this way
safely survives relocation.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Create a new configuration file: at91-sama5_common.h. Which includes the
configurations that reused by all SAMA5 chips.
at91-sama5_common.h includes:
- hw macros (clock, text_base and etc.)
- default commands.
- BOOTARGS
- U-Boot common configs.
NOTE: NOR flash definition should be put before including the common header.
For sama5d3-xplained:
- add CMD_SETEXPR
For sama5d3xek:
- add CMD_SETEXPR
- change CONFIG_SYS_MALLOC_LEN to (4*1024*1024)
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Supports boot up from NAND flash with software ECC eanbled.
And supports boot up from SD/MMC card with FAT file system.
As the boot from SD/MMC card with FAT file system, the BSS
segment is too big to fit into SRAM, so, use the lds to put
it into SDRAM.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Config MCKR according to the datasheet sequence, or else it
will cause the MCKR configuration failed.
Remove timeout checking for clock configuration, if configure
the clock failed, let the system hang while not run in wrong
clock configuration.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Heiko Schocher <hs@denx.de>
Insteading in mmc's raw sectors, this patch will save the environment
in a fat file (uboot.env) in mmc card's first FAT patition by default.
If you want to save in mmc's raw sectors, you only need to define
CONFIG_ENV_IS_IN_MMC.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Bo Shen <voice.shen@atmel.com>
Add support for on-flash bad block table. This makes U-Boot handle an existing
BBT correctly.
Signed-off-by: David Dueck <davidcdueck@googlemail.com>
Reviewed-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
CC: Boris BREZILLON <boris.brezillon@free-electrons.com>
CC: Josh Wu <josh.wu@atmel.com>
CC: Andreas Bießmann <andreas.devel@googlemail.com>
CC: Scott Wood <scottwood@freescale.com>
Acked-by: Josh Wu <josh.wu@atmel.com>
To facilitate changing lowlevel_init to become s_init, move the current
contents of s_init into board_init_f and add the rest of what
board_init_f does here.
In order to compile clean without CONFIG_SKIP_LOWLEVEL_INIT set, leave an
empty stub of s_init(). It can be removed when lowlevel_init becomes s_init.
Cc: Bo Shen <voice.shen@atmel.com>
Cc: Andreas Bießmann <andreas.devel@googlemail.com>
Tested-by: Matt Porter <mporter@konsulko.com> on sama5d3_xplained
Signed-off-by: Tom Rini <trini@ti.com>
[rebased on current master, leave s_init() as empty stub]
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
The commit 8dfafdd (Introduce common timer functions), add common
timer functions, we can use them directly.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
[rebase on current master]
Sigend-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Testing showed, that commands like STATUS made the buffer dirty
when executed with NFC_SECSZ set to the page size. It looks
like the controller transfers bogus data when this register
is configured. When setting it to 0, the buffer does not get
altered while the status command still seems to work flawless.
Signed-off-by: Stefan Agner <stefan@agner.ch>
The driver tries to re-use the page buffer by storing the page
number of the current page in the buffer. The page is only read
if the requested page number is not currently in the buffer. When
a block is erased, the page number is marked as invalid if the
erased page equals the one currently in the cache. However, since
a erase block consists of multiple pages, also other page numbers
could be affected.
The commands to reproduce this issue (on a written page):
> nand dump 0x800
> nand erase 0x0 0x20000
> nand dump 0x800
The second nand dump command returns the data from the buffer,
while in fact the page is erased (0xff).
Avoid the hassle to calculate whether the page is affected or not,
but set the page buffer unconditionally to invalid instead.
Signed-off-by: Stefan Agner <stefan@agner.ch>
This command is only enabled by one board, complicates the NAND code,
and doesn't appear to have been functioning properly for several
years. If there are no bad blocks in the NAND region being written
nand_write_skip_bad() will take the shortcut of calling nand_write()
which bypasses the special yaffs handling. This causes invalid YAFFS
data to be written. See
http://lists.denx.de/pipermail/u-boot/2011-September/102830.html for
an example and a potential workaround.
U-Boot still retains the ability to mount and access YAFFS partitions
via CONFIG_YAFFS2.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
The CONFIG_MTD_NAND_VERIFY_WRITE has been removed from Linux for some
time and a more generic method of NAND verification now exists in U-Boot.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Tested-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Previously NAND writes were not verified and could fail silently. Add
a verification step after all writes to NAND.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Previously NAND writes were only verified when CONFIG_MTD_NAND_VERIFY_WRITE
was defined. On boards without this define writes could fail silently.
Boards with CONFIG_MTD_NAND_VERIFY_WRITE could prematurely report
failures which ECC could correct.
Add a verification step after all "nand write[.x]" commands to ensure the
writes were successful. The verification uses ECC for for "normal"
writes, but does not for raw and yaffs writes. Some test cases which
inject fake bad bits on a 2K page flash are below.
Test cases with CONFIG_MTD_NAND_VERIFY_WRITE defined:
Example of an ECC write which previously failed when
CONFIG_MTD_NAND_VERIFY_WRITE was defined, but now succeeds because ECC
is used during verification:
nand erase 0 0x10000
dhcp /somefile
mw.b 0x10000 0xff 0x2000
mw.b 0x10020 0xfe 1
nand write.raw 0x10000 0x800 1
mw.b 0x1000020 0x01 1
nand write 0x1000000 0x800 0x1800
Test cases without CONFIG_MTD_NAND_VERIFY_WRITE defined:
Example of an ECC write which previously silently failed:
nand erase 0 0x10000
dhcp /somefile
mw.b 0x10000 0xff 0x2000
mw.b 0x10020 0x00 1
nand write.raw 0x10000 0x800 1
mw.b 0x1000020 0xff 1
nand write 0x1000000 0x800 0x1800
Example of a raw write which previously failed silently due to stuck
data bit, but now errors out:
nand erase 0 0x10000
dhcp /somefile
mw.b 0x10000 0xff 0x2000
mw.b 0x10020 0xfe 1
nand write.raw 0x10000 0x800 1
mw.b 0x1000020 0x01 1
nand write.raw 0x1000000 0x800 3
Example of a raw write which previously failed silently due to stuck OOB
bit, but now errors out:
nand erase 0 0x10000
dhcp /somefile
mw.b 0x10000 0xff 0x2000
mw.b 0x10810 0xfe 1
nand write.raw 0x10000 0x800 1
mw.b 0x1000810 0x01 1
nand write.raw 0x1000000 0x800 3
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Tested-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Add nand_verify() and nand_verify_page_oob(). nand_verify() verifies
NAND contents against an arbitrarily sized buffer using ECC while
nand_verify_page_oob() verifies a NAND page's contents and OOB.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Tested-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
The use of the nand_write_options and nand_read_options structures were
removed in commit dfbf617ff0. Remove the
now-unused structures too.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
By specification the FIFO size would be in a range 2-256 bytes. From TX Level
prospective it means we can set threshold in the range 0-(FIFO size - 1) bytes.
Hence there are currently two issues:
a) FIFO size 2 bytes is actually skipped since TX Level is 1 bit and could be
either 0 or 1 byte;
b) FIFO size is incorrectly decreased by 1 which already done by meaning of
TX Level register.
Fixes: 501943696e (spi: designware_spi: Fix detecting FIFO depth)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Pavel Machek <pavel@denx.de>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Make local functions static and remove unneeded forward declarations.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Don't assume slave is always the first member of struct cf_spi_slave.
Use container_of instead of casting first structure member.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
This patch enables QUAD read mode for qspi to improve the
read performace while loading the binaries from qspi.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Don't assume slave is always the first member of struct ftssp010_spi.
Use to_ftssp010_spi() to ensure free correct address in spi_free_slave().
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
The third parameter of container_of is the name of the member within the struct.
Current code only works if the parameter passed to to_cf_qspi_slave named slave.
Fix it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
following kernel patches to reduce the cpu clock to 912MHz due to
reported instability at 1008MHz, select 912MHz as the boot speed
for the a10-lime
Signed-off-by: Iain Paton <ipaton0@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
make the CPU clock selectable via Kconfig
this removes the sunxi specific CONFIG_CLK_FULL_SPEED defined in each
soc header and replaces it's use in board/sunxi/board.c with
CONFIG_SYS_CLK_FREQ from Kconfig which allows us to configure board
specific frequency on boot
Signed-off-by: Iain Paton <ipaton0@gmail.com>
[hdegoede@redhat.com s/CONFIG_SYS_CLK_FREQ/CONFIG_TIMER_CLK_FREQ/ for the
arch-timer clk speed on sun7i to fix mis-compile on sun7i]
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
clock_set_pll1 would pick the next highest available cpu clock speed if
a value not in the pre defined table was selected. this potentially
results in overclocking the soc.
reverse the selection method so that we select the next lowest speed
and add the missing 912Mhz setting that's requested by sun7i which also
uses the sun4i clock code.
Signed-off-by: Iain Paton <ipaton0@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The usb0 / otg phy on sunxi boards has a bug where it wrongly detects a
high speed squelch on usb reset deassert when a lo speed device is plugged in.
The android kernel has a work around for this in the form of temporary
disabling the phy's squelch detection on reset deassert, this commit adds
the same workaround to the u-boot sunxi musb code, thereby fixing various usb
lo speed devices not working.
Tested with a (before non working) usb keyboard and a usb 2.4 GHz wireless
keyboard/mouse combo receiver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add CONFIG_SYS_GENERIC_BOARD to amcc-common.h and CONFIG_DISPLAY_BOARDINFO
to Kconfig files. canyonlands.h includes amcc-common.h, so remove
CONFIG_SYS_GENERIC_BOARD definition there.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Feng Kan <fkan@amcc.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Tom Rini <trini@konsulko.com>
The current head revision of mkenvimage
(e72be8947e) will prevent you from creating
an env image from a text file that is larger than the env length specified
by the '-s' option. That doesn't make sense given that the tool now allows
comments and blank lines. This patch removes that limitation and allows
longer text files to be used.
I don't have time / desire at the moment to figure out "patman" and could
really care less if this is adopted up stream. Just figured I would share
in case anybody else finds it useful enough to take time to do a proper
patch.
>From 39ff30190c2bf687861f4b4b33230f1944fb64f9 Mon Sep 17 00:00:00 2001
From: Brian McFarland <bmcfarland@rldrake.com>
Date: Thu, 12 Mar 2015 11:37:19 -0400
Subject: [PATCH] In mkenvimage, removed the check that prevented using a
source text file larger than the output environment image. Instead, the main
parsing loop checks to see if the environment buffer is full, and quits if it
is. After the main parse loop, a second loop swallows comments and
whitespace until either the EOF is reached or more env vars are found, in
which case an error will be thrown.
Fix eb_cpu5282 and eb_cpu5282_internal unresolved external error.
These boards have video but don't need any ppc related
video_setmem().
Fix M53017EVB moving away embedded env to a different offset,
as in M52277EVB.
Signed-off-by: Angelo Dureghello <angelo@sysam.it>
Purpose of this change is to make it possible to re-use code currently
used on X86 solely for other architectures. For example:
* init_sequence_f_r
* board_init_f_r
Even though board_init_f_mem() has nothing to do with any particular
architecture it won't work (at least in current implementation) for X86.
This is because on X86 "gd" is an alias to function get_fs_gd_ptr(),
thus we cannot assign anything to it.
So this change separates selection of board_init_f_mem() from X86 while
keeping it disabled for X86 still.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
This variant that is neither FVP / Base Model or Juno Versatile
Express 64bit is confusing. Get rid of it unless someone can
point out what machine that really is. Seems to be an evolutional
artifact in the config base.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
