Commit graph

2015 commits

Author SHA1 Message Date
Michal Simek
18c4e7f71c i2c: spd: Extend SPD memory types
Decode DDR, DDR3 and DDR4 memories.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2016-02-22 16:21:12 +01:00
Simon Glass
4c80c53c00 gpio: Correct handling of 'gpio status'
This is broken - we need to look at the first two characters to distinguish
'gpio status' from 'gpio set'.

Fixes: 0ffe6ab5 (gpio: Allow 's' as an abbreviation for 'status')
Reported-by: Soeren Moch <smoch@web.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Soeren Moch <smoch@web.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>
2016-02-15 20:58:25 +00:00
Stephen Warren
986fe37817 itest: allow map_physmem to return 0 in limited cases
On some systems, RAM starts at address 0. If the user executes itest
against address 0 on such a system, it will call map_physmem(0, ...)
which will return 0 back; mapping only changes the address on sandbox.
This causes itest to believe map_physmem() has failed, and hence fails
the comparison.

Fix itest so that it allows map_physmem() to return 0 /if/ the orignal
address passed to it was also 0.

This fixes "tegra-uboot-flasher flash" on Tegra20.

This has the disadvantage that on sandbox, failed mapping attempts for
address 0 are not detected. Instead, should the code only call
map_physmem() on sandbox? Or, should map_physmem() return its error status
some other way. Or, should the special case only be allowed on systems
where the base of RAM is 0 somehow?

Fixes: 7861204c9a ("itest: make memory access work under sandbox")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
2016-02-09 15:41:19 -07:00
David Müller (ELSOFT AG)
b7fbdc60ab Remove unused CONFIG_CMD_HWFLOW option and associated dead code.
Signed-off-by: David Müller <d.mueller@elsoft.ch>
2016-02-08 10:22:44 -05:00
Simon Glass
e517db73a6 cmd: Fix control bmp_display()
All paths should share the same return.

Reported-by: Coverity (CID:134903)

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-06 13:53:09 +01:00
Bin Meng
a187559e3d Use correct spelling of "U-Boot"
Correct spelling of "U-Boot" shall be used in all written text
(documentation, comments in source files etc.).

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
2016-02-06 12:00:59 +01:00
Tom Rini
8a36287a01 Merge git://git.denx.de/u-boot-dm 2016-01-29 13:47:38 -05:00
Stephen Warren
e578b92cdb Implement "pci enum" command for CONFIG_DM_PCI
With CONFIG_DM_PCI enabled, PCI buses are not enumerated at boot, as they
are without that config option enabled. No command exists to enumerate the
PCI buses. Hence, unless some board-specific code causes PCI enumeration,
PCI-based Ethernet devices are not detected, and network access is not
available.

This patch implements "pci enum" in the CONFIG_DM_PCI case, thus giving a
mechanism whereby PCI can be enumerated.

do_pci()'s handling of case 'e' is moved into a single location before the
dev variable is assigned, in order to skip calculation of dev. The enum
sub-command doesn't need the dev value, and skipping its calculation
avoids an irrelevant error being printed.

Using a command to initialize PCI like this has a disadvantage relative to
enumerating PCI at boot. In particular, Ethernet devices are not probed
during PCI enumeration, but only when used. This defers setting variables
such as ethact, ethaddr, etc. until the first network-related command is
executed. Hopefully this will not cause further issues. Perhaps in the
long term, we need a "net start/enum" command too?

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-01-28 21:01:23 -07:00
Christophe Ricard
0e37d4c2c6 tpm: Fix fault in case CONFIG_DM_TPM is set without any TPM
In case CONFIG_DM_TPM was set without any TPM chipset configured a fault
was generated (NULL pointer access).

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
2016-01-28 21:01:22 -07:00
Tom Rini
82d72a1b99 Merge branch 'master' of git://git.denx.de/u-boot-net 2016-01-28 18:42:10 -05:00
Michal Simek
455ad585ee fpga: Fix compilation warnings
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2016-01-27 15:55:54 +01:00
Michal Simek
062f078c3b microblaze: Do not print eth device when DM_ETH is enabled
Doing the same fix as is done for ARM by:
"Avoid calling print_eths() with driver model"
(sha1: ff97380015)

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2016-01-27 15:55:49 +01:00
Masahiro Yamada
84b8bf6d5d bug.h: move BUILD_BUG_* defines to include/linux/bug.h
BUILD_BUG_* macros have been defined in several headers.  It would
be nice to collect them in include/linux/bug.h like Linux.

This commit is cherry-picking useful macros from include/linux/bug.h
of Linux 4.4.

I did not import BUILD_BUG_ON_MSG() because it would not work if it
is used with include/common.h in U-Boot.  I'd like to postpone it
until the root cause (the "error()" macro in include/common.h causes
the name conflict with "__attribute__((error()))") is fixed.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-25 10:39:59 -05:00
Simon Glass
2e192b245e Remove the cmd_ prefix from command files
Now that they are in their own directory, we can remove this prefix.
This makes it easier to find a file since the prefix does not get in the
way.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Stefan Roese <sr@denx.de>
Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
2016-01-25 10:39:43 -05:00
Simon Glass
72a8cf8dcc Move all command code into its own directory
There are a lot of unrelated files in common, including all of the commands.
Moving them into their own directory makes them easier to find and is more
logical.

Some commands include non-command code, such as cmd_scsi.c. This should be
sorted out at some point so that the function can be enabled with or without
the associated command.

Unfortunately, with m68k I get this error:

m68k:  +   M5329AFEE
+arch/m68k/cpu/mcf532x/start.o: In function `_start':
+arch/m68k/cpu/mcf532x/start.S:159:(.text+0x452): relocation truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in .text.board_init_f section in common/built-in.o

I hope someone can shed some light on what this means. I hope it isn't
depending on the position of code in the image.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Stefan Roese <sr@denx.de>
Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
2016-01-25 10:39:43 -05:00