Stefan Reinauer [Wed, 10 Oct 2012 13:12:56 +0000 (13:12 +0000)]
x86: coreboot: Move non-board specific files to coreboot arch directory
coreboot.c and coreboot_pci.c don't contain board specific but only
coreboot specific code. Hence move it to the coreboot directory in
arch/x86/cpu (which should probably be moved out of cpu/ in another
commit)
Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
Gabe Black [Tue, 27 Nov 2012 21:08:06 +0000 (21:08 +0000)]
x86: Allow excluding reset vector code from u-boot
When running from coreboot we don't want this code.
This version works by ifdef-ing out all of the code that would go
into those sections and all the code that refers to it. The sections are
then empty, and the linker will either leave them empty for the loader
to ignore or remove them entirely.
Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
Graeme Russ [Tue, 27 Nov 2012 15:38:36 +0000 (15:38 +0000)]
x86: Put global data on the stack
Putting global data on the stack simplifies the init process (and makes it
slightly quicker). During the 'flash' stage of the init sequence, global
data is in the CAR stack. After SDRAM is initialised, global data is copied
from CAR to the SDRAM stack
Signed-off-by: Graeme Russ <graeme.russ@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Andy Fleming [Wed, 31 Oct 2012 19:02:38 +0000 (19:02 +0000)]
mmc: Properly determine maximum supported bus width
At some point, a confusion arose about the use of the bit
definitions in host_caps for bus widths, and the value
in ext_csd. By coincidence, a simple shift could convert
between one and the other:
However, as host_caps is a bitmask of supported things,
there is not, in fact, a one-to-one correspondence. host_caps
is capable of containing MODE_4BIT | MODE_8BIT, so nonsensical
things were happening where we would try to set the bus width
to 12.
The new code clarifies the very different namespaces:
host_caps/card_caps = bitmask (MMC_MODE_*)
ext CSD fields are just an index (EXT_CSD_BUS_WIDTH_*)
mmc->bus_width integer number of bits (1, 4, 8)
We create arrays to map between the namespaces, like in Linux.
Signed-off-by: Andy Fleming <afleming@freescale.com> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Tested-by: Stephen Warren <swarren@nvidia.com>
Taylor Hutt [Thu, 22 Nov 2012 09:13:00 +0000 (09:13 +0000)]
mmc: Fix incorrect handling of 'read' & 'write' commands
If a malformed 'read' or 'write' command is issued, the Sandbox U-Boot
can crash because the command-handling code does no error checking on
the number of provided arguments.
This change makes the mmc 'erase', 'read' and 'write' commands only
function if the proper number of arguments are supplied.
Also puts the else assignment at the beginning fo the if() statement
to shortens the generated code. This removes an unnecessary jump from
the generated code.
Signed-off-by: Taylor Hutt <thutt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Andy Fleming <afleming@freescale.com>
Stephen Warren [Tue, 6 Nov 2012 11:27:30 +0000 (11:27 +0000)]
mmc: tegra: use bounce buffer APIs
Tegra's MMC driver does DMA, and hence needs cache-aligned buffers. In
some cases (e.g. user load commands) this cannot be guaranteed by callers
of the MMC APIs. To solve this, modify the Tegra MMC driver to use the
new bounce_buffer_*() APIs.
Note: Ideally, all U-Boot code will always provide address- and size-
aligned buffers, so a bounce buffer will only ever be needed for user-
supplied buffers (e.g. load commands). Ensuring this removes the need
for performance-sucking bounce buffer cache management and memcpy()s.
The one known exception at present is the SCR buffer in sd_change_freq(),
which is only 8 bytes long. Solving this requires enhancing struct
mmc_data to know the difference between buffer size and transferred data
size, or forcing all callers of mmc_send_cmd() to have allocated buffers
using ALLOC_CACHE_ALIGN_BUFFER(), which while true in this case, is not
enforced in any way at present, and so cannot be assumed by the core MMC
code.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Andy Fleming <afleming@freescale.com>
Stephen Warren [Tue, 6 Nov 2012 11:27:29 +0000 (11:27 +0000)]
common: rework bouncebuf implementation
The current bouncebuf API requires all parameters to be passed to both
bounce_buffer_start() and bounce_buffer_stop(). Modify the bouncebuf
start function to accept a state structure as a parameter, and only
require that state struct to be passed to the stop function. This
simplifies usage of the bounce buffer by clients.
Don't modify the data pointer, but rather store the temporary buffer in
this state struct. The bouncebuf code ensures that client code can
always use a single buffer pointer in the state structure, irrespective
of whether a bounce buffer actually had to be allocated.
Move cache management logic into the bounce buffer code, so that each
client doesn't have to duplicate this. I believe there's no need to
invalidate the buffer before a DMA operation, since flushing the cache
should prevent any write-backs.
Update the MXS MMC driver for this change.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Andy Fleming <afleming@freescale.com>
Stephen Warren [Tue, 6 Nov 2012 11:27:28 +0000 (11:27 +0000)]
bouncebuf: remove dummy implementation
If any driver ever needs to use the bounce buffer API, it always needs
to use it. As such, providing a dummy implementation of those APIs when
CONFIG_BOUNCE_BUFFER isn't defined does not make sense. Remove the dummy
implementation.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Andy Fleming <afleming@freescale.com>
Stephen Warren [Tue, 6 Nov 2012 11:27:27 +0000 (11:27 +0000)]
Replace CONFIG_MMC_BOUNCE_BUFFER with CONFIG_BOUNCE_BUFFER in configs
Commits 6dc71c8 "MMC: MXS: Toggle the generic bounce buffer on the
boards" and 49a627f "MMC: Remove the MMC bounce buffer" replaced
CONFIG_MMC_BOUNCE_BUFFER with CONFIG_BOUNCE_BUFFER, but missed
converting a few boards over to the new option. Fix this.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Andy Fleming <afleming@freescale.com>
Some HW balks when writing both voltage setting and power up at the same
time to SDHCI_POWER_CONTROL register.
Signed-off-by: Rommel G Custodio <sessyargc@gmail.com> CC: Andy Fleming <afleming@freescale.com>
v2: fix attribution and SOB Signed-off-by: Andy Fleming <afleming@freescale.com>
This patch adds a NAND Flash torture feature, which is useful as a block stress
test to determine if a block is still good and reliable (or should be marked as
bad), e.g. after a write error.
This code is ported from mtd-utils' lib/libmtd.c.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com> Cc: Scott Wood <scottwood@freescale.com>
[scottwood@freescale.com: removed unnec. ifdef and unwrapped error strings] Signed-off-by: Scott Wood <scottwood@freescale.com>
driver/mtd:IFC NAND:Initialise internal SRAM before any write
IFC-1.1.0 uses 28nm techenology for SRAM. This tech has known limitaion for
SRAM i.e. "byte select" is not supported. Hence Read Modify Write is
implemented in IFC for any "system side write" into sram buffer. Reading an
uninitialized memory results in ECC Error from sram wrapper.
Hence we must initialize/prefill SRAM buffer by any data before writing
anything in SRAM from system side. To initialize SRAM user can use "READID"
NAND command with read bytes equal to SRAM size. It will be a one time
activity post boot
Scott Wood [Fri, 12 Oct 2012 23:02:24 +0000 (18:02 -0500)]
powerpc/mpc85xx/p2020rdb-pca: Use L2 SRAM for SPL boot
This allows DDR configuration to be deferred to the final U-Boot image,
which is able to make use of SPD data. The SPL itself cannot use SPD due
to code size constraints. It previously used fixed register values for
DDR configuration, and those values did not work on the p2020rdb-pca
board I tested with. It's possible that different revisions of the board
require different settings. Using SPD eliminates that problem.
Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: Andy Fleming <afleming@freescale.com>
Scott Wood [Wed, 3 Oct 2012 00:35:18 +0000 (19:35 -0500)]
powerpc/mpc85xx/p1_p2_rdb_pc: clean up memory map
- Sort by address, and fix column alignment
- Don't label things as localbus that aren't. Instead, put chipselect
info at the end of the description for localbus windows. Note that
NAND/NOR have their chipselects swapped when booting from NAND, and CS2
can be either PMC or VSC7385 depending on hwconfig.
- Shrink NAND to the 32K that's actually mapped in the localbus
- Assign an address and size to L2 SRAM. Remove the similarly named
but unintelligible "L2 SDRAM(REV.)".
- Remove the untrue comment about L1 stack being mapped with TLB0.
Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: Andy Fleming <afleming@freescale.com>
Scott Wood [Fri, 21 Sep 2012 23:35:27 +0000 (18:35 -0500)]
spl/nand: config symbol documentation
Document parameters used for specifying the NAND image to be loaded.
Also fix the definition of CONFIG_SPL_NAND_SIMPLE -- it's only
nand_spl_simple.c, not the entire nand directory. The word "simple" is
there for a reason. :-)
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
v2: updated for makefile changes earlier in patchset
Scott Wood [Fri, 21 Sep 2012 00:09:07 +0000 (19:09 -0500)]
spl/nand: introduce CONFIG_SPL_NAND_DRIVERS, _BASE, and _ECC.
Some small SPLs do not use nand_base.c, and a subset of those also
require a special driver. Some SPLs need software ECC but others can't
fit it.
All existing boards that specify CONFIG_SPL_NAND_SUPPORT have these
symbols added to preserve existing behavior.
Signed-off-by: Scott Wood <scottwood@freescale.com>
--
v2: use positive logic for including bits of NAND, rather than
a MINIMAL symbol that excludes things.
Scott Wood [Fri, 21 Sep 2012 00:02:18 +0000 (19:02 -0500)]
spl/85xx: new SPL support
Update CONFIG_RAMBOOT and CONFIG_NAND_SPL references to accept CONFIG_SPL
and CONFIG_SPL_BUILD, respectively. CONFIG_NAND_SPL can be removed once
the last mpc85xx nand_spl target is gone.
CONFIG_RAMBOOT will need to remain for other use cases, but it doesn't
seem right to overload it for meaning SPL as well as nand_spl does. Even
if it's somewhat appropriate for the main u-boot, the SPL itself isn't
(necessarily) ramboot, and we don't have separate configs for SPL and
main u-boot. It was also inconsistent, as other platforms such as
mpc83xx didn't use CONFIG_RAMBOOT in this way.
Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: Andy Fleming <afleming@freescale.com>
Scott Wood [Thu, 20 Sep 2012 21:35:21 +0000 (16:35 -0500)]
spl/powerpc: introduce CONFIG_SPL_INIT_MINIMAL
cpu_init_nand.c is renamed to spl_minimal.c as it is not really NAND-specific.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
v2: factor out START, and change cpu_init_nand.c to spl_minimal.c Cc: Andy Fleming <afleming@freescale.com>
Scott Wood [Sat, 18 Aug 2012 00:46:29 +0000 (19:46 -0500)]
spl/mpc85xx: move udelay to cpu code
It applies to non-Freescale 85xx boards as well as Freescale boards,
so it doesn't belong in board/freescale. Plus, it needs to come out
of nand_spl if it's to be used by the new SPL.
Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: Andy Fleming <afleming@freescale.com>
Scott Wood [Thu, 20 Sep 2012 23:34:49 +0000 (18:34 -0500)]
powerpc/mpc85xx: fix TLB alignment
In the RAMBOOT/SPL case we were creating a TLB entry starting at
CONFIG_SYS_MONITOR_BASE, and just hoping that the base was properly
aligned for the TLB entry size. This turned out to not be the case
with NAND SPL because the main U-Boot starts at an offset into the image
in order to skip the SPL itself.
Fix the TLB entry to always start at a proper alignment. We still assume that
CONFIG_SYS_MONITOR_BASE doesn't start immediately before a large-page boundary
thus requiring multiple TLB entries.
Signed-off-by: Scott Wood <scottwood@frescale.com> Cc: Andy Fleming <afleming@freescale.com>
Scott Wood [Fri, 21 Sep 2012 00:10:01 +0000 (19:10 -0500)]
powerpc: change .fixup test to a GCC version test
This was introduced by commit 244615197469dd6fe75ae082f38424b97c79aeaf, but it
fails in a minimal SPL build where the only thing in arch/powerpc/lib is
cache.c, which apparently doesn't generate any fixup records.
The problem is reported to occur with GCC 3.x, so insist on GCC 4.0 or newer.
Patterned after checkthumb as suggested by Tom Rini.
Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: Peter Tyser <ptyser@xes-inc.com> Cc: Tom Rini <trini@ti.com>
--
v2: test gcc version instead of testing nothing
Scott Wood [Fri, 21 Sep 2012 21:27:32 +0000 (16:27 -0500)]
spl: introduce CONFIG_SPL_TARGET
Currently the SPL target is specified in a CPU-specific makefile
fragment. While some targets may need something more complicated than a
simple target name, targets which don't need this shouldn't have to provide a makefile fragment just for this.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
v2: Removed default target as it's been pointed out to me how existing platforms
cause the SPL to be built.
Samsung's S3C24XX SoCs need this in order to generate a binary image
with a padded SPL concatenated with U-Boot.
Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt>
[scottwood@freescale.com: fixed prereq of u-boot.ubl] Signed-off-by: Scott Wood <scottwood@freescale.com>
--
v2: Removed spl/ prefix from u-boot.ubl prerequisite.
Scott Wood [Fri, 26 Oct 2012 00:27:41 +0000 (19:27 -0500)]
powerpc/mpc85xx: move debug tlb entry after TLB is in known state
Previously, in many if not all configs we were creating overlapping TLB entries
which is illegal. This caused a crash during boot when moving p2020rdb NAND SPL
into L2 SRAM.
Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: Prabhakar Kushwaha <prabhakar@freescale.com> Cc: Andy Fleming <afleming@freescale.com>
--
Prabhakar, please test that debug still works.
Scott Wood [Tue, 18 Sep 2012 23:19:05 +0000 (18:19 -0500)]
serial/ns16550: wait for TEMT before initializing
TEMT is set when the transmitter is totally empty and all output has
finished.
This prevents output problems (including a loss of synchronization
observed on p2020 that persisted for quite a while) if SPL has output
still on its way out.
Signed-off-by: Scott Wood <scottwood@freescale.com>
--
v2: fixed typo in subject, and explained what the bit does in the changelog
Scott Wood [Tue, 16 Oct 2012 20:43:15 +0000 (15:43 -0500)]
serial/ns16550: don't build serial_ns16550 with MIN_FUNCTIONS
CONFIG_NS16550_MIN_FUNCTIONS is used by small SPLs to gain access to basic
ns16550 output code without pulling in things not needed by the SPL.
This previously only worked with non-MULTI configs. Recently MULTI was
made mandatory, and MIN_FUNCTIONS fails like this:
drivers/serial/libserial.o: In function `calc_divisor.clone.0':
serial_ns16550.c:(.text.calc_divisor.clone.0+0x24): undefined reference to `get_bus_freq'
drivers/serial/libserial.o: In function `_serial_getc':
(.text._serial_getc+0x30): undefined reference to `NS16550_getc'
drivers/serial/libserial.o: In function `_serial_tstc':
(.text._serial_tstc+0x30): undefined reference to `NS16550_tstc'
drivers/serial/libserial.o: In function `_serial_setbrg':
(.text._serial_setbrg+0x3c): undefined reference to `NS16550_reinit'
make[1]: *** [/tmp/u-boot/spl/u-boot-spl] Error 1
make: *** [/tmp/u-boot/spl/u-boot-spl.bin] Error 2
With MIN_FUNCTIONS we don't need anything from this file, so don't build
it. The conditional needs to be in the file itself rather than the
makefile, because the config symbols are only imported to the makefiles
once, not separately for the SPL phase of the build.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Zhi-zhou Zhang [Sat, 24 Nov 2012 05:07:13 +0000 (05:07 +0000)]
MIPS: do not initialize timestamp variable before relocate_code
Because timestamp is declared as `static', we needn't initialize
it by writing it a zero. If we do it before relocate_code, we
will write into a flash address(0xffffffffbfc0xxxx).
Signed-off-by: Zhi-zhou Zhang <zhizhou.zh@gmail.com> Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
By commit c7e3b2b5, this was chanded to support multiple controllers.
But this has missing of parenthesis. This commit fix it.
-----
r8a66597-hcd.c: In function ‘usb_lowlevel_init’:
r8a66597-hcd.c:911:52: error: expected declaration specifiers before ‘)’
token
r8a66597-hcd.c:935:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or‘__attribute__’ before ‘{’ token
r8a66597-hcd.c:939:1: error: expected ‘{’ at end of input
-----
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> CC: Lucas Stach <dev@lynxeye.de>
Ilya Yanok [Tue, 6 Nov 2012 13:48:25 +0000 (13:48 +0000)]
musb-new: am35x backend driver
Backend driver for MUSB OTG controllers found on TI AM35x.
It seems that on AM35X interrupt status registers can be updated
_before_ core registers. As we don't use true interrupts in U-Boot
and poll interrupt status registers instead this can result in
interrupt handler being called with non-updated core registers.
This confuses the code and result in hanged transfers.
Add a small delay in am35x_interrupt as a workaround.
Ilya Yanok [Tue, 6 Nov 2012 13:48:21 +0000 (13:48 +0000)]
musb-new: port of Linux musb driver
Existing U-Boot musb driver has no support for the new gadget framework
and also seems to have other limitations. As gadget framework is ported
from Linux it seems pretty natural to port musb gadget driver as well.
This driver supports both host and peripheral modes.
This is not a replacement for current musb driver (at least now) as
there are still some consumers of the old UDC interface.
No DMA operation support included, CONFIG_MUSB_PIO_ONLY should be
defined.
Virtual root hub device is not implemented.
Known problems: with no devices connected usb_lowlevel_start() fails.
Ilya Yanok [Tue, 6 Nov 2012 13:48:20 +0000 (13:48 +0000)]
usb: use linux/usb/ch9.h instead of usbdescriptors.h
Linux usb/ch9.h seems to have all the same information (and more)
as usbdescriptors.h so use the former instead of the later one.
As a consequense of this change USB_SPEED_* values don't correspond
directly to EHCI speed encoding anymore, I've added necessary
recoding in EHCI driver. Also there is no point to put speed into
pipe anymore so it's removed and a bunch of host drivers fixed to
look at usb_device->speed instead.
Old usbdescriptors.h included is not removed as it seems to be
used by old USB device code.
This makes usb.h and usbdevice.h incompatible. Fortunately the
only place that tries to include both are the old MUSB code and
it needs usb.h only for USB_DMA_MINALIGN used in aligned attribute
on musb_regs structure but this attribute seems to be unneeded
(old MUSB code doesn't support any DMA at all).
Allen Martin [Tue, 6 Nov 2012 21:26:03 +0000 (13:26 -0800)]
USB: add arrow key support to usb_kbd
Check for scancodes for arrow keys and map them to ^F/^B, ^N/^P.
Control characters are used instead of ANSI sequence because the
queueing code in usb_kbd doesn't handle the data increase when one
keypress generates 3 keycodes. The real fix is to convert this driver
to use the input subsystem and queue, but this allows arrow keys to
work until this driver is converted.
Allen Martin [Wed, 24 Oct 2012 08:32:04 +0000 (08:32 +0000)]
USB: make usb_kbd obey USB DMA alignment requirements
Change usb_kbd driver to obey alignment requirements for USB DMA on
the buffer used for data transfer. This is necessary for
architectures that enable dcache and enable USB DMA.
Signed-off-by: Allen Martin <amartin@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com>
Alejandro Mery [Wed, 31 Oct 2012 08:21:33 +0000 (08:21 +0000)]
fs: zfs: fix illegal use of fp
the upcoming sunxi (allwinner a10/a13) platform enables zfs
by default, and using linaro's hf -msoft-float makes the build
fail because this u64 division.
Signed-off-by: Alejandro Mery <amery@geeks.cl> Acked-by: Stefan Roese <sr@denx.de>
M68K: eb_cpu5282: general update and enhanced board support
- update clock settings for higher perfomance
- change standard baud rate to 115200
- fix flash base address
- remove unused defines
- add I2C support
- switch form board dependent flash to cfi
- remove board dependent flash code
- use sdram bank 0 instead of bank 1 on boot
- enable on board frame buffer instead external
- remove fake mac address form config
- add watchdog support
- add status led support
Signed-off-by: Jens Scharsig (BuS Elektronik) <esw@bus-elektronik.de>
[agust: fixed small style issues and build warning] Signed-off-by: Anatolij Gustschin <agust@denx.de>
Łukasz Majewski [Tue, 13 Nov 2012 03:22:12 +0000 (03:22 +0000)]
pmic: Extend PMIC framework to support battery related commands
Two extra commands:
"pmic name bat state" and "pmic name bat charge" has been added to
pmic framework. Those provides state display and charge capabilities
to named batteries.
The pmic_core.c file has been refactored to more consistent name scheme.
Łukasz Majewski [Tue, 13 Nov 2012 03:22:03 +0000 (03:22 +0000)]
pmic:fuel-gauge: Support for MAX17042 fuel-gauge
Support for MAX17042 fuel-gauge (FG), which is built into the MAX8997
power management device.
Special file - fg_battery_cell_params.h with cells characteristics
added.
The FG device will work with redesigned PMIC framework.
Łukasz Majewski [Tue, 13 Nov 2012 03:22:01 +0000 (03:22 +0000)]
pmic:battery: Support for Trats Battery at PMIC framework
Trats battery is now treated in the same way as other power related
devices. This approach allows for more unified handling of all devices
responsible for power management.
projects / u-boot.git / log
;st=author){kind=link}
