SPDX: Convert all of our single license tags to Linux Kernel styleWhen U-Boot started using SPDX tags we were among the early adopters andthere weren't a lot of other examples to borrow from. So
SPDX: Convert all of our single license tags to Linux Kernel styleWhen U-Boot started using SPDX tags we were among the early adopters andthere weren't a lot of other examples to borrow from. So we picked thearea of the file that usually had a full license text and replaced itwith an appropriate SPDX-License-Identifier: entry. Since then, theLinux Kernel has adopted SPDX tags and they place it as the very firstline in a file (except where shebangs are used, then it's second line)and with slightly different comment styles than us.In part due to community overlap, in part due to better tag visibilityand in part for other minor reasons, switch over to that style.This commit changes all instances where we have a single declaredlicense in the tag as both the before and after are identical in tagcontents. There's also a few places where I found we did not have a tagand have introduced one.Signed-off-by: Tom Rini <trini@konsulko.com>
show more ...
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h>Thomas reported U-Boot failed to build host tools if libfdt-develpackage is installed because tools include libfdt headers from/us
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h>Thomas reported U-Boot failed to build host tools if libfdt-develpackage is installed because tools include libfdt headers from/usr/include/ instead of using internal ones.This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.hand replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h>Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
env: Rename common functions related to setenv()We are now using an env_ prefix for environment functions. Rename thesecommonly used functions, for consistency. Also add function comments incommo
env: Rename common functions related to setenv()We are now using an env_ prefix for environment functions. Rename thesecommonly used functions, for consistency. Also add function comments incommon.h.Suggested-by: Wolfgang Denk <wd@denx.de>Signed-off-by: Simon Glass <sjg@chromium.org>
qemu-ppce500: Update get_phys_ccsrbar_addr_early()The logic of what fdt_get_base_address() will search for and return haschanged. Rework get_phys_ccsrbar_addr_early() to perform the logic thatfd
qemu-ppce500: Update get_phys_ccsrbar_addr_early()The logic of what fdt_get_base_address() will search for and return haschanged. Rework get_phys_ccsrbar_addr_early() to perform the logic thatfdt_get_base_address used to perform.Fixes: 336a44877af8 ("fdt: Correct fdt_get_base_address()")Reviewed-by: Simon Glass <sjg@chromium.org>Cc: Alexander Graf <agraf@suse.de>Signed-off-by: Tom Rini <trini@konsulko.com>
qemu-ppce500: pass 'range_id' around in pci_map_regionIn pci_map_region(), pass 'range_id' to fdt_read_range(),otherwise the same address will be mapped again in othercalls to pci_map_region()S
qemu-ppce500: pass 'range_id' around in pci_map_regionIn pci_map_region(), pass 'range_id' to fdt_read_range(),otherwise the same address will be mapped again in othercalls to pci_map_region()Signed-off-by: Miao Yan <yammiaobest@gmail.com>Reviewed-by: Bin Meng <bmeng.cn@gmail.com>Reviewed-by: Alexander Graf <agraf@suse.de>
fdt: Allow ft_board_setup() to report failureThis function can fail if the device tree runs out of space. Rather thansilently booting with an incomplete device tree, allow the failure to bedetect
fdt: Allow ft_board_setup() to report failureThis function can fail if the device tree runs out of space. Rather thansilently booting with an incomplete device tree, allow the failure to bedetected.Unfortunately this involves changing a lot of places in the code. I havenot changed behvaiour to return an error where one is not currentlyreturned, to avoid unexpected breakage.Eventually it would be nice to allow boards to register functions to becalled to update the device tree. This would avoid all the many functionsto do this. However it's not clear yet if this should be done using drivermodel or with a linker list. This work is left for later.Signed-off-by: Simon Glass <sjg@chromium.org>Acked-by: Anatolij Gustschin <agust@denx.de>
kconfig: remove redundant "string" type in arch and board KconfigsNow the types of CONFIG_SYS_{ARCH, CPU, SOC, VENDOR, BOARD, CONFIG_NAME}are specified in arch/Kconfig.We can delete the ones in
kconfig: remove redundant "string" type in arch and board KconfigsNow the types of CONFIG_SYS_{ARCH, CPU, SOC, VENDOR, BOARD, CONFIG_NAME}are specified in arch/Kconfig.We can delete the ones in arch and board Kconfig files.This commit can be easily reproduced by the following command:find . -name Kconfig -a ! -path ./arch/Kconfig | xargs sed -i -e '/config[[:space:]]SYS_\(ARCH\|CPU\|SOC\|\VENDOR\|BOARD\|CONFIG_NAME\)/ { N s/\n[[:space:]]*string//}'Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Add board MAINTAINERS filesWe have switched to Kconfig and the boards.cfg file is going tobe removed. We have to retrieve the board status and maintainersinformation from it.The MAINTAINERS for
Add board MAINTAINERS filesWe have switched to Kconfig and the boards.cfg file is going tobe removed. We have to retrieve the board status and maintainersinformation from it.The MAINTAINERS format as in Linux Kernel would be nicebecause we can crib the scripts/get_maintainer.pl script.After some discussion, we chose to put a MAINTAINERS file under eachboard directory, not the top-level one because we want to collectrelevant information for a board into a single place.TODO:Modify get_maintainer.pl to scan multiple MAINTAINERS files.Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>Suggested-by: Tom Rini <trini@ti.com>Acked-by: Simon Glass <sjg@chromium.org>
kconfig: add board Kconfig and defconfig filesThis commit adds: - arch/${ARCH}/Kconfig provide a menu to select target boards - board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig
kconfig: add board Kconfig and defconfig filesThis commit adds: - arch/${ARCH}/Kconfig provide a menu to select target boards - board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig set CONFIG macros to the appropriate values for each board - configs/${TARGET_BOARD}_defconfig default setting of each board(This commit was automatically generated by a conversion scriptbased on boards.cfg)In Linux Kernel, defconfig files are located underarch/${ARCH}/configs/ directory.It works in Linux Kernel since ARCH is always given from thecommand line for cross compile.But in U-Boot, ARCH is not given from the command line.Which means we cannot know ARCH until the board configuration is done.That is why all the "*_defconfig" files should be gathered into asingle directory ./configs/.Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>Acked-by: Simon Glass <sjg@chromium.org>
PPC 85xx QEMU: Always assume 1 coreWe only need u-boot to bother about a single core in the QEMU machine.Everything that would require additional knowledge of more cores getshandled by QEMU and p
PPC 85xx QEMU: Always assume 1 coreWe only need u-boot to bother about a single core in the QEMU machine.Everything that would require additional knowledge of more cores getshandled by QEMU and passed straight into the payload we execute.Because of this setup, it would be counterproductive to enable SMP supportin u-boot. We would have to rip CPUs out of already existing spin tablesand respin them from u-boot. It would be a pretty big mess.So only assume we have a single core. This fixes errors about CONFIG_MPbeing disabled.Signed-off-by: Alexander Graf <agraf@suse.de>
PPC 85xx: Add qemu-ppce500 machineFor KVM we have a special PV machine type called "ppce500". This machineis inspired by the MPC8544DS board, but implements a lot less featuresthan that one.It
PPC 85xx: Add qemu-ppce500 machineFor KVM we have a special PV machine type called "ppce500". This machineis inspired by the MPC8544DS board, but implements a lot less featuresthan that one.It also provides more PCI slots and is supposed to be enumerated bydevice tree only.This patch adds support for the generic ppce500 machine and tries torely solely on device tree for device enumeration.Signed-off-by: Alexander Graf <agraf@suse.de>Acked-by: Scott Wood <scottwood@freescale.com>Reviewed-by: York Sun <yorksun@freescale.com>