Suriyan Ramasami [Thu, 27 Nov 2014 21:24:16 +0000 (13:24 -0800)]
fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined
The boot commands - bootz/bootm mandate a third argument which is the
address to the FDT blob. In cases where this argument is not specified,
boot fails with a message indicating a missing FDT.
This causes non-FDT kernels to fail to boot. This patch allows both FDT
and non-FDT kernels to boot by making the third parameter to the bootm/bootz
optional.
Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
[trini: Update again for covering appended DTB case after last revert in
this area] Signed-off-by: Tom Rini <trini@ti.com>
Introduce a Makefile under arch/$ARCH/ and include it in the
top Makefile (similar to Linux kernel). This allows further
refactoringi like moving architecture-specific code out of global
makefiles, deprecating config variables (CPU, CPUDIR, SOC) or
deprecating arch/$ARCH/config.mk.
In contrary to Linux kernel, U-Boot defines the ARCH variable by
Kconfig, thus the arch Makefile can only included conditionally
after the top config.mk.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Acked-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Vikas Manocha [Fri, 21 Nov 2014 18:34:21 +0000 (10:34 -0800)]
serial: pl01x: move all line control at same place
Receive line control uses same setting as transmit line control, also one lcrh
write is effective for both baud rate & receive line control internal update.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com> Acked-by: Simon Glass <sjg@chromium.org>
Vikas Manocha [Fri, 21 Nov 2014 18:34:20 +0000 (10:34 -0800)]
serial: pl01x: fix pl011 baud rate configuration
UART_IBRD, UART_FBRD, and UART_LCR_H form a single 30-bit wide register which
is updated on a single write strobe generated by a UART_LCR_H write. So, to
internally update the content of UART_IBRD or UART_FBRD, a write to UART_LCR_H
must always be performed at the end.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com> Acked-by: Simon Glass <sjg@chromium.org>
The CPU directory of this board is arch/powerpc/cpu/mpc5xxx.
Without the CONFIG_SPL_START_S_PATH and CONFIG_SPL_LDSCRIPT defines,
the same start.o and u-boot-spl.lds are selected by default.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Stefan Roese <sr@denx.de> Acked-by: Stefan Roese <sr@denx.de>
The CPU directory of this board is arch/powerpc/cpu/ppc4xx.
Without the CONFIG_SPL_START_S_PATH and CONFIG_SPL_LDSCRIPT defines,
the same start.o and u-boot-spl.lds are selected by default.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Wolfgang Denk <wd@denx.de> Acked-by: Stefan Roese <sr@denx.de>
Masahiro Yamada [Fri, 21 Nov 2014 02:26:11 +0000 (11:26 +0900)]
powerpc: mpc8xx: remove hermes board support
This board sprinkles #ifdef(CONFIG_HERMES) over various global files
such as include/common.h, common/board_r.c, common/cmd_bdinfo.c.
Let's zap such an ill-behaved board.
It has not been converted to generic board yet and mpc8xx is old
enough.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Wolfgang Denk <wd@denx.de> Acked-by: Wolfgang Denk <wd@denx.de>
Hector Palacios [Thu, 20 Nov 2014 08:27:42 +0000 (09:27 +0100)]
cmd_fuse: return CMD_RET_FAILURE on error
Fuse drivers, like the mxs_ocotp.c, may return negative error codes but
the commands are only allowed to return CMD_RET_* enum values to the
shell, otherwise the following error appears:
Stephen Warren [Thu, 20 Nov 2014 03:41:04 +0000 (20:41 -0700)]
ARM: rpi: support an environment
Enable ENV_IS_IN_FAT so that the environment can be stored persistently.
It's stored in the FAT partition that the RPi firmware requires. On most
RPis, this is on the SD card (which must be present in order for the
system to boot). On the CM this is on the built-in eMMC device.
Since we now have a persistent environment, there's no need to load
uEnv.txt at boot; we only did that to work around the lack of persistent
environment.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
Stephen Warren [Wed, 19 Nov 2014 04:40:21 +0000 (21:40 -0700)]
ARM: rpi_b: detect board revision
Detect the board revision early during boot, and print the decoded
model name.
Eventually, this information can be used for tasks such as:
- Allowing/preventing USB device mode; some models have a USB device on-
board so only host mode makes sense. Others connect the SoC directly
to the USB connector, so device-mode might make sense.
- The on-board USB hub/Ethernet requires different GPIOs to enable it,
although luckily the default appears to be fine so far.
- The compute module contains an on-board eMMC device, so we could store
the environment there. Other models use an SD card and so don't support
saving the environment (unless we store it in a file on the FAT boot
partition...)
Set $fdtfile based on this information. At present, the mainline Linux
kernel doesn't contain a separate DTB for most models, but I hope that
will change soon.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
Wu, Josh [Tue, 18 Nov 2014 05:07:08 +0000 (13:07 +0800)]
net: bootp: as CONFIG_BOOTP_SERVERIP is defined, keep bootfile not changed
Currenly when CONFIG_BOOTP_SERVERIP is defined, the SERVERIP is not changed
when receive the BOOTP packet. But BOOTFILE is changed via BOOTP packet.
As we will load the BOOTFILE from SERVERIP, if the BOOTFILE is modified
by bootp packet but SERVERIP is not, that is not make sense.
This patch make SERVERIP and BOOTFILE be consistent. If we define the
CONFIG_BOOTP_SERVERIP, then SERVERIP and BOOTFILE will not changed by
BOOTP packet. Only IP address is changed.
get_maintainer.pl always fails with following message:
./scripts/get_maintainer.pl: The current directory does not appear to be a linux kernel source tree.
We use MAINTAINERS for the maintainership of the supported boards.
For dead boards, we have some clues in doc/README.scrapyard and
also imperishable history in git-log.
Remove CREDITS from source tree detection to fix this.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 14 Nov 2014 03:51:12 +0000 (20:51 -0700)]
Fix console functions for U-Boot API
Commit 709ea54 made a subtle change to the way the U-Boot API jump table
is set up. So at present putc(), getc(), tstc() and puts() do not work
correctly from functions that use the U-Boot API.
Previously these were set to the stdio functions, but these now take a
parameter specifying which stdio device to use. Instead, we should change
them to use the global functions which do not have a parameter.
This is a slight change in behaviour. The functions will now output to
all selected stdio devices - for example putc() will output a character to
all devices selected by stdout. However in most cases there is only one,
and it isn't necessarily incorrect behaviour anyway.
The API version is not changed since it is compatible with what was there
before.
Reported-by: Martin Dorwig <dorwig@tektronik.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Raw images of U-Boot can be stored inside MMC partitions, so it makes sense to
read the partition table, looking for a partition number instead of using
a fixed sector address.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@ti.com>
[trini: Only add mmc_load_image_raw_partition() when
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to avoid warning, add missing
conversion in spl_mmc_load_image()] Signed-off-by: Tom Rini <trini@ti.com>
CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION ought to be called
CONFIG_SYS_MMCSD_FS_BOOT_PARTITION to keep it consistent with other config
options such as: CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR.
In addition, it is not related to raw mode booting but to fs mode instead.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@ti.com>
Tom Rini [Mon, 24 Nov 2014 16:50:46 +0000 (11:50 -0500)]
fs/ext4/ext4fs.c, fs/fs.c fs/fat/fat_write.c: Adjust 64bit math methods
The changes to introduce loff_t into filesize means that we need to do
64bit math on 32bit platforms. Make sure we use the right wrappers for
these operations.
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Cc: Suriyan Ramasami <suriyan.r@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@ti.com> Tested-by: Pierre Aubert <p.aubert@staubli.com>
Hans de Goede [Fri, 28 Nov 2014 13:23:51 +0000 (14:23 +0100)]
fdt: Fix regression in fdt_pack_reg()
After commit 933cdbb479: "fdt: Try to use fdt_address_cells()/fdt_size_cells()"
I noticed that allwinner boards would no longer boot.
Switching to fdt_address_cells / fdt_size_cells changes the result from
bytes to 32 bit words, so when we increment pointers into the blob, we must
do so by 32 bit words now.
This commit makes allwinner boards boot again.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de> Tested-by: Vince Hsu <vinceh@nvidia.com>
Masahiro Yamada [Wed, 26 Nov 2014 09:34:01 +0000 (18:34 +0900)]
usb: UniPhier: support OF configuration
If CONFIG_OF_CONTROL is defined, search device tree nodes that are
compatible with "panasonic,uniphier-ehci" and take the base address
from their "reg" property.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Marek Vasut <marex@denx.de>
Masahiro Yamada [Wed, 26 Nov 2014 09:33:58 +0000 (18:33 +0900)]
ARM: UniPhier: add dummy gpio.h to enable CONFIG_OF_CONTROL
If CONFIG_OF_CONTROL is enabled, lib/fdtdec.c is compiled.
It includes <asm/gpio.h> and then <asm/gpio.h> includes
<asm/arch/gpio.h>. Consequently, all the SoCs that enable
CONFIG_OF_CONTROL must have <asm/arch/gpio.h> even if they do not
support GPIO.
In the first place, GPIO has nothing to do with OF_CONTROL.
It is wrong that lib/fdtdec.c includes GPIO functions; it should
be split into two files, FDT-common things and GPIO things.
It is, however, a pretty big work to fix that correctly.
This is a compromised commit to add a dummy <asm/arch/gpio.h>
to support OF_CONTROL for UniPhier platform. This dummy header
will be removed after FDT-GPIO stuff is fixed correctly.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Reviewed-by: Simon Glass <sjg@chromium.org>
The initramfs is currently only relocated if the user calls
the bootm ramdisk subcommand. If bootm should be used without
subcommands, the arch-specific bootm code needs to implement
the relocation.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
To get correct stack walking and backtrace functionality in gdb,
registers fp and ra should be initialized before calling board_init_f
or board_init_r. Thus allocating stack space and zeroing it as it is
currently done in board.c becomes obsolete.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Marek Vasut [Sat, 11 Oct 2014 16:42:52 +0000 (18:42 +0200)]
mtd: nand: s3c: Unify the register definition and naming
Merge struct s3c2410_nand and struct s3c2440_nand into one unified
struct s3c24x0_nand. While at it, fix up and rename the functions
to retrieve the NAND base address and fix up the s3c NAND driver to
reflect this change.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Minkyu Kang <mk7.kang@samsung.com> Cc: Scott Wood <scottwood@freescale.com> Cc: Vladimir Zapolskiy <vz@mleia.com>
Simon Glass [Thu, 16 Oct 2014 07:05:56 +0000 (01:05 -0600)]
buildman: Don't default to -e when building current source
We probably don't need to enable this option by default. It is useful to
display only failure boards (not errors) and it is easy to add -e if it
is required. Also update the docs.
Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Albert Aribaud <albert.u.boot@aribaud.net>
Sanchayan Maity [Mon, 24 Nov 2014 05:33:59 +0000 (11:03 +0530)]
mtd/nand/vf610_nfc: Disable subpage writes
This patch disables subpage writes for vf610_nfc nand
driver. This is required, as without this fix, writing
unaligned u-boot images with DFU results in a hang.
Trying to write unalgined binary images also results
in a hang, without disabling subpage writes.
Masahiro Yamada [Thu, 13 Nov 2014 11:31:51 +0000 (20:31 +0900)]
mtd: denali: set some registers after nand_scan_ident()
Some but not all of implementations of the Denali NAND controller
have hardware circuits to detect the device parameters such as
page_size, erase_size, etc. Even on those SoCs with such hardware
supported, the hardware is known to detect wrong parameters for some
nasty (almost buggy) NAND devices. The device parameters detected
during nand_scan_ident() are more trustworthy.
This commit sets some hardware registers to mtd->pagesize,
mtd->oobsize, etc. in the code between nand_scan_ident() and
nand_scan_tail().
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Scott Wood <scottwood@freescale.com> Cc: Chin Liang See <clsee@altera.com>
Masahiro Yamada [Thu, 13 Nov 2014 11:31:50 +0000 (20:31 +0900)]
mtd: denali: use CONFIG_SYS_NAND_SELF_INIT
Some variants of the Denali NAND controller need some registers
set up based on the device information that has been detected during
nand_scan_ident().
CONFIG_SYS_NAND_SELF_INIT has to be defined to insert code between
nand_scan_ident() and nand_scan_tail(). It is also helpful to reduce
the difference between this driver and its Linux counterpart because
this driver was ported from Linux. Moreover, doc/README.nand recommends
to use CONFIG_SYS_NAND_SELF_INIT.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Scott Wood <scottwood@freescale.com> Cc: Chin Liang See <clsee@altera.com>
Simon Glass [Sat, 15 Nov 2014 03:56:42 +0000 (20:56 -0700)]
bios_emulator: Add an option to enable debugging
At present there are DEBUG options spread around the place. If you enable
one and not another you can end up with an emulator that does not work,
since each file can have a different view of what the registers look like.
To fix this, create a global CONFIG_X86EMU_DEBUG option that keeps
everything consistent.
Simon Glass [Sat, 15 Nov 2014 03:56:40 +0000 (20:56 -0700)]
bios_emulator: Add vesa support and allow ROMs to be passed in as data
As well as locating the ROM on the PCI bus, allow the ROM to be supplied to
the emulator. Split the init up a little so that callers can supply their
own interrupt routines. Also allow a vesa mode to be provided, to be
selected once the BIOS run is complete.
Simon Glass [Sat, 15 Nov 2014 03:56:39 +0000 (20:56 -0700)]
bios_emulator: Allow x86 to use the emulator
There is an implicit assumption that x86 machines want to use raw I/O in the
BIOS emulator, but this should be selectable. Add an CONFIG_X86EMU_RAW_IO
option to control it instead.
Also fix a few bugs which cause warnings on x86 and adjust the Makefile to
remove the assumption that only PowerPC uses the emulator.
Simon Glass [Sat, 15 Nov 2014 03:56:36 +0000 (20:56 -0700)]
x86: Add initial video device init for Intel GMA
Intel's Graphics Media Accelerator (GMA) is a generic name for a wide range
of video devices. Add code to set up the hardware on ivybridge. Part of the
init happens in native code, part of it happens in a 16-bit option ROM for
those nostalgic for the 1970s.
Simon Glass [Sat, 15 Nov 2014 03:56:35 +0000 (20:56 -0700)]
x86: Allow an option ROM to be built into U-Boot
Some x86 machines require a binary blob containing 16-bit initialisation
code for their video hardware. Allow this to be built into the x86 ROM so
that it is accessible during boot.
Simon Glass [Sat, 15 Nov 2014 03:56:33 +0000 (20:56 -0700)]
pci: Add general support for execution of video ROMs
Some platforms don't have native code for dealing with their video
hardware. In some cases they use a binary blob to set it up and perform
required actions like setting the video mode. This approach is a hangover
from the old PC days where a ROM was provided and executed during startup.
Even now, these ROMs are supplied as a way to set up video. It avoids the
code for every video chip needing to be provided in the boot loader. But
it makes the video much less flexible - e.g. it is not possible to do
anything else while the video init is happening (including waiting hundreds
of milliseconds for display panels to start up).
In any case, to deal with this sad state of affairs, provide an API for
execution of x86 video ROMs, either natively or through emulation.
Simon Glass [Sat, 15 Nov 2014 03:56:32 +0000 (20:56 -0700)]
x86: Add support for running option ROMs natively
On x86 machines we can use an emulator to run option ROMS as with other
architectures. But with some additional effort (mostly due to the 16-bit
nature of option ROMs) we can run them natively. Add support for this.
Bin Meng [Thu, 20 Nov 2014 08:11:16 +0000 (16:11 +0800)]
x86: Refactor interrupt_init()
Rename interrupt_init() in arch/x86/lib/pcat_interrupts.c to
i8259_init() and create a new interrupt_init() in
arch/x86/cpu/interrupt.c to call i8259_init() followed by a
call to cpu_init_interrupts().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Thu, 20 Nov 2014 08:10:49 +0000 (16:10 +0800)]
x86: Call cpu_init_interrupts() from interrupt_init()
Currently cpu_init_interrupts() is called from cpu_init_r() to
setup the interrupt and exception of the cpu core, but at that
time the i8259 has not been initialized to mask all the irqs
and remap the master i8259 interrupt vector base, so the whole
system is at risk of being interrupted, and if interrupted,
wrong interrupt/exception message is shown.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
projects / u-boot.git / log