mirrors/u-boot
0
0
Fork 0
mirror of https://github.com/u-boot/u-boot.git synced 2024-12-11 21:53:29 +08:00
Code Issues Packages Projects Releases Wiki Activity
75dd53055a
u-boot/configs/ds414_defconfig

72 lines
1.7 KiB
Plaintext
Raw Normal View History

mvebu: Support Synology DS414 This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error. Sadly, support is far from perfect. The major parts I have failed in are SATA and XHCI support. Details about these and some other things follow: Device Tree ----------- The device tree file armada-xp-synology-ds414.dts has been copied from Linux and enhanced by recent U-Boot specific changes to armada-xp-gp.dts. SATA Support ------------ There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv. I'm not sure if extending the latter to support PCI devices is worth the effort at all. Porting sata_mv from Linux exceeded my brain's capacities. :( XHCI Support ------------ There is an EtronTech EJ168A XHCI controller attached to PCIe which drives the two rear USB3 ports. After a bit of playing around I managed to get it recognized by xhci-pci, but never was able to access any devices attached to it. Enabling it in ds414 board config shows that it does not respond to commands for whatever reason. The (somewhat) bright side to it is that it is not even supported in Synology's customized U-Boot, but that also means nowhere to steal the relevant bits from. EHCI Support ------------ This seems functional after issuing 'usb start'. At least it detects USB storage devices, and IIRC reading from them was OK. OTOH Linux fails to register the controller if 'usb start' wasn't given before in U-Boot. According to Synology sources, this board seems to support USB device (gadget?) mode. Though I didn't play around with it. PCIe Support ------------ This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI. DDR3 Training ------------- Marvell/Synology uses eight PUPs instead of four. Does not look like this is meant to be customized in mainline U-Boot at all. OTOH I have no idea what a "PUP" actually is. PEX Init -------- Synology uses different values than mainline U-Boot with this patch: pex_max_unit_get returns 2, pex_max_if_get returns 7 and max_serdes_lines is set to 7. Not changing this seems to not have an impact, although I'm not entirely sure it does not cause issues I am not aware of. Static Environment ------------------ This allows to boot stock Synology firmware at least. In order to be a little more flexible when it comes to booting custom kernels, do not only load zImage partition, but also rd.gz into memory. This way it is possible to use about 7MB for kernel with piggyback initramfs. Signed-off-by: Phil Sutter <phil@nwl.cc> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-12-25 21:41:25 +08:00
CONFIG_ARM=y
Convert CONFIG_ARCH_CPU_INIT to Kconfig This converts the following to Kconfig: CONFIG_ARCH_CPU_INIT Signed-off-by: Adam Ford <aford173@gmail.com> Acked-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Felix Brack <fb@ltec.ch>
2019-08-14 21:29:25 +08:00
CONFIG_ARCH_CPU_INIT=y
mvebu: Support Synology DS414 This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error. Sadly, support is far from perfect. The major parts I have failed in are SATA and XHCI support. Details about these and some other things follow: Device Tree ----------- The device tree file armada-xp-synology-ds414.dts has been copied from Linux and enhanced by recent U-Boot specific changes to armada-xp-gp.dts. SATA Support ------------ There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv. I'm not sure if extending the latter to support PCI devices is worth the effort at all. Porting sata_mv from Linux exceeded my brain's capacities. :( XHCI Support ------------ There is an EtronTech EJ168A XHCI controller attached to PCIe which drives the two rear USB3 ports. After a bit of playing around I managed to get it recognized by xhci-pci, but never was able to access any devices attached to it. Enabling it in ds414 board config shows that it does not respond to commands for whatever reason. The (somewhat) bright side to it is that it is not even supported in Synology's customized U-Boot, but that also means nowhere to steal the relevant bits from. EHCI Support ------------ This seems functional after issuing 'usb start'. At least it detects USB storage devices, and IIRC reading from them was OK. OTOH Linux fails to register the controller if 'usb start' wasn't given before in U-Boot. According to Synology sources, this board seems to support USB device (gadget?) mode. Though I didn't play around with it. PCIe Support ------------ This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI. DDR3 Training ------------- Marvell/Synology uses eight PUPs instead of four. Does not look like this is meant to be customized in mainline U-Boot at all. OTOH I have no idea what a "PUP" actually is. PEX Init -------- Synology uses different values than mainline U-Boot with this patch: pex_max_unit_get returns 2, pex_max_if_get returns 7 and max_serdes_lines is set to 7. Not changing this seems to not have an impact, although I'm not entirely sure it does not cause issues I am not aware of. Static Environment ------------------ This allows to boot stock Synology firmware at least. In order to be a little more flexible when it comes to booting custom kernels, do not only load zImage partition, but also rd.gz into memory. This way it is possible to use about 7MB for kernel with piggyback initramfs. Signed-off-by: Phil Sutter <phil@nwl.cc> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-12-25 21:41:25 +08:00
CONFIG_ARCH_MVEBU=y
configs: Migrate CONFIG_SYS_TEXT_BASE On the NIOS2 and Xtensa architectures, we do not have CONFIG_SYS_TEXT_BASE set. This is a strict migration of the current values into the defconfig and removing them from the headers. I did not attempt to add more default values in and for now will leave that to maintainers. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-02-04 01:10:38 +08:00
CONFIG_SYS_TEXT_BASE=0x00800000
Convert CONFIG_SPL_LIBCOMMON_SUPPORT to Kconfig Move this option to Kconfig and tidy up existing uses. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-09-13 13:18:41 +08:00
CONFIG_SPL_LIBCOMMON_SUPPORT=y
Convert CONFIG_SPL_LIBGENERIC_SUPPORT to Kconfig Move this option to Kconfig and tidy up existing uses. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-09-13 13:18:43 +08:00
CONFIG_SPL_LIBGENERIC_SUPPORT=y
Revert "Increase default of CONFIG_SYS_MALLOC_F_LEN for SPL_OF_CONTROL" This reverts commit 90c08d9e08c7a108ab904f3bbdeb558081757892. I took a closer look at this after the commit was applied, and found CONFIG_SYS_MALLOC_F_LEN=0x2000 was too much. 8KB memory for SPL is actually too big for some boards. Perhaps 0x800 is enough, but the situation varies board by board. Let's postpone our decision until we come up with a better idea. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-09-19 20:40:26 +08:00
CONFIG_SYS_MALLOC_F_LEN=0x2000
mvebu: Support Synology DS414 This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error. Sadly, support is far from perfect. The major parts I have failed in are SATA and XHCI support. Details about these and some other things follow: Device Tree ----------- The device tree file armada-xp-synology-ds414.dts has been copied from Linux and enhanced by recent U-Boot specific changes to armada-xp-gp.dts. SATA Support ------------ There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv. I'm not sure if extending the latter to support PCI devices is worth the effort at all. Porting sata_mv from Linux exceeded my brain's capacities. :( XHCI Support ------------ There is an EtronTech EJ168A XHCI controller attached to PCIe which drives the two rear USB3 ports. After a bit of playing around I managed to get it recognized by xhci-pci, but never was able to access any devices attached to it. Enabling it in ds414 board config shows that it does not respond to commands for whatever reason. The (somewhat) bright side to it is that it is not even supported in Synology's customized U-Boot, but that also means nowhere to steal the relevant bits from. EHCI Support ------------ This seems functional after issuing 'usb start'. At least it detects USB storage devices, and IIRC reading from them was OK. OTOH Linux fails to register the controller if 'usb start' wasn't given before in U-Boot. According to Synology sources, this board seems to support USB device (gadget?) mode. Though I didn't play around with it. PCIe Support ------------ This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI. DDR3 Training ------------- Marvell/Synology uses eight PUPs instead of four. Does not look like this is meant to be customized in mainline U-Boot at all. OTOH I have no idea what a "PUP" actually is. PEX Init -------- Synology uses different values than mainline U-Boot with this patch: pex_max_unit_get returns 2, pex_max_if_get returns 7 and max_serdes_lines is set to 7. Not changing this seems to not have an impact, although I'm not entirely sure it does not cause issues I am not aware of. Static Environment ------------------ This allows to boot stock Synology firmware at least. In order to be a little more flexible when it comes to booting custom kernels, do not only load zImage partition, but also rd.gz into memory. This way it is possible to use about 7MB for kernel with piggyback initramfs. Signed-off-by: Phil Sutter <phil@nwl.cc> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-12-25 21:41:25 +08:00
CONFIG_TARGET_DS414=y
Convert CONFIG_SPL_SERIAL_SUPPORT to Kconfig Move this option to Kconfig and tidy up existing uses. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-09-13 13:18:56 +08:00
CONFIG_SPL_SERIAL_SUPPORT=y
env: Finish migration of common ENV options - In ARMv8 NXP Layerscape platforms we also need to make use of CONFIG_SYS_RELOC_GD_ENV_ADDR now, do so. - On ENV_IS_IN_REMOTE, CONFIG_ENV_OFFSET is never used, drop the define to 0. - Add Kconfig entry for ENV_ADDR. - Make ENV_ADDR / ENV_OFFSET depend on the env locations that use it. - Add ENV_xxx_REDUND options that depend on their primary option and SYS_REDUNDAND_ENVIRONMENT - On a number of PowerPC platforms, use SPL_ENV_ADDR not CONFIG_ENV_ADDR for the pre-main-U-Boot environment location. - On ENV_IS_IN_SPI_FLASH, check not for CONFIG_ENV_ADDR being set but rather it being non-zero, as it will now be zero by default. - Rework the env_offset absolute in env/embedded.o to not use CONFIG_ENV_OFFSET as it was the only use of ENV_OFFSET within ENV_IS_IN_FLASH. - Migrate all platforms. Cc: Wolfgang Denk <wd@denx.de> Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: uboot-stm32@st-md-mailman.stormreply.com Signed-off-by: Tom Rini <trini@konsulko.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com> Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
2019-11-19 09:02:10 +08:00
CONFIG_ENV_SIZE=0x10000
CONFIG_ENV_OFFSET=0x7E0000
configs: Resync with savedefconfig Rsync all defconfig files using moveconfig.py Signed-off-by: Tom Rini <trini@konsulko.com>
2019-04-30 03:54:04 +08:00
CONFIG_NR_DRAM_BANKS=2
configs: Resync with savedefconfig Rsync all defconfig files using moveconfig.py Signed-off-by: Tom Rini <trini@konsulko.com>
2018-06-04 23:57:37 +08:00
CONFIG_SPL=y
CONFIG_DEBUG_UART_BASE=0xd0012000
CONFIG_DEBUG_UART_CLOCK=250000000
env: Finish migration of common ENV options - In ARMv8 NXP Layerscape platforms we also need to make use of CONFIG_SYS_RELOC_GD_ENV_ADDR now, do so. - On ENV_IS_IN_REMOTE, CONFIG_ENV_OFFSET is never used, drop the define to 0. - Add Kconfig entry for ENV_ADDR. - Make ENV_ADDR / ENV_OFFSET depend on the env locations that use it. - Add ENV_xxx_REDUND options that depend on their primary option and SYS_REDUNDAND_ENVIRONMENT - On a number of PowerPC platforms, use SPL_ENV_ADDR not CONFIG_ENV_ADDR for the pre-main-U-Boot environment location. - On ENV_IS_IN_SPI_FLASH, check not for CONFIG_ENV_ADDR being set but rather it being non-zero, as it will now be zero by default. - Rework the env_offset absolute in env/embedded.o to not use CONFIG_ENV_OFFSET as it was the only use of ENV_OFFSET within ENV_IS_IN_FLASH. - Migrate all platforms. Cc: Wolfgang Denk <wd@denx.de> Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: uboot-stm32@st-md-mailman.stormreply.com Signed-off-by: Tom Rini <trini@konsulko.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com> Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
2019-11-19 09:02:10 +08:00
CONFIG_ENV_SECT_SIZE=0x10000
Convert CONFIG_SPL_SPI_FLASH_SUPPORT to Kconfig Move this option to Kconfig and tidy up existing uses. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-09-13 13:18:57 +08:00
CONFIG_SPL_SPI_FLASH_SUPPORT=y
Convert CONFIG_SPL_SPI_SUPPORT to Kconfig Move this option to Kconfig and tidy up existing uses. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-09-13 13:18:58 +08:00
CONFIG_SPL_SPI_SUPPORT=y
configs: Resync defconfigs Signed-off-by: Tom Rini <trini@konsulko.com>
2017-06-19 21:47:40 +08:00
CONFIG_DEBUG_UART=y
configs: Resync with savedefconfig Rsync all defconfig files using moveconfig.py Signed-off-by: Tom Rini <trini@konsulko.com>
2019-09-23 23:47:37 +08:00
CONFIG_SPL_TEXT_BASE=0x40004030
common: bootdelay: move CONFIG_BOOTDELAY into a Kconfig option move CONFIG_BOOTDELAY into a Kconfig option. Used for this purpose the moveconfig.py tool in tools. Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Igor Grinberg <grinberg@compulab.co.il>
2016-06-07 14:31:14 +08:00
CONFIG_BOOTDELAY=3
common: Move CONFIG_BOOTARGS to Kconfig Also introduce CONFIG_USE_BOOTARGS option so we can control if CONFIG_BOOTARGS defined at all. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> [trini: Resync r8a779[56]_ulcb, various ls10xx targets] Signed-off-by: Tom Rini <trini@konsulko.com>
2017-08-15 01:22:17 +08:00
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS="console=ttyS0,115200"
Convert CONFIG_USE_PREBOOT and CONFIG_PREBOOT to Kconfig This converts the following to Kconfig: CONFIG_USE_PREBOOT CONFIG_PREBOOT Both are together in one commit, since otherwise the former causes kconfig to define the latter, which gives duplicate symbol errors. Includes a manual fixup for CONFIG_PREBOOT in ids8313_defconfig since the backslash lands in the wrong place. Similarly with socfpga_vining_fpga. Signed-off-by: Simon Glass <sjg@chromium.org>
2019-07-21 10:51:14 +08:00
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="usb start; sf probe"
common: Add DISPLAY_BOARDINFO Create a Kconfig entry for DISPLAY_BOARDINFO and make it be the default in certain architectures. Migrate all config files. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-10-12 09:33:46 +08:00
# CONFIG_DISPLAY_BOARDINFO is not set
treewide: Migrate CONFIG_DISPLAY_BOARDINFO_LATE to Kconfig Migrate the CONFIG_DISPLAY_BOARDINFO_LATE option to Kconfig. Signed-off-by: Mario Six <mario.six@gdsys.cc> [trini: Re-run migration] Signed-off-by: Tom Rini <trini@konsulko.com>
2018-03-28 20:38:17 +08:00
CONFIG_DISPLAY_BOARDINFO_LATE=y
configs: Re-sync Signed-off-by: Tom Rini <trini@konsulko.com>
2017-03-14 01:48:42 +08:00
CONFIG_SPL_I2C_SUPPORT=y
spl: spi: Move CONFIG_SPL_SPI_LOAD to Kconfig Add Kconfig entry for CONFIG_SPL_SPI_LOAD symbol and move all configurations using it to Kconfig. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Tom Rini <trini@konsulko.com>
2018-04-07 22:05:27 +08:00
CONFIG_SPL_SPI_LOAD=y
Convert CONFIG_SYS_SPI_U_BOOT_OFFS to Kconfig This converts the following to Kconfig: CONFIG_SYS_SPI_U_BOOT_OFFS Signed-off-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com> [trini: Expose this for SPL_SPI_SUNXI for now] Signed-off-by: Tom Rini <trini@konsulko.com>
2019-08-22 21:41:46 +08:00
CONFIG_SYS_SPI_U_BOOT_OFFS=0x24000
mvebu: Support Synology DS414 This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error. Sadly, support is far from perfect. The major parts I have failed in are SATA and XHCI support. Details about these and some other things follow: Device Tree ----------- The device tree file armada-xp-synology-ds414.dts has been copied from Linux and enhanced by recent U-Boot specific changes to armada-xp-gp.dts. SATA Support ------------ There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv. I'm not sure if extending the latter to support PCI devices is worth the effort at all. Porting sata_mv from Linux exceeded my brain's capacities. :( XHCI Support ------------ There is an EtronTech EJ168A XHCI controller attached to PCIe which drives the two rear USB3 ports. After a bit of playing around I managed to get it recognized by xhci-pci, but never was able to access any devices attached to it. Enabling it in ds414 board config shows that it does not respond to commands for whatever reason. The (somewhat) bright side to it is that it is not even supported in Synology's customized U-Boot, but that also means nowhere to steal the relevant bits from. EHCI Support ------------ This seems functional after issuing 'usb start'. At least it detects USB storage devices, and IIRC reading from them was OK. OTOH Linux fails to register the controller if 'usb start' wasn't given before in U-Boot. According to Synology sources, this board seems to support USB device (gadget?) mode. Though I didn't play around with it. PCIe Support ------------ This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI. DDR3 Training ------------- Marvell/Synology uses eight PUPs instead of four. Does not look like this is meant to be customized in mainline U-Boot at all. OTOH I have no idea what a "PUP" actually is. PEX Init -------- Synology uses different values than mainline U-Boot with this patch: pex_max_unit_get returns 2, pex_max_if_get returns 7 and max_serdes_lines is set to 7. Not changing this seems to not have an impact, although I'm not entirely sure it does not cause issues I am not aware of. Static Environment ------------------ This allows to boot stock Synology firmware at least. In order to be a little more flexible when it comes to booting custom kernels, do not only load zImage partition, but also rd.gz into memory. This way it is possible to use about 7MB for kernel with piggyback initramfs. Signed-off-by: Phil Sutter <phil@nwl.cc> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-12-25 21:41:25 +08:00
# CONFIG_CMD_FLASH is not set
configs: Resync with savedefconfig Rsync all defconfig files using moveconfig.py Signed-off-by: Tom Rini <trini@konsulko.com>
2017-08-15 07:58:53 +08:00
CONFIG_CMD_I2C=y
CONFIG_CMD_PCI=y
configs: Re-sync almost all of cmd/Kconfig This syncs up the current cmd/Kconfig and include/configs/ files with the only exception being CMD_NAND. Due to how we have used this historically we need to take further care here when converting. Signed-off-by: Tom Rini <trini@konsulko.com>
2016-04-23 04:41:25 +08:00
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
mvebu: Support Synology DS414 This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error. Sadly, support is far from perfect. The major parts I have failed in are SATA and XHCI support. Details about these and some other things follow: Device Tree ----------- The device tree file armada-xp-synology-ds414.dts has been copied from Linux and enhanced by recent U-Boot specific changes to armada-xp-gp.dts. SATA Support ------------ There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv. I'm not sure if extending the latter to support PCI devices is worth the effort at all. Porting sata_mv from Linux exceeded my brain's capacities. :( XHCI Support ------------ There is an EtronTech EJ168A XHCI controller attached to PCIe which drives the two rear USB3 ports. After a bit of playing around I managed to get it recognized by xhci-pci, but never was able to access any devices attached to it. Enabling it in ds414 board config shows that it does not respond to commands for whatever reason. The (somewhat) bright side to it is that it is not even supported in Synology's customized U-Boot, but that also means nowhere to steal the relevant bits from. EHCI Support ------------ This seems functional after issuing 'usb start'. At least it detects USB storage devices, and IIRC reading from them was OK. OTOH Linux fails to register the controller if 'usb start' wasn't given before in U-Boot. According to Synology sources, this board seems to support USB device (gadget?) mode. Though I didn't play around with it. PCIe Support ------------ This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI. DDR3 Training ------------- Marvell/Synology uses eight PUPs instead of four. Does not look like this is meant to be customized in mainline U-Boot at all. OTOH I have no idea what a "PUP" actually is. PEX Init -------- Synology uses different values than mainline U-Boot with this patch: pex_max_unit_get returns 2, pex_max_if_get returns 7 and max_serdes_lines is set to 7. Not changing this seems to not have an impact, although I'm not entirely sure it does not cause issues I am not aware of. Static Environment ------------------ This allows to boot stock Synology firmware at least. In order to be a little more flexible when it comes to booting custom kernels, do not only load zImage partition, but also rd.gz into memory. This way it is possible to use about 7MB for kernel with piggyback initramfs. Signed-off-by: Phil Sutter <phil@nwl.cc> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-12-25 21:41:25 +08:00
# CONFIG_CMD_SETEXPR is not set
configs: Re-sync almost all of cmd/Kconfig This syncs up the current cmd/Kconfig and include/configs/ files with the only exception being CMD_NAND. Due to how we have used this historically we need to take further care here when converting. Signed-off-by: Tom Rini <trini@konsulko.com>
2016-04-23 04:41:25 +08:00
CONFIG_CMD_DHCP=y
configs: Resync with savedefconfig Rsync all defconfig files using moveconfig.py Signed-off-by: Tom Rini <trini@konsulko.com>
2018-04-17 21:22:31 +08:00
CONFIG_CMD_TFTPPUT=y
configs: Re-sync with cmd/Kconfig Update the config.h and defconfig files for the commands that 8e3c036 converted over to Kconfig Signed-off-by: Tom Rini <trini@konsulko.com>
2016-04-25 05:29:26 +08:00
CONFIG_CMD_MII=y
configs: Re-sync almost all of cmd/Kconfig This syncs up the current cmd/Kconfig and include/configs/ files with the only exception being CMD_NAND. Due to how we have used this historically we need to take further care here when converting. Signed-off-by: Tom Rini <trini@konsulko.com>
2016-04-23 04:41:25 +08:00
CONFIG_CMD_PING=y
CONFIG_CMD_TIME=y
configs: Re-sync with cmd/Kconfig Update the config.h and defconfig files for the commands that 8e3c036 converted over to Kconfig Signed-off-by: Tom Rini <trini@konsulko.com>
2016-04-25 05:29:26 +08:00
CONFIG_CMD_EXT2=y
CONFIG_CMD_FAT=y
Convert CONFIG_CMD_JFFS2 to Kconfig This converts the following to Kconfig: CONFIG_CMD_JFFS2 Signed-off-by: Simon Glass <sjg@chromium.org>
2017-05-17 17:25:37 +08:00
CONFIG_CMD_JFFS2=y
configs: Migrate and re-enabled CONFIG_CMD_MTDPARTS Now that CMD_UBI does not select CMD_MTDPARTS we need to make platforms that had been enabling it turn it on by hand. This exposed that we had not yet migrated CMD_MTDPARTS fully, so do so now. Fixes: 86dfa556d927 ("cmd: ubi: Remove useless call to mtdparts_init()") Signed-off-by: Tom Rini <trini@konsulko.com>
2018-11-14 08:54:45 +08:00
CONFIG_CMD_MTDPARTS=y
kconfig: introduce kconfig for UBI move the UBI config options into Kconfig. Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andrew F. Davis <afd@ti.com> Reviewed by: Evgeni Dobrev <evgeni at studio-punkt.com>
2016-09-21 13:58:19 +08:00
CONFIG_CMD_UBI=y
disk: convert CONFIG_ISO_PARTITION to Kconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>
2017-01-27 18:00:38 +08:00
CONFIG_ISO_PARTITION=y
configs: Resync with savedefconfig Rsync all defconfig files using moveconfig.py Signed-off-by: Tom Rini <trini@konsulko.com>
2018-09-04 03:26:12 +08:00
CONFIG_DEFAULT_DEVICE_TREE="armada-xp-synology-ds414"
Convert CONFIG_ENV_SPI_* to Kconfig This converts the following to Kconfig: CONFIG_ENV_SPI_BUS CONFIG_ENV_SPI_CS CONFIG_ENV_SPI_MAX_HZ CONFIG_ENV_SPI_MODE Most of time these value are not needed, CONFIG_SF_DEFAULT with same value is used, so I introduced CONFIG_USE_ENV_SPI_* to force the associated value for the environment. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2019-02-27 22:20:38 +08:00
CONFIG_USE_ENV_SPI_MAX_HZ=y
CONFIG_ENV_SPI_MAX_HZ=50000000
env: Add CONFIG_SYS_RELOC_GD_ENV_ADDR symbol Today in initr_reloc_global_data() we use some non-obvious tests to determine if we need to relocate the env_addr within gd or not. In order to facilitate migration of other symbols to Kconfig we need to introduce a new symbol for this particular use case. Cc: Wolfgang Denk <wd@denx.de> Cc: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2019-11-13 11:46:36 +08:00
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
Convert CONFIG LIB_HW_RAND to Kconfig config_fallbacks.h had some logic to automatically select LIB_RAND if RANDOM_UUID or CMD_UUID were set if LIB_HW_RAND wasn't already selected. By migrating LIB_HW_RAND to Kconfig, we can remove this check from config_fallbacks.h and put it into Kconfig Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Lukasz Majewski <lukma@denx.de> [trini: Turn into a choice, add NET_RANDOM_ETHADDR] Signed-off-by: Tom Rini <trini@konsulko.com>
2018-02-07 00:18:18 +08:00
CONFIG_NET_RANDOM_ETHADDR=y
mvebu: Support Synology DS414 This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error. Sadly, support is far from perfect. The major parts I have failed in are SATA and XHCI support. Details about these and some other things follow: Device Tree ----------- The device tree file armada-xp-synology-ds414.dts has been copied from Linux and enhanced by recent U-Boot specific changes to armada-xp-gp.dts. SATA Support ------------ There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv. I'm not sure if extending the latter to support PCI devices is worth the effort at all. Porting sata_mv from Linux exceeded my brain's capacities. :( XHCI Support ------------ There is an EtronTech EJ168A XHCI controller attached to PCIe which drives the two rear USB3 ports. After a bit of playing around I managed to get it recognized by xhci-pci, but never was able to access any devices attached to it. Enabling it in ds414 board config shows that it does not respond to commands for whatever reason. The (somewhat) bright side to it is that it is not even supported in Synology's customized U-Boot, but that also means nowhere to steal the relevant bits from. EHCI Support ------------ This seems functional after issuing 'usb start'. At least it detects USB storage devices, and IIRC reading from them was OK. OTOH Linux fails to register the controller if 'usb start' wasn't given before in U-Boot. According to Synology sources, this board seems to support USB device (gadget?) mode. Though I didn't play around with it. PCIe Support ------------ This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI. DDR3 Training ------------- Marvell/Synology uses eight PUPs instead of four. Does not look like this is meant to be customized in mainline U-Boot at all. OTOH I have no idea what a "PUP" actually is. PEX Init -------- Synology uses different values than mainline U-Boot with this patch: pex_max_unit_get returns 2, pex_max_if_get returns 7 and max_serdes_lines is set to 7. Not changing this seems to not have an impact, although I'm not entirely sure it does not cause issues I am not aware of. Static Environment ------------------ This allows to boot stock Synology firmware at least. In order to be a little more flexible when it comes to booting custom kernels, do not only load zImage partition, but also rd.gz into memory. This way it is possible to use about 7MB for kernel with piggyback initramfs. Signed-off-by: Phil Sutter <phil@nwl.cc> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-12-25 21:41:25 +08:00
CONFIG_SPL_OF_TRANSLATE=y
arm: mvebu: ds412: Enable CONFIG_BLK This patch enables CONFIG_BLK for the ds414 Armada XP based platform. This removes this build warning: ===================== WARNING ====================== This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== Please note that I don't have this board and can't test this change. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Phil Sutter <phil@nwl.cc>
2019-03-27 21:31:36 +08:00
CONFIG_BLK=y
configs: Re-sync Signed-off-by: Tom Rini <trini@konsulko.com>
2017-03-14 01:48:42 +08:00
# CONFIG_MMC is not set
mtd: rename CONFIG_MTD_DEVICE -> CONFIG_MTD Like in Linux, just use CONFIG_MTD to compile the MTD stack. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
2019-10-04 01:50:05 +08:00
CONFIG_MTD=y
mvebu: Support Synology DS414 This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error. Sadly, support is far from perfect. The major parts I have failed in are SATA and XHCI support. Details about these and some other things follow: Device Tree ----------- The device tree file armada-xp-synology-ds414.dts has been copied from Linux and enhanced by recent U-Boot specific changes to armada-xp-gp.dts. SATA Support ------------ There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv. I'm not sure if extending the latter to support PCI devices is worth the effort at all. Porting sata_mv from Linux exceeded my brain's capacities. :( XHCI Support ------------ There is an EtronTech EJ168A XHCI controller attached to PCIe which drives the two rear USB3 ports. After a bit of playing around I managed to get it recognized by xhci-pci, but never was able to access any devices attached to it. Enabling it in ds414 board config shows that it does not respond to commands for whatever reason. The (somewhat) bright side to it is that it is not even supported in Synology's customized U-Boot, but that also means nowhere to steal the relevant bits from. EHCI Support ------------ This seems functional after issuing 'usb start'. At least it detects USB storage devices, and IIRC reading from them was OK. OTOH Linux fails to register the controller if 'usb start' wasn't given before in U-Boot. According to Synology sources, this board seems to support USB device (gadget?) mode. Though I didn't play around with it. PCIe Support ------------ This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI. DDR3 Training ------------- Marvell/Synology uses eight PUPs instead of four. Does not look like this is meant to be customized in mainline U-Boot at all. OTOH I have no idea what a "PUP" actually is. PEX Init -------- Synology uses different values than mainline U-Boot with this patch: pex_max_unit_get returns 2, pex_max_if_get returns 7 and max_serdes_lines is set to 7. Not changing this seems to not have an impact, although I'm not entirely sure it does not cause issues I am not aware of. Static Environment ------------------ This allows to boot stock Synology firmware at least. In order to be a little more flexible when it comes to booting custom kernels, do not only load zImage partition, but also rd.gz into memory. This way it is possible to use about 7MB for kernel with piggyback initramfs. Signed-off-by: Phil Sutter <phil@nwl.cc> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-12-25 21:41:25 +08:00
CONFIG_SPI_FLASH_STMICRO=y
net: phy: Don't limit phy addresses by default Some boards expect to find more than one phy while other boards are old and need to be limited to a specific phy address. Only limit the phy address for boards that opt in. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2018-03-31 00:52:16 +08:00
CONFIG_PHY_ADDR_ENABLE=y
treewide: Move CONFIG_PHY_MARVELL to Kconfig The CONFIG_PHY_MARVELL has already been migrated to Kconfig (some boards already had it in their Kconfig), but had not been moved for older boards. Move it to the defconfigs for all boards. Signed-off-by: Mario Six <mario.six@gdsys.cc> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2018-04-27 20:52:21 +08:00
CONFIG_PHY_MARVELL=y
configs: Finish migration of PHY_GIGE Reviewed-by: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2017-08-08 10:00:34 +08:00
CONFIG_PHY_GIGE=y
ARM: mvebu: Convert CONFIG_MVNETA to Kconfig This converts the following to Kconfig: CONFIG_MVNETA Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Stefan Roese <sr@denx.de>
2017-08-21 16:17:03 +08:00
CONFIG_MVNETA=y
Convert CONFIG_MII et al to Kconfig This converts the following to Kconfig: CONFIG_MII CONFIG_DRIVER_TI_EMAC Signed-off-by: Adam Ford <aford173@gmail.com> Acked-by: Jagan Teki <jagan@amarulasolutions.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2018-07-21 12:03:57 +08:00
CONFIG_MII=y
drivers/pci/Kconfig: Add PCI Add 'PCI' as a menu option and migrate all existing users. Signed-off-by: Tom Rini <trini@konsulko.com> Acked-by: Stephen Warren <swarren@nvidia.com>
2016-10-27 05:15:37 +08:00
CONFIG_PCI=y
pci: pci_mvebu: Add DM_PCI support and move CONFIG_PCI_MVEBU to defconfig This patch adds DM_PCI support to the MVEBU PCIe driver. This is necessary, since all PCI drivers have to be moved to DM (driver model) until the v2019.07 release. To not break git bisect'ablility, this patch also moves CONFIG_PCI_MVEBU from config headers to the defconfig files. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Dirk Eibach <dirk.eibach@gdsys.cc> Cc: Mario Six <mario.six@gdsys.cc> Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> Cc: Phil Sutter <phil@nwl.cc> Cc: Marek Behún <marek.behun@nic.cz> Cc: VlaoMao <vlaomao@gmail.com>
2019-01-25 18:52:43 +08:00
CONFIG_PCI_MVEBU=y
mvebu: Support Synology DS414 This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error. Sadly, support is far from perfect. The major parts I have failed in are SATA and XHCI support. Details about these and some other things follow: Device Tree ----------- The device tree file armada-xp-synology-ds414.dts has been copied from Linux and enhanced by recent U-Boot specific changes to armada-xp-gp.dts. SATA Support ------------ There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv. I'm not sure if extending the latter to support PCI devices is worth the effort at all. Porting sata_mv from Linux exceeded my brain's capacities. :( XHCI Support ------------ There is an EtronTech EJ168A XHCI controller attached to PCIe which drives the two rear USB3 ports. After a bit of playing around I managed to get it recognized by xhci-pci, but never was able to access any devices attached to it. Enabling it in ds414 board config shows that it does not respond to commands for whatever reason. The (somewhat) bright side to it is that it is not even supported in Synology's customized U-Boot, but that also means nowhere to steal the relevant bits from. EHCI Support ------------ This seems functional after issuing 'usb start'. At least it detects USB storage devices, and IIRC reading from them was OK. OTOH Linux fails to register the controller if 'usb start' wasn't given before in U-Boot. According to Synology sources, this board seems to support USB device (gadget?) mode. Though I didn't play around with it. PCIe Support ------------ This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI. DDR3 Training ------------- Marvell/Synology uses eight PUPs instead of four. Does not look like this is meant to be customized in mainline U-Boot at all. OTOH I have no idea what a "PUP" actually is. PEX Init -------- Synology uses different values than mainline U-Boot with this patch: pex_max_unit_get returns 2, pex_max_if_get returns 7 and max_serdes_lines is set to 7. Not changing this seems to not have an impact, although I'm not entirely sure it does not cause issues I am not aware of. Static Environment ------------------ This allows to boot stock Synology firmware at least. In order to be a little more flexible when it comes to booting custom kernels, do not only load zImage partition, but also rd.gz into memory. This way it is possible to use about 7MB for kernel with piggyback initramfs. Signed-off-by: Phil Sutter <phil@nwl.cc> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-12-25 21:41:25 +08:00
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYS_NS16550=y
spi: Migrate CONFIG_KIRKWOOD_SPI to Kconfig Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
2018-02-07 08:42:22 +08:00
CONFIG_KIRKWOOD_SPI=y
configs: Migrate CONFIG_USB_STORAGE In some cases we were missing CONFIG_USB=y so enable that when needed. Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-09-09 04:31:26 +08:00
CONFIG_USB=y
configs: Migrate all of the existing USB symbols, except fastboot This syncs all of the currently Kconfig'd symbols out of the headers and into the defconfig files. This has two exceptions, first am335x_evm needs to be converted to DM in SPL and then it can stop undef'ing CONFIG_DM_USB. Leaving this as-is results in a build failure, and without work, run time failure. The other case is am43xx_evm.h and in turn am43xx_evm_usbhost_boot. The problem here is that we need DWC3 USB host mode in SPL, but still desire to have gadget mode in U-Boot proper. Signed-off-by: Tom Rini <trini@konsulko.com>
2017-08-26 05:50:26 +08:00
CONFIG_DM_USB=y
Kconfig: USB: Migrate CONFIG_USB_EHCI_HCD users to Kconfig Migrate the rest of the users of CONFIG_USB_EHCI_HCD over to Kconfig. For a few SoCs, imply or default y this if USB is enabled. In some cases we had not already migrated to CONFIG_USB so do that as well. Cc: Marek Vasut <marex@denx.de> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Marek Vasut <marex@denx.de>
2017-05-13 10:33:28 +08:00
CONFIG_USB_EHCI_HCD=y
configs: Migrate CONFIG_USB_STORAGE In some cases we were missing CONFIG_USB=y so enable that when needed. Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-09-09 04:31:26 +08:00
CONFIG_USB_STORAGE=y
Reference in New Issue Copy Permalink