Age | Commit message (Collapse) | Author |
|
Most OMAP3 boards have various flash related macros in their configs
that are either not referenced anywhere in the code or are used by
drivers that are not enabled. Remove them.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Acked-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
|
|
map
Fix the build breakage introduced by the recent relocation
and memory layout changes for ARM.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
|
|
DECLARE_GLOBAL_DATA_PTR is currently defined within the scope
of function while it is a global pointer. Change the scope of
definition to replicate it's global scope. This seems to help
gcc 4.5 optimizations as well.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
|
|
Having a loop with a counter is no timing guarentee for timing
accuracy or compiler optimizations. For e.g. the same loop counter
which runs when the MPU is running at 600MHz will timeout in around
half the time when running at 1GHz. or the example where GCC 4.5
compiles with different optimization compared to GCC 4.4. use timer
to keep track of time elapse and we use an emperical number - 1sec
for a worst case timeout. This should never happen, and is adequate
imaginary condition for us to fail with timeout.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
|
|
Fixes build breakage in da830evm after commit
97003756249bd790910417eb66f0039bbf06a02c "da8xx: fixup ARM
relocation support"
The da8xx fixup commit changed da830/da850 common code to make
relocation work in da850, but didn't add the required defines
to da830evm_config.h resulting in build failure in the common code.
This patch adds those defines for da830, but makes no sense without
also referring to the commit mentioned above.
Signed-off-by: Nick Thompson <nick.thompson@ge.com>
Reviewed-by: Ben Gardiner <bengardiner@nanometrics.ca>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously with archive libraries fdt.o was compiled and included in
qe.a and then discarded by the linker. With partial linking this
results in unresolved symbols, which this commit fixes.
This commit also cleans up a now-useless conditional in fdt.c.
Signed-off-by: Sebastien Carlier <sebastien.carlier@gmail.com>
Tested-by: Wolfgang Denk <wd@denx.de>
|
|
The Blackfin on-chip BootROM requires that fill operations (which is
used for the bss) be aligned to 4 bytes (base addr and total len).
Plus, the Blackfin early init asm code assumes the same thing. So
rather than making things work for no real gain, make sure the bss
len is padded to 4 bytes in the linker script.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
This lets the linker garbage collect these functions when they aren't
actually used by placing them into the standard .text.<func> section.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
If USE_PRIVATE_LIBGCC is set the yes building fails with a missing
libgcc.a As we use partial linking now it is libgcc.o now.
Signed-off-by: Matthias Weisser <weisserm@arcor.de>
|
|
Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
|
|
Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
|
|
ethernet frame reception.
Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
|
|
Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
|
|
Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
|
|
Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
|
|
Since we set #define MORECORE_CLEARS 1, the code assumes 'sbrk' always
returns zero'd out memory. However since its possible that free()
returns memory back to sbrk() via malloc_trim we could possible get
non-zero'd memory from sbrk(). This is a problem for when code might
call calloc() and expect the memory to have been zero'd out.
There are two possible solutions to this problem.
1. change #define MORECORE_CLEARS 0
2. memset to zero memory returned to sbrk.
We go with the second since the sbrk being called to free up memory
should be pretty rare.
The following code problems an example test to show the issue. This
test code was inserted right after the call to mem_malloc_init().
...
u8 *p2;
int i;
printf("MALLOC TEST\n");
p1 = malloc(135176);
printf("P1 = %p\n", p1);
memset(p1, 0xab, 135176);
free(p1);
p2 = calloc(4097, 1);
printf("P2 = %p %p\n", p2, p2 + 4097);
for (i = 0; i < 4097; i++) {
if (p2[i] != 0)
printf("miscompare at byte %d got %x\n", i, p2[i]);
free(p2);
printf("END MALLOC TEST\n\n");
...
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Tested-by: Wolfgang Denk <wd@denx.de>
|
|
Typo from 4b29bdb0ed08412d225a8be94f61fc6c37a59dd5
Signed-off-by: Matthew McClintock <msm@freescale.com>
|
|
Before this commit, weak symbols were not overridden by non-weak symbols
found in archive libraries when linking with recent versions of
binutils. As stated in the System V ABI, "the link editor does not
extract archive members to resolve undefined weak symbols".
This commit changes all Makefiles to use partial linking (ld -r) instead
of creating library archives, which forces all symbols to participate in
linking, allowing non-weak symbols to override weak symbols as intended.
This approach is also used by Linux, from which the gmake function
cmd_link_o_target (defined in config.mk and used in all Makefiles) is
inspired.
The name of each former library archive is preserved except for
extensions which change from ".a" to ".o". This commit updates
references accordingly where needed, in particular in some linker
scripts.
This commit reveals board configurations that exclude some features but
include source files that depend these disabled features in the build,
resulting in undefined symbols. Known such cases include:
- disabling CMD_NET but not CMD_NFS;
- enabling CONFIG_OF_LIBFDT but not CONFIG_QE.
Signed-off-by: Sebastien Carlier <sebastien.carlier@gmail.com>
|
|
|
|
older ld emitted all ELF relocations in input sections named
.rel.dyn, whereas newer ld uses names of the form .rel*. The
linker script only collected .rel.dyn input sections. Rewrite
to collect all .rel* input sections.
Signed-off-by: Albert Aribaud <albert.aribaud@free.fr>
|
|
older ld emitted all ELF relocations in input sections named
.rel.dyn, whereas newer ld uses names of the form .rel*. The
linker script only collected .rel.dyn input sections. Rewrite
to collect all .rel* input sections.
Signed-off-by: Albert Aribaud <albert.aribaud@free.fr>
|
|
If CONFIG_SYS_POST_I2C_ADDRS is not defined and CONFIG_SYS_POST_I2C
is activated, i2c_probe() is not called in the for statement,
because missing curly bracket.
Signed-off-by: Heiko Schocher <hs@denx.de>
|
|
Tested on upcoming hydra (mpc5200 based) board.
Signed-off-by: Heiko Schocher <hs@denx.de>
|
|
This has always been confusing, and the idea of these functions returning the
number of interfaces initialized was half-baked and ultimately pointless.
Instead, act more like regular functions and return < 0 on failure, >= 0 on
success.
This change shouldn't break anything.
Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
|
|
Reorder including config.mk before the HOSTCC check, so HOSTCC is
actually defined when checking for it.
Signed-off-by: François Revol <revol@free.fr>
Cleaned up commit message
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
Add a check to make sure that the user's arguments actually find a board
in boards.cfg. Previously, if a user misspelled an argument the
argument would be discarded without warning. For example, running
'MAKEALL -c 85xx' with the intention of compiling all Freescale 85xx
boards would instead silently discard the '-c 85xx' argument since the
proper cpu name is 'mpc85xx' and then proceed to compile all PowerPC
boards (MAKEALL's default).
Also fix an unrelated typo.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
|
|
When CONFIG_PCI_SCAN_SHOW is defined U-Boot prints out PCI devices as
they are found during bootup, eg:
PCIE1: connected as Root Complex
01:00.0 - 10b5:8518 - Bridge device
02:01.0 - 10b5:8518 - Bridge device
03:00.0 - 10b5:8112 - Bridge device
04:01.0 - 8086:1010 - Network controller
04:01.1 - 8086:1010 - Network controller
02:02.0 - 10b5:8518 - Bridge device
02:03.0 - 10b5:8518 - Bridge device
06:00.0 - 10b5:8518 - Bridge device
07:00.0 - 10b5:8518 - Bridge device
08:00.0 - 1957:0040 - Processor
07:01.0 - 10b5:8518 - Bridge device
09:00.0 - 10b5:8112 - Bridge device
07:02.0 - 10b5:8518 - Bridge device
PCIE1: Bus 00 - 0b
PCIE2: connected as Root Complex
0d:00.0 - 1957:0040 - Processor
PCIE2: Bus 0c - 0d
This information is useful, but its difficult to determine the PCI bus
topology. To things clearer, we can use indention to make it more
obvious how the PCI bus is organized. For the example above, the
updated output with this change is:
PCIE1: connected as Root Complex
01:00.0 - 10b5:8518 - Bridge device
02:01.0 - 10b5:8518 - Bridge device
03:00.0 - 10b5:8112 - Bridge device
04:01.0 - 8086:1010 - Network controller
04:01.1 - 8086:1010 - Network controller
02:02.0 - 10b5:8518 - Bridge device
02:03.0 - 10b5:8518 - Bridge device
06:00.0 - 10b5:8518 - Bridge device
07:00.0 - 10b5:8518 - Bridge device
08:00.0 - 1957:0040 - Processor
07:01.0 - 10b5:8518 - Bridge device
09:00.0 - 10b5:8112 - Bridge device
07:02.0 - 10b5:8518 - Bridge device
PCIE1: Bus 00 - 0b
PCIE2: connected as Root Complex
0d:00.0 - 1957:0040 - Processor
PCIE2: Bus 0c - 0d
In the examples above, an MPC8640 is connected to a PEX8518 PCIe switch
(01:00 and 02:0x), which is connected to another PEX8518 PCIe switch
(06:00 and 07:0x), which then connects to a MPC8572 processor (08:00).
Also, the MPC8640's PEX8518 PCIe switch is connected to a PCI ethernet
card (04:01) via a PEX8112 PCIe-to-PCI bridge (03:00).
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
|
|
Move the printing of PCI device information to before the PCI device is
configured. This prevents the case where recursive scanning results in
the deepest devices being printed first.
This change also makes PCI lockups during enumeration easier to
diagnose since the device that is being configured is printed out prior
to configuration. Previously, it was not possible to determine which
device caused the PCI lockup.
Original example:
PCIE1: connected as Root Complex
04:01.0 - 8086:1010 - Network controller
04:01.1 - 8086:1010 - Network controller
03:00.0 - 10b5:8112 - Bridge device
02:01.0 - 10b5:8518 - Bridge device
02:02.0 - 10b5:8518 - Bridge device
08:00.0 - 1957:0040 - Processor
07:00.0 - 10b5:8518 - Bridge device
09:00.0 - 10b5:8112 - Bridge device
07:01.0 - 10b5:8518 - Bridge device
07:02.0 - 10b5:8518 - Bridge device
06:00.0 - 10b5:8518 - Bridge device
02:03.0 - 10b5:8518 - Bridge device
01:00.0 - 10b5:8518 - Bridge device
PCIE1: Bus 00 - 0b
Updated example:
PCIE1: connected as Root Complex
01:00.0 - 10b5:8518 - Bridge device
02:01.0 - 10b5:8518 - Bridge device
03:00.0 - 10b5:8112 - Bridge device
04:01.0 - 8086:1010 - Network controller
04:01.1 - 8086:1010 - Network controller
02:02.0 - 10b5:8518 - Bridge device
02:03.0 - 10b5:8518 - Bridge device
06:00.0 - 10b5:8518 - Bridge device
07:00.0 - 10b5:8518 - Bridge device
08:00.0 - 1957:0040 - Processor
07:01.0 - 10b5:8518 - Bridge device
09:00.0 - 10b5:8112 - Bridge device
07:02.0 - 10b5:8518 - Bridge device
PCIE1: Bus 00 - 0b
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
|
|
This change does the following:
- Removes the printing of the PCI interrupt line value. This is
normally set to 0 by U-Boot on bootup and is rarely used during
everyday operation.
- Prints out the PCI function number of a device. Previously a device
with multiple functions would be printed identically 2 times, which is
generally confusing. For example, on an Intel 2 port gigabit Ethernet
card the following was displayed:
...
04 01 8086 1010 0200 00
04 01 8086 1010 0200 00
...
- Prints a text description of each device's PCI class instead of the
raw PCI class code. The textual description makes it much easier to
determine what devices are installed on a PCI bus.
- Changes the general formatting of the PCI device output.
Previous output:
PCIE1: connected as Root Complex
04 01 8086 1010 0200 00
04 01 8086 1010 0200 00
03 00 10b5 8112 0604 00
02 01 10b5 8518 0604 00
02 02 10b5 8518 0604 00
08 00 1957 0040 0b20 00
07 00 10b5 8518 0604 00
09 00 10b5 8112 0604 00
07 01 10b5 8518 0604 00
07 02 10b5 8518 0604 00
06 00 10b5 8518 0604 00
02 03 10b5 8518 0604 00
01 00 10b5 8518 0604 00
PCIE1: Bus 00 - 0b
PCIE2: connected as Root Complex
0d 00 1957 0040 0b20 00
PCIE2: Bus 0c - 0d
Updated output:
PCIE1: connected as Root Complex
04:01.0 - 8086:1010 - Network controller
04:01.1 - 8086:1010 - Network controller
03:00.0 - 10b5:8112 - Bridge device
02:01.0 - 10b5:8518 - Bridge device
02:02.0 - 10b5:8518 - Bridge device
08:00.0 - 1957:0040 - Processor
07:00.0 - 10b5:8518 - Bridge device
09:00.0 - 10b5:8112 - Bridge device
07:01.0 - 10b5:8518 - Bridge device
07:02.0 - 10b5:8518 - Bridge device
06:00.0 - 10b5:8518 - Bridge device
02:03.0 - 10b5:8518 - Bridge device
01:00.0 - 10b5:8518 - Bridge device
PCIE1: Bus 00 - 0b
PCIE2: connected as Root Complex
0d:00.0 - 1957:0040 - Processor
PCIE2: Bus 0c - 0d
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
|
|
The "Scanning PCI bus X" message doesn't provide any real useful
information, so remove it.
Original output:
PCIE1: connected as Root Complex
Scanning PCI bus 01
04 01 8086 1010 0200 00
04 01 8086 1010 0200 00
03 00 10b5 8112 0604 00
02 01 10b5 8518 0604 00
02 02 10b5 8518 0604 00
08 00 1957 0040 0b20 00
07 00 10b5 8518 0604 00
09 00 10b5 8112 0604 00
07 01 10b5 8518 0604 00
07 02 10b5 8518 0604 00
06 00 10b5 8518 0604 00
02 03 10b5 8518 0604 00
01 00 10b5 8518 0604 00
PCIE1: Bus 00 - 0b
PCIE2: connected as Root Complex
Scanning PCI bus 0d
0d 00 1957 0040 0b20 00
PCIE2: Bus 0c - 0d
Updated output:
PCIE1: connected as Root Complex
04 01 8086 1010 0200 00
04 01 8086 1010 0200 00
03 00 10b5 8112 0604 00
02 01 10b5 8518 0604 00
02 02 10b5 8518 0604 00
08 00 1957 0040 0b20 00
07 00 10b5 8518 0604 00
09 00 10b5 8112 0604 00
07 01 10b5 8518 0604 00
07 02 10b5 8518 0604 00
06 00 10b5 8518 0604 00
02 03 10b5 8518 0604 00
01 00 10b5 8518 0604 00
PCIE1: Bus 00 - 0b
PCIE2: connected as Root Complex
0d 00 1957 0040 0b20 00
PCIE2: Bus 0c - 0d
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
CC: galak@kernel.crashing.org
|
|
Previously some mpc85xx boards printed indented messages such as the
following on bootup:
printf(" eTSEC4 is in sgmii mode.\n");
printf(" Serdes2 disalbed\n");
The bootup appearance looks cleaner if the indentation is removed which
aligns these messages with other bootup output.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
CC: galak@kernel.crashing.org
|
|
Previously boards used a variety of indentations, newline styles, and
colon styles for the PCI information that is printed on bootup. This
patch unifies the style to look like:
...
NAND: 1024 MiB
PCIE1: connected as Root Complex
Scanning PCI bus 01
04 01 8086 1010 0200 00
04 01 8086 1010 0200 00
03 00 10b5 8112 0604 00
02 01 10b5 8518 0604 00
02 02 10b5 8518 0604 00
08 00 1957 0040 0b20 00
07 00 10b5 8518 0604 00
09 00 10b5 8112 0604 00
07 01 10b5 8518 0604 00
07 02 10b5 8518 0604 00
06 00 10b5 8518 0604 00
02 03 10b5 8518 0604 00
01 00 10b5 8518 0604 00
PCIE1: Bus 00 - 0b
PCIE2: connected as Root Complex
Scanning PCI bus 0d
0d 00 1957 0040 0b20 00
PCIE2: Bus 0c - 0d
In: serial
...
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
CC: wd@denx.de
CC: sr@denx.de
CC: galak@kernel.crashing.org
|
|
Previously fsl_pci_init_port() always assumed that a port was a PCIe
port and would incorrectly print messages for a PCI port such as the
following on bootup:
PCI1: 32 bit, 33 MHz, sync, host, arbiter
Scanning PCI bus 00
PCIE1 on bus 00 - 00
This change corrects the output of fsl_pci_init_port():
PCI1: 32 bit, 33 MHz, sync, host, arbiter
Scanning PCI bus 00
PCI1 on bus 00 - 00
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
|
|
Can't get IP address with dhcp due to the dhcp server not
allow the empty param list request under some network env
This patch is based on Gray Remlin's initial patch.
Signed-off-by: Jason Liu <r64343@freescale.com>
Signed-off-by: Gray Remlin <g_remlin@rocketmail.com>
|
|
hexport would complain implicit declaration, if we don't add the
include file.
env_mmc.c: In function 'saveenv':
env_mmc.c:109: warning: implicit declaration of function 'hexport'
Signed-off-by: Lei Wen <leiwen@marvell.com>
|
|
This patch makes tools/env/Makefile more similar to tools/imls:
- define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works.
- include U-Boot headers using -idirafter to prevent picking up
u-boot/include/errno.h.
- use HOSTCFLAGS_NOPED (fw_env.c does not conform to -pedantic).
In order to cross-compile tools/env, override the HOSTCC variable
as in this example:
make tools env HOSTCC=bfin-uclinux-gcc
Signed-off-by: Daniel Hobi <daniel.hobi@schmid-telecom.ch>
Tested-by: Detlev Zundel <dzu@denx.de>
Tested-by: Steve Sakoman <steve.sakoman@linaro.org>
|
|
The fixup procedure just stored a constant value in the
fixup table rather than just adjusting the table.
Although that doesn't seem to do any harm, it prevents
relocation more that once.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
|
|
nic and hw structures are allocated via malloc i.e. return memory
is not zero initialized. Because of this few structure member like
"function pointers" are initialized with garbage values.
It may cause problem. for eg. during eth_initialize, dev->write_hwaddr
is used.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Fixed typo.
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
uli526x driver does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>
|
|
tsi108_eth driver does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>
|
|
pcnet driver does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>
|
|
ns8382x driver does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>
|
|
natsemi driver does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>
|
|
This prevents access to the member of eth_device which is not initialized.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>
|