how to efficiently add a vendor zynqmp board stealing from xilinx/ dir?
short form: is there an efficient way to add a new vendor and new zynqmp-based board to the u-boot infrastructure without creating a whole new vendor directory that (mostly) duplicates what is already under board/xilinx/? as i read it, if i configure u-boot for, say, a xilinx zynqmp-based ZCU102 (rev 1.0), the "board" selection is actually just the SoC specifier -- in this case, zynqmp. the resulting .config file contains, among other stuff: CONFIG_SYS_ARCH="arm" CONFIG_SYS_CPU="armv8" CONFIG_SYS_SOC="zynqmp" CONFIG_SYS_VENDOR="xilinx" CONFIG_SYS_BOARD="zynqmp" CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp" with no indication of the actual (ZCU102) target board. again, as i read it, the board-specific content comes from: 1) the board defconfig file, say: $ make xilinx_zynqmp_zcu102_rev1_0_defconfig 2) the board/xilinx/zynqmp/ subdirectory identified by CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zcu102-rev1.0" with most of those xilinx/zynqmp/ subdirectories containing the single (board-specific) source file psu_init_gpl.c. in other words, it *seems* that a new zynqmp-based board can be entirely defined by (in the simple case): 1) an appropriate defconfig file 2) a board-specific psu_init_gpl.c file now, if i wanted to define a new vendor and board as above (say, vendor "acme" and board "coyote" rev 1.0, based on ZCU102), i could of course just create an entirely new vendor directory and copy all of the relevant content from board/xilinx/ into it, but most of that would be identical. is there an obvious way to somehow "steal" the xilinx vendor content so that i don't have to copy it? copying it would naturally be the most obvious strategy, just wondering if there is a more clever way to base the new vendor and board off the board/xilinx/ content. (symlinks would also work, i guess, but that just seems messy.) i'm guessing there's no clever way to do this, but i'm willing to be corrected. rday
[PATCH] [ARM] arch/arm/Kconfig: typo/grammar/punctuation fixes
Various (mostly minor) spelling, grammar and punctuation tweaks for arch/arm/Kconfig. Signed-off-by: Robert P. J. Day --- diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f9dab073ea..36c9c2fecd 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -17,7 +17,7 @@ config POSITION_INDEPENDENT be loaded to and run from that address. This option lifts that restriction, thus allowing the code to be loaded to and executed from almost any address. This logic relies on the relocation - information that is embedded into the binary to support U-Boot + information that is embedded in the binary to support U-Boot relocating itself to the top-of-RAM later during execution. config INIT_SP_RELATIVE @@ -26,7 +26,7 @@ config INIT_SP_RELATIVE U-Boot typically uses a hard-coded value for the stack pointer before relocation. Enable this option to instead calculate the initial SP at run-time. This is useful to avoid hard-coding addresses - into U-Boot, so that can be loaded and executed at arbitrary + into U-Boot, so that it can be loaded and executed at arbitrary addresses and thus avoid using arbitrary addresses at runtime. If this option is enabled, the early stack pointer is set to @@ -57,7 +57,7 @@ config LNX_KRNL_IMG_TEXT_OFFSET_BASE hex help The value subtracted from CONFIG_SYS_TEXT_BASE to calculate the - TEXT_OFFSET value written in to the Linux kernel image header. + TEXT_OFFSET value written to the Linux kernel image header. endif endif @@ -121,7 +121,7 @@ config SYS_ARM_MMU select SYS_ARM_CACHE_CP15 help Select if you want MMU-based virtualised addressing space - support by paged memory management. + support via paged memory management. config SYS_ARM_MPU bool 'Use the ARM v7 PMSA Compliant MPU' @@ -136,8 +136,8 @@ config SYS_ARM_MPU # startup. Note that in general these options force the workarounds to be # applied; no CPU-type/version detection exists, unlike the similar options in # the Linux kernel. Do not set these options unless they apply! Also note that -# the following can be machine specific errata. These do have ability to -# provide rudimentary version and machine specific checks, but expect no +# the following can be machine-specific errata. These do have ability to +# provide rudimentary version and machine-specific checks, but expect no # product checks: # CONFIG_ARM_ERRATA_430973 # CONFIG_ARM_ERRATA_454179 @@ -332,7 +332,7 @@ config SYS_CACHELINE_SIZE config ARCH_CPU_INIT bool "Enable ARCH_CPU_INIT" help - Some architectures require a call to arch_cpu_init() + Some architectures require a call to arch_cpu_init(). Say Y here to enable it config SYS_ARCH_TIMER @@ -342,7 +342,7 @@ config SYS_ARCH_TIMER help The ARM Generic Timer (aka arch-timer) provides an architected interface to a timer source on an SoC. - It is mandantory for ARMv8 implementation and widely available + It is mandatory for ARMv8 implementation and widely available on ARMv7 systems. config ARM_SMCCC @@ -385,7 +385,7 @@ config TPL_SYS_THUMB_BUILD default y if SYS_THUMB_BUILD depends on TPL && !ARM64 help - Use this flag to build SPL using the Thumb instruction set for + Use this flag to build TPL using the Thumb instruction set for ARM architectures. Thumb instruction set provides better code density. For ARM architectures that support Thumb2 this flag will result in Thumb2 code generated by GCC. @@ -394,7 +394,7 @@ config TPL_SYS_THUMB_BUILD config SYS_L2CACHE_OFF bool "L2cache off" help - If SoC does not support L2CACHE or one do not want to enable + If SoC does not support L2CACHE or one does not want to enable L2CACHE, choose this option. config ENABLE_ARM_SOC_BOOT0_HOOK @@ -414,7 +414,7 @@ config USE_ARCH_MEMCPY depends on !ARM64 help Enable the generation of an optimized version of memcpy. - Such implementation may be faster under some conditions + Such an implementation may be faster under some conditions but may increase the binary size. config SPL_USE_ARCH_MEMCPY @@ -423,7 +423,7 @@ config SPL_USE_ARCH_MEMCPY depends on !ARM64 && SPL help Enable the generation of an optimized version of memcpy. - Such implementation may be faster under some conditions + Such an implementation may be faster under some conditions but may increase the binary size. config TPL_USE_ARCH_MEMCPY @@ -432,7 +432,7 @@ config TPL_USE_ARCH_MEMCPY depends on !ARM64 && TPL help Enable the generation of an optimized version
proper way to build [html]docs these days?
just tried to build docs on a fully-updated fedora 31 system, and got: $ make htmldocs SPHINX htmldocs --> file:///home/rpjday/uboot/git/doc/output make[2]: Nothing to be done for 'html'. Running Sphinx v2.1.2 Extension error: Could not import extension kerneldoc (exception: cannot import name 'AutodocReporter' from 'sphinx.ext.autodoc' (unknown location)) make[1]: *** [doc/Makefile:68: htmldocs] Error 2 make: *** [Makefile:1984: htmldocs] Error 2 $ i don't know enough about sphinx to know what to do with that diagnostic -- what is the current way to build u-boot docs? rday
xilinx_zynqmp.h: erroneous(?) "#define CONFIG_PANIC_HANG"
long story short, colleague came to me with a petalinux project wherein the compile of u-boot was failing due to a redefinition of the macro "CONFIG_PANIC_HANG" ... rather than mess with petalinux, i just set up the current master of u-boot (aarch64), used the same configuration and, sure enough: CC lib/asm-offsets.s In file included from include/config.h:5, from include/common.h:23, from lib/asm-offsets.c:14: include/configs/xilinx_zynqmp.h:97: warning: "CONFIG_PANIC_HANG" redefined #define CONFIG_PANIC_HANG In file included from ././include/linux/kconfig.h:4, from : include/generated/autoconf.h:410: note: this is the location of the previous definition #define CONFIG_PANIC_HANG 1 it would *appear* that this is because xilinx_zynqmp.h defines: #define CONFIG_PANIC_HANG but that symbol has been migrated to the Kconfig system, lib/Kconfig: config PANIC_HANG bool "Do not reset the system on fatal error" help Define this option to stop the system in case of a fatal error, so that you have to reset it manually. This is probably NOT a good idea for an embedded system where you want the system to reboot automatically as fast as possible, but it may be useful during development since you can try to debug the conditions that lead to the situation. is it safe to assume that this is the problem? i can certainly see how that combination would generate two different macro definitions, and it's just our luck that it seems that is the only header file that does that. rday
Re: want to confirm that include/configs/xilinx_zynqmp*.h files seem unused
On Fri, 13 Dec 2019, Michal Simek wrote: > On 13. 12. 19 15:05, Robert P. J. Day wrote: > > > > been a while since i wandered through the innards of u-boot so it's > > possible this is a silly question. > > > > was just placed on a project that involves a xilinx zynqmp-based > > board, and need to upgrade the version of u-boot that's currently > > being used. as part of my perusal, i did a quick grep to see what > > existing boards were doing with any zynqmp-related header files, so i > > did this from the top of the current tree: > > > > $ grep -r "include.*xilinx_zynqmp.*\.h" * > > include/configs/xilinx_zynqmp_mini.h:#include > > include/configs/xilinx_zynqmp_mini_emmc.h:#include > > > > include/configs/xilinx_zynqmp_mini_qspi.h:#include > > > > include/configs/xilinx_zynqmp_mini_nand.h:#include > > > > $ > > > > i'm aware of the ongoing migration of content from > > include/configs/*.h files to defconfig files, so the above seems to > > suggest, given the circular inclusion of those header files with no > > one else including them, that those files are no longer referenced. > > > > my guess is that all that content was migrated to defconfigs but the > > header files were simply left there. is that a fair conclusion, or > > might there be something far more subtle i'm overlooking here? > > Nope. > All of them are used as configuration for > configs/xilinx_zynqmp_mini* configurations. ah, i think i see what i overlooked (like i said, it's been a while since i poked around here). i wasn't sure how those header files could be included if their actual names were not found in the source, until i looked at (for example) xilinx_zynqmp_mini_qspi_defconfig, where i saw the line: CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_mini_qspi" which i now assume is used as part of the build to identify the header file to be included, is that correct? oh, and there it is in arch/arm/mach-zynqmp/Kconfig: config SYS_CONFIG_NAME string "Board configuration name" default "xilinx_zynqmp" help This option contains information about board configuration name. Based on this option include/configs/.h header will be used for board configuration. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
want to confirm that include/configs/xilinx_zynqmp*.h files seem unused
been a while since i wandered through the innards of u-boot so it's possible this is a silly question. was just placed on a project that involves a xilinx zynqmp-based board, and need to upgrade the version of u-boot that's currently being used. as part of my perusal, i did a quick grep to see what existing boards were doing with any zynqmp-related header files, so i did this from the top of the current tree: $ grep -r "include.*xilinx_zynqmp.*\.h" * include/configs/xilinx_zynqmp_mini.h:#include include/configs/xilinx_zynqmp_mini_emmc.h:#include include/configs/xilinx_zynqmp_mini_qspi.h:#include include/configs/xilinx_zynqmp_mini_nand.h:#include $ i'm aware of the ongoing migration of content from include/configs/*.h files to defconfig files, so the above seems to suggest, given the circular inclusion of those header files with no one else including them, that those files are no longer referenced. my guess is that all that content was migrated to defconfigs but the header files were simply left there. is that a fair conclusion, or might there be something far more subtle i'm overlooking here? rday -- ======== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: [U-Boot] CONFIG_OPTEE
On Tue, 20 Aug 2019, Stephen Segal wrote: > Hi all, > > I'm not sure if this has been noticed or handled already, but it appears > there are two separate config options named CONFIG_OPTEE. > > In drivers/tee/optee/Kconfig: > > config OPTEE > bool "OP-TEE" > depends on ARM_SMCCC > help > This implements the OP-TEE Trusted Execution Environment (TEE) > driver. OP-TEE is a Trusted OS designed primarily to rely on the > ARM TrustZone(R) technology as the underlying hardware isolation > mechanism. This driver can request services from OP-TEE, but also > handle Remote Procedure Calls (RPC) from OP-TEE needed to > execute a service. For more information see: > https://www.op-tee.org > > And in lib/optee/Kconfig: > > config OPTEE > bool "Support OPTEE images" > help > U-Boot can be configured to boot OPTEE images. > Selecting this option will enable shared OPTEE library code and > enable an OPTEE specific bootm command that will perform > additional > OPTEE specific checks before booting an OPTEE image created with > mkimage. > > This has the effect of making these options inter-dependent: it's > impossible to enable one without the other. pretty sure i pointed that out once upon a time, and someone else submitted a patch to resolve that. rday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Difference between _defconfig and _config make switches
On Tue, 25 Jun 2019, Ahmad Ijaz wrote: > Hi Sir, > > I am trying to understand u-boot source code. As a starting point, I > compiled u-boot for beaglebone black and successfully executed it on > beaglebone hardware. > My question is related to compilation step. > > The u-boot can be compiled with the following switches on *make.* > > *1. am335x_beaglebone_defconfig* > *2. am335x_beaglebone_config* > *3. am335x_evm_defconfig* > *4. am335x_evm_config* from scripts/kconfig/Makefile: # Added for U-Boot (backward compatibility) %_config: %_defconfig @: -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] cmd/fpga.c: correct typo, capitalize "Xilinx"
A couple minor tweaks to printed strings in cmd/fpga.c. Signed-off-by: Robert P. J. Day --- diff --git a/cmd/fpga.c b/cmd/fpga.c index b1f224bc6a..62453f0a8f 100644 --- a/cmd/fpga.c +++ b/cmd/fpga.c @@ -458,7 +458,7 @@ U_BOOT_CMD(fpga, 6, 1, do_fpga_wrapper, "0-device key, 1-user key, 2-no encryption.\n" "The optional Userkey address specifies from which address key\n" "has to be used for decryption if user key is selected.\n" - "NOTE: the sceure bitstream has to be created using xilinx\n" + "NOTE: the secure bitstream has to be created using Xilinx\n" "bootgen tool only.\n" #endif ); -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] is "autoconfig.mk" simply a misspelling of "autoconf.mk"?
was going over README.kconfig and noticed these references: $ grep -r autoconfig.mk * doc/README.kconfig: - spl/include/autoconfig.mk(generated by the old config for SPL) doc/README.kconfig: - tpl/include/autoconfig.mk(generated by the old config for TPL) doc/README.kconfig: macros used in makefiles, we can drop include/autoconfig.mk, which makes $ i see no historical references to anything named "autoconfig.mk" -- should i simply assume those are typos for "autoconf.mk"? can submit patch if so. rday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] should all include/configs/*.h headers be included via SYS_CONFIG_NAME?
pretty sure i know the answer to this, but i'm going to ask it anyway ... should all header files under include/configs/ be included in a build either directly or indirectly via the value in CONFIG_SYS_CONFIG_NAME? i'm aware of that Kbuild setting and what it's used for: config SYS_CONFIG_NAME string "Board configuration name" default "zynq-common" help This option contains information about board configuration name. Based on this option include/configs/.h header will be used for board configuration. at which point that header file might well include further header files under include/configs/ and so on. so the question is, are include/configs/ header files meant to be included *exclusively* via CONFIG_SYS_CONFIG_NAME? i ask since, out of curiosity, i did a quick grep to see if any of them were included from anywhere else, and i found all of one hit in the entire code base: $ git grep '#include $ i thought it was odd that there would be a single example of that in the whole code base, even more so since the board file Kconfig board/renesas/ecovec/Kconfig includes: config SYS_CONFIG_NAME default "ecovec" which suggests that header file would have been included anyway. thoughts? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] relationship between "ARM_DCC" and "DEBUG_UART_ARM_DCC"?
On Tue, 23 Apr 2019, Michal Simek wrote: > On 19. 04. 19 13:27, Robert P. J. Day wrote: > > > > just noticed the oddness regarding those two Kbuild symbols: > > > > $ git grep ARM_DCC > > arch/x86/include/asm/acpi_table.h:#define ACPI_DBG2_ARM_DCC 0x000F > > configs/zynq_cse_qspi_defconfig:CONFIG_DEBUG_UART_ARM_DCC=y > > drivers/serial/Kconfig:config DEBUG_UART_ARM_DCC > > drivers/serial/Makefile:obj-$(CONFIG_ARM_DCC) += arm_dcc.o > > drivers/serial/arm_dcc.c:#ifdef CONFIG_DEBUG_UART_ARM_DCC > > include/configs/xilinx_versal.h:#define CONFIG_ARM_DCC > > include/configs/xilinx_zynqmp.h:#define CONFIG_ARM_DCC > > include/configs/zynq-common.h:#define CONFIG_ARM_DCC > > scripts/config_whitelist.txt:CONFIG_ARM_DCC > > $ > > > > strangely(?), there is a Kbuild config directive for the latter: > > > > drivers/serial/Kconfig:config DEBUG_UART_ARM_DCC > > > > but not the former, which is just hardcoded in some xilinx-associated > > header files. is this deliberate? it just seems ... weird. > > Simply none has had time to convert ARM_DCC to Kconfig that's why it > is enabled via base platform. And because debug symbol is in Kconfig > it is enabled for platform which needs it. Feel free to send a patch > to move symbol there. ok, i can do that. i'm assuming the Kconfig file should define both symbols: config ARM_DCC and config DEBUG_UART_ARM_DCC depends on ARM_DCC based on the current Makefile and arm_dcc.c file. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [OT] trying to boot zedboard just to u-boot, having no luck
On Tue, 23 Apr 2019, Michal Simek wrote: > On 20. 04. 19 12:44, Robert P. J. Day wrote: > > > > i've asked on the meta-xilinx mailing list, and rummaged around the > > net, and have failed to do something that should be straightforward -- > > i want to simply boot an avnet zedboard to a recent u-boot and stop > > there; i have no need to go any further for the time being. > > > > i have no problem configuring and building u-boot using: > > > > $ make zynq_zed_defconfig > > > > and as a test, i've tried to download any pre-built SD card > > images/files just to verify that the board boots, with absolutely no > > luck. i've formatted and re-formatted SD cards, populated them with > > allegedly working image files, checked and rechecked jumper settings > > to boot from SD card, used minicom and picocom to connect to the UART > > port ... all i ever see is the power LED come on, and never anything > > else. > > > > if someone can point me at a recipe that is verified to work to get > > u-boot up and running on this zedboard, i would be eternally grateful, > > because i'm running out of ideas. > > I didn't try zed board for quite a long time. > You can look at images distributed via http://zedboard.org/ > or petalinux bsp which should also run on zeboard. actually, just resolved getting SD card to boot so apologies for the interruption ... we're good here. rday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [OT] trying to boot zedboard just to u-boot, having no luck
i've asked on the meta-xilinx mailing list, and rummaged around the net, and have failed to do something that should be straightforward -- i want to simply boot an avnet zedboard to a recent u-boot and stop there; i have no need to go any further for the time being. i have no problem configuring and building u-boot using: $ make zynq_zed_defconfig and as a test, i've tried to download any pre-built SD card images/files just to verify that the board boots, with absolutely no luck. i've formatted and re-formatted SD cards, populated them with allegedly working image files, checked and rechecked jumper settings to boot from SD card, used minicom and picocom to connect to the UART port ... all i ever see is the power LED come on, and never anything else. if someone can point me at a recipe that is verified to work to get u-boot up and running on this zedboard, i would be eternally grateful, because i'm running out of ideas. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] relationship between "ARM_DCC" and "DEBUG_UART_ARM_DCC"?
just noticed the oddness regarding those two Kbuild symbols: $ git grep ARM_DCC arch/x86/include/asm/acpi_table.h:#define ACPI_DBG2_ARM_DCC 0x000F configs/zynq_cse_qspi_defconfig:CONFIG_DEBUG_UART_ARM_DCC=y drivers/serial/Kconfig:config DEBUG_UART_ARM_DCC drivers/serial/Makefile:obj-$(CONFIG_ARM_DCC) += arm_dcc.o drivers/serial/arm_dcc.c:#ifdef CONFIG_DEBUG_UART_ARM_DCC include/configs/xilinx_versal.h:#define CONFIG_ARM_DCC include/configs/xilinx_zynqmp.h:#define CONFIG_ARM_DCC include/configs/zynq-common.h:#define CONFIG_ARM_DCC scripts/config_whitelist.txt:CONFIG_ARM_DCC $ strangely(?), there is a Kbuild config directive for the latter: drivers/serial/Kconfig:config DEBUG_UART_ARM_DCC but not the former, which is just hardcoded in some xilinx-associated header files. is this deliberate? it just seems ... weird. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] "optee" Kbuild seems to have weird dependencies
going over the u-boot.cfg generated from zynq_zed_defconfig, and noticed the following: #define CONFIG_OPTEE_TZDRAM_BASE 0x #define CONFIG_OPTEE_TZDRAM_SIZE 0x000 i thought that was strange as CONFIG_OPTEE was not selected, so i checked, and here's the relevant snippet from lib/optee/Kconfig: config OPTEE bool "Support OPTEE images" help U-Boot can be configured to boot OPTEE images. Selecting this option will enable shared OPTEE library code and enable an OPTEE specific bootm command that will perform additional OPTEE specific checks before booting an OPTEE image created with mkimage. config OPTEE_TZDRAM_SIZE hex "Amount of Trust-Zone RAM for the OPTEE image" default 0x000 help The size of pre-allocated Trust Zone DRAM to allocate for the OPTEE runtime. config OPTEE_TZDRAM_BASE hex "Base address of Trust-Zone RAM for the OPTEE image" default 0x help The base address of pre-allocated Trust Zone DRAM for the OPTEE runtime. those two Kbuild directives are (strangely?) not dependent on OPTEE, which is why they show up in u-boot.cfg. is this deliberate? i know nothing about TEE, but it seems odd that OPTEE-related settings don't depend on OPTEE. am i misreading something? rday p.s. the MAINTAINERS entry for TEE seems incomplete as well: TEE M: Jens Wiklander S: Maintained F: drivers/tee/ F: include/tee.h F: include/tee/ one suspects that should include, at the very least: * lib/optee * include/config/optee ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Zynq: delete long-dead CONFIG_USB_CABLE_CHECK
This Kbuild option disappeared way back in 2014: commit 75504e9592745021006cb8905b5ff5a51d9d1cb3 Author: Mateusz Zalega Date: Wed Apr 30 13:07:48 2014 +0200 ... snip ... CONFIG_USB_CABLE_CHECK was removed. Signed-off-by: Robert P. J. Day --- diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h index 27a8e4d490..c9b56fb9cf 100644 --- a/include/configs/xilinx_zynqmp.h +++ b/include/configs/xilinx_zynqmp.h @@ -66,7 +66,6 @@ #if defined(CONFIG_ZYNQMP_USB) #define CONFIG_SYS_DFU_DATA_BUF_SIZE 0x180 #define DFU_DEFAULT_POLL_TIMEOUT 300 -#define CONFIG_USB_CABLE_CHECK #define CONFIG_THOR_RESET_OFF #define DFU_ALT_INFO_RAM \ "dfu_ram_info=" \ diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h index 94177c6fcb..2f5126c38d 100644 --- a/include/configs/zynq-common.h +++ b/include/configs/zynq-common.h @@ -65,7 +65,6 @@ # define CONFIG_SYS_DFU_DATA_BUF_SIZE 0x60 # define DFU_DEFAULT_POLL_TIMEOUT 300 -# define CONFIG_USB_CABLE_CHECK # define CONFIG_THOR_RESET_OFF # define DFU_ALT_INFO_RAM \ "dfu_ram_info=" \ diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 31c1ba3477..fdf3cd1cfd 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -4497,7 +4497,6 @@ CONFIG_USB_ATMEL_CLK_SEL_PLLB CONFIG_USB_ATMEL_CLK_SEL_UPLL CONFIG_USB_BIN_FIXUP CONFIG_USB_BOOTING -CONFIG_USB_CABLE_CHECK CONFIG_USB_DEVICE CONFIG_USB_DEV_BASE CONFIG_USB_DEV_PULLUP_GPIO -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] doc: delete long-obsolete README.ARM-memory-map
As far back as 2011, "_armboot_start" was being described as "no longer defined": commit 297f18ac0fbeef30ba1c17fe131ca75f09a6e7cf Author: Greg Ungerer Date: Fri Sep 9 22:23:34 2011 +1000 CM4000: fix broken flash base for OpenGear boards Use _bss_start_ofs as the size of the boot loader code+data that we want to protect in the flash. This replaces use of the no longer defined _armboot_start. --- diff --git a/doc/README.ARM-memory-map b/doc/README.ARM-memory-map deleted file mode 100644 index 1b120ac3e1..00 --- a/doc/README.ARM-memory-map +++ /dev/null @@ -1,17 +0,0 @@ -Subject: Re: [PATCH][CFT] bring ARM memory layout in line with the documented behaviour -From: "Anders Larsen" -Date: Thu, 18 Sep 2003 14:15:21 +0200 -To: Wolfgang Denk - -... ->I still see references to _armboot_start, _armboot_end_data, and ->_armboot_end - which role do these play now? Can we get rid of them? -> ->How are they (should they be) set in your memory map above? - -_armboot_start contains the value of CONFIG_SYS_TEXT_BASE (0xA07E); it seems -CONFIG_SYS_TEXT_BASE and _armboot_start are both used for the same purpose in -different parts of the (ARM) code. -Furthermore, the startup code (cpu//start.S) internally uses -another variable (_TEXT_BASE) with the same content as _armboot_start. -I agree that this mess should be cleaned up. -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] MSCC: delete obsolete reference to MSCC_BITBANG_SPI_GPIO
Remove "select MSCC_BITBANG_SPI_GPIO" since Kbuild option was deleted back in commit ace9c103df2875d2b435dbd7b36618020edfd1c0: commit ace9c103df2875d2b435dbd7b36618020edfd1c0 Author: Lars Povlsen Date: Tue Jan 8 10:38:35 2019 +0100 mips: gpio: mscc: Obsoleted gpio-mscc-bitbang-spi.c --- not sure if someone already handled this. diff --git a/arch/mips/mach-mscc/Kconfig b/arch/mips/mach-mscc/Kconfig index 34584a1909..affc4721f8 100644 --- a/arch/mips/mach-mscc/Kconfig +++ b/arch/mips/mach-mscc/Kconfig @@ -29,7 +29,6 @@ config SOC_OCELOT config SOC_LUTON bool "Luton SOC Family" select SOC_VCOREIII - select MSCC_BITBANG_SPI_GPIO help This supports MSCC Luton family of SOCs. -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] getting rid of clearly(?) obsolete doc/README* files?
before i submit a patch, i'll ask permission first -- is it worth submitting patches to delete what appear to be totally obsolete README files? i just stumbled over doc/README.ARM-memory-map, dated Sep 2003, which reads in part: "_armboot_start contains the value of CONFIG_SYS_TEXT_BASE (0xA07E); it seems CONFIG_SYS_TEXT_BASE and _armboot_start are both used for the same purpose in different parts of the (ARM) code. Furthermore, the startup code (cpu//start.S) internally uses another variable (_TEXT_BASE) with the same content as _armboot_start. I agree that this mess should be cleaned up." i checked -- there are no remaining references to _armboot_start, and there's this from 2011: commit 297f18ac0fbeef30ba1c17fe131ca75f09a6e7cf Author: Greg Ungerer Date: Fri Sep 9 22:23:34 2011 +1000 CM4000: fix broken flash base for OpenGear boards Use _bss_start_ofs as the size of the boot loader code+data that we want to protect in the flash. This replaces use of the no longer defined _armboot_start. ... etc etc ... under the circumstances, does that file have any current informational value? i'm pretty sure i've noticed a couple others that seem way out of date. rday -- ======== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/usb/host/Kconfig: Drop CONFIG_ prefix from select
On Sun, 14 Apr 2019, Marek Vasut wrote: > On 4/14/19 12:51 PM, Robert P. J. Day wrote: > > On Sun, 14 Apr 2019, Marek Vasut wrote: > > > >> On 4/14/19 12:06 PM, Robert P. J. Day wrote: > >>> > >>> Kbuild "select" directives should not include "CONFIG_" prefix. > >>> > >>> Signed-off-by: Robert P. J. Day > >> > >> The patch is correct, but does it have any side-effects ? > >> > >>> --- > >>> > >>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > >>> index ba1e6bfa43..96474f4e3b 100644 > >>> --- a/drivers/usb/host/Kconfig > >>> +++ b/drivers/usb/host/Kconfig > >>> @@ -204,7 +204,7 @@ config USB_EHCI_GENERIC > >>> config USB_EHCI_FSL > >>> bool "Support for FSL on-chip EHCI USB controller" > >>> default n > >>> - select CONFIG_EHCI_HCD_INIT_AFTER_RESET > >>> + select EHCI_HCD_INIT_AFTER_RESET > >>> ---help--- > >>> Enables support for the on-chip EHCI controller on FSL chips. > >>> endif # USB_EHCI_HCD > >>> > > > > there are a *ton* of include/configs/ header files that > > already contain: > > > > #define CONFIG_EHCI_HCD_INIT_AFTER_RESET > > And those boards also enable USB_EHCI_FSL ? If so, then it might > also make sense to remove these #define > CONFIG_EHCI_HCD_INIT_AFTER_RESET from the header files. > > I think ./tools/moveconfig.py could help you with that cleanup . ok, i'll take a closer look first chance i get. clearly, there's potentially more cleanup here than just fixing a typo. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/usb/host/Kconfig: Drop CONFIG_ prefix from select
On Sun, 14 Apr 2019, Marek Vasut wrote: > On 4/14/19 12:06 PM, Robert P. J. Day wrote: > > > > Kbuild "select" directives should not include "CONFIG_" prefix. > > > > Signed-off-by: Robert P. J. Day > > The patch is correct, but does it have any side-effects ? > > > --- > > > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > > index ba1e6bfa43..96474f4e3b 100644 > > --- a/drivers/usb/host/Kconfig > > +++ b/drivers/usb/host/Kconfig > > @@ -204,7 +204,7 @@ config USB_EHCI_GENERIC > > config USB_EHCI_FSL > > bool "Support for FSL on-chip EHCI USB controller" > > default n > > - select CONFIG_EHCI_HCD_INIT_AFTER_RESET > > + select EHCI_HCD_INIT_AFTER_RESET > > ---help--- > > Enables support for the on-chip EHCI controller on FSL chips. > > endif # USB_EHCI_HCD > > there are a *ton* of include/configs/ header files that already contain: #define CONFIG_EHCI_HCD_INIT_AFTER_RESET and the only test i can see for it is in drivers/usb/host/ehci-hcd.c: #if defined(CONFIG_EHCI_HCD_INIT_AFTER_RESET) rc = ehci_hcd_init(index, init, >hccr, >hcor); if (rc) return rc; #endif so i would *think* that, given the number of boards that already explicitly include that feature, it's unlikely that fixing that Kconfig file would suddenly reveal an issue that was hidden until now. but that's just a guess. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] very short list of "badref selects" in u-boot source
On Fri, 12 Apr 2019, Robert P. J. Day wrote: > rather than go to the trouble of whipping up a wiki page, i can > present this in a short post to the list. here's the list of what my > script identified as "badref selects" -- those identifiers for which > there is a Kconfig line of the form: > > select X > > where there is no corresponding: > > config X > > the entire list: > > >>>>> BOOTM_LINUX > >>>>> CONFIG_EHCI_HCD_INIT_AFTER_RESET > >>>>> CONFIG_MPC8xx_WATCHDOG > >>>>> CPU_ARM926EJS1 > >>>>> CRC32 > >>>>> GPIO > >>>>> MSCC_BITBANG_SPI_GPIO > >>>>> SPL_DISABLE_OF_CONTROL > >>>>> VEXPRESS_CLK ... snip ... between a couple patches i sent in and the more extensive submissions from chris packham, most of this list has been resolved except for three of them. a couple are isolated but i'm not sure what to do with them: $ git grep MSCC_BITBANG_SPI_GPIO arch/mips/mach-mscc/Kconfig:select MSCC_BITBANG_SPI_GPIO $ and: $ git grep VEXPRESS_CLK drivers/video/Kconfig: select VEXPRESS_CLK $ but it's BOOTM_LINUX that i'm unsure of: $ git grep BOOTM_LINUX common/bootm_os.c:#ifdef CONFIG_BOOTM_LINUX include/config_defaults.h:#define CONFIG_BOOTM_LINUX 1 include/configs/xilinx_versal_mini.h:#undef CONFIG_BOOTM_LINUX include/configs/xilinx_zynqmp_mini.h:#undef CONFIG_BOOTM_LINUX include/configs/zynq_cse.h:#undef CONFIG_BOOTM_LINUX lib/optee/Kconfig: select BOOTM_LINUX scripts/config_whitelist.txt:CONFIG_BOOTM_LINUX $ it's clear that CONFIG_BOOTM_LINUX is simply defined as a hard-coded macro in some header files, so what does it then mean if a Kconfig file selects it? i've never checked what the Kbuild infrastructure does in a case like that -- would it actually define CONFIG_BOOTM_LINUX, despite the fact that there is no associated BOOTM_LINUX Kbuild option? in any event, it's definitely messy. anyway, those are the remnants of "select" directives referring to non-existent Kbuild options. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] delete Kbuild "select" of long-dead SPL_DISABLE_OF_CONTROL
From way back in 2015: commit dffb86e468c8e02ba77283989aefef214d904dc5 Author: Masahiro Yamada Date: Wed Aug 12 07:31:54 2015 +0900 of: flip CONFIG_SPL_DISABLE_OF_CONTROL into CONFIG_SPL_OF_CONTROL As we discussed a couple of times, negative CONFIG options make our life difficult; CONFIG_SYS_NO_FLASH, CONFIG_SYS_DCACHE_OFF, ... and here is another one. Now, there are three boards enabling OF_CONTROL on SPL: - socfpga_arria5_defconfig - socfpga_cyclone5_defconfig - socfpga_socrates_defconfig This commit adds CONFIG_SPL_OF_CONTROL for them and deletes CONFIG_SPL_DISABLE_OF_CONTROL from the other boards to invert the logic. Signed-off-by: Masahiro Yamada Reviewed-by: Tom Rini Reviewed-by: Simon Glass --- AFAICT, simple deletion should be sufficient but i'm willing to be convinced otherwise. diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 3807770362..14347e7c7d 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -116,7 +116,6 @@ config TARGET_SNOW config TARGET_SPRING bool "Spring board" select OF_CONTROL - select SPL_DISABLE_OF_CONTROL select SUPPORT_SPL config TARGET_SMDK5420 @@ -150,7 +149,6 @@ config TARGET_ESPRESSO7420 select OF_CONTROL select PINCTRL select PINCTRL_EXYNOS7420 - select SPL_DISABLE_OF_CONTROL select SUPPORT_SPL endchoice -- ======== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] drivers/usb/host/Kconfig: Drop CONFIG_ prefix from select
Kbuild "select" directives should not include "CONFIG_" prefix. Signed-off-by: Robert P. J. Day --- diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index ba1e6bfa43..96474f4e3b 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -204,7 +204,7 @@ config USB_EHCI_GENERIC config USB_EHCI_FSL bool "Support for FSL on-chip EHCI USB controller" default n - select CONFIG_EHCI_HCD_INIT_AFTER_RESET + select EHCI_HCD_INIT_AFTER_RESET ---help--- Enables support for the on-chip EHCI controller on FSL chips. endif # USB_EHCI_HCD -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] listing apparently "bad" Kconfig options in Makefiles
as a final(?) example of one of my originally Linux kernel-related Kbuild cleanup scripts, i have one that identifies Makefile entries that refer to Kbuild options that are not defined in any Kconfig file (IIRC, they might be defined manually in a defconfig file, i'll have to refresh my memory, but tradition suggests that "CONFIG_"-prefixed variables are meant to be defined in Kconfig files). i ran this script on the entire u-boot code base, and posted the results here (not overly long): https://crashcourse.ca/dokuwiki/doku.php?id=u-boot_make_badref so let me elaborate with a couple examples. first, there's this output: >>>>> NATSEMI ./drivers/net/Makefile:obj-$(CONFIG_NATSEMI) += natsemi.o so what's the story with CONFIG_NATSEMI? first, it clearly is not defined in a Kconfig file anywhere: $ git grep "config NATSEMI" $ so where does it occur? $ git grep CONFIG_NATSEMI README: CONFIG_NATSEMI drivers/net/Makefile:obj-$(CONFIG_NATSEMI) += natsemi.o include/netdev.h:#ifdef CONFIG_NATSEMI scripts/config_whitelist.txt:CONFIG_NATSEMI $ pretty clearly(?), it's documented and tested and whitelisted, while never being defined anywhere. a wild guess suggests it really should say CONFIG_PHY_NATSEMI: $ git grep CONFIG_PHY_NATSEMI configs/brppt1_mmc_defconfig:CONFIG_PHY_NATSEMI=y configs/brppt1_nand_defconfig:CONFIG_PHY_NATSEMI=y configs/brppt1_spi_defconfig:CONFIG_PHY_NATSEMI=y configs/microblaze-generic_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_versal_virt_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu102_rev1_0_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu102_revA_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu102_revB_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu104_revA_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu104_revC_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu106_revA_defconfig:CONFIG_PHY_NATSEMI=y configs/xilinx_zynqmp_zcu111_revA_defconfig:CONFIG_PHY_NATSEMI=y drivers/net/phy/Makefile:obj-$(CONFIG_PHY_NATSEMI) += natsemi.o drivers/net/phy/phy.c:#ifdef CONFIG_PHY_NATSEMI include/config_phylib_all_drivers.h:#define CONFIG_PHY_NATSEMI include/configs/pengwyn.h:#define CONFIG_PHY_NATSEMI include/configs/rut.h:#define CONFIG_PHY_NATSEMI include/configs/spear6xx_evb.h:#define CONFIG_PHY_NATSEMI $ as established back in 2015: commit f96fe2c0a8a72d675532d79df49cbfe3464154a5 Author: Michal Simek Date: Wed Sep 23 19:35:31 2015 +0200 ARM64: zynqmp: Enable NATSEMI phys Signed-off-by: Michal Simek diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h index 5008722bf4..eae1a4988b 100644 --- a/include/configs/xilinx_zynqmp.h +++ b/include/configs/xilinx_zynqmp.h @@ -193,6 +193,7 @@ # define CONFIG_MII # define CONFIG_SYS_FAULT_ECHO_LINK_DOWN # define CONFIG_PHY_MARVELL +# define CONFIG_PHY_NATSEMI # define CONFIG_PHY_TI #endif and as a second (far more trivial) example, there's this: >>>>> RTC_DAVINCI ./drivers/rtc/Makefile:obj-$(CONFIG_RTC_DAVINCI) += davinci.o where does that string occur? apparently, in only one place so it clearly is utterly worthless as it is currently spelled: $ git grep RTC_DAVINCI drivers/rtc/Makefile:obj-$(CONFIG_RTC_DAVINCI) += davinci.o $ anyway, people are free to peruse that page to see if anything jumps out at them. i'll spend a few minutes today wiki'ing all of the scripts so people can run them on whatever part of the code base amuses them. thanks for your patience. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Remove select CRC32 and CONFIG_CRC32
On Sat, 13 Apr 2019, Chris Packham wrote: > Robert points out that we have code selecting CRC32 but nothing that > actually defines this config option. Similarly image.h #defines > CONFIG_CRC32 but nothing tests for it. ... snip ... thanks for all that effort ... my script can *find* stuff like that, but i'm nowhere confident that i'd know how to resolve it once it's found. one last cleanup post coming shortly ... rday -- ==== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] very short list of "badref selects" in u-boot source
rather than go to the trouble of whipping up a wiki page, i can present this in a short post to the list. here's the list of what my script identified as "badref selects" -- those identifiers for which there is a Kconfig line of the form: select X where there is no corresponding: config X the entire list: >>>>> BOOTM_LINUX >>>>> CONFIG_EHCI_HCD_INIT_AFTER_RESET >>>>> CONFIG_MPC8xx_WATCHDOG >>>>> CPU_ARM926EJS1 >>>>> CRC32 >>>>> GPIO >>>>> MSCC_BITBANG_SPI_GPIO >>>>> SPL_DISABLE_OF_CONTROL >>>>> VEXPRESS_CLK first, the two with the "CONFIG_" prefix are obvious typos which should have those prefixes removed. as for the rest, as one example, consider "CRC32": $ git grep "select CRC32" cmd/Kconfig:select CRC32 cmd/Kconfig:select CRC32 drivers/mtd/ubi/Kconfig:select CRC32 fs/btrfs/Kconfig: select CRC32C $ there is no matching "config CRC32" anywhere, although there is: include/image.h:# define CONFIG_CRC32 /* FIT images need CRC32 support */ in any event, others are welcome to decide what to do about that short list of suspicious "select" directives. i am not trying to be annoying, i am merely succeeding. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] doing anything about "bad" Kbuild configuration options?
On Sat, 13 Apr 2019, Chris Packham wrote:
>
> On Sat, 13 Apr 2019, 4:56 AM Robert P. J. Day, wrote:
> Â one of the worst culprits appears to be CONFIG_SPL_BUILD, which
> appears all over the tree, but one can see a recent commit that takes
> that into account:
>
>
> That's not quite right. CONFIG_SPL_BUILD is defined for the Makefile
> just not in Kconfig (I'm on a tablet right now so I can't point you
> to the source).
>
> Â commit 0ef692084363f2de8547db93397c6a69123d26ca
> Â Author: Baruch Siach
> Â Date:Â Â Thu Feb 7 13:21:16 2019 +0200
>
> Â Â Kconfig: fix BUILD_TARGET for ARCH_MVEBU
>
> Â Â Commit dc146ca11187 ("Kconfig: Migrate CONFIG_BUILD_TARGET") made
> the
> Â Â mvebu default build target depend on CONFIG_SPL_BUILD.
> Unfortunately,
> Â Â there is no such Kconfig symbol. Use the CONFIG_SPL symbol instead
> to
> Â Â fix that.
>
> Â Â Cc: Jagan Teki
> Â Â Signed-off-by: Baruch Siach
> Â Â Reviewed-by: Stefan Roese
> Â Â Reviewed-by: Jagan Teki
> Â Â Signed-off-by: Stefan Roese
>
>
> This commit addresses the fact that CONFIG_SPL_BUILD is not
> available to use in Kconfig. It is available to Makefiles, I can't
> remember if it gets defined for source files.
i realize there are such things; however, the standard is that any
options/variables prefixed with "CONFIG_" are typically defined as
part of the Kbuild infrastructure (with the exception of prefixes of
"CONFIG_SYS_").
i think what you're referring to is in scripts/Makefile.spl:
scripts/Makefile.spl:KBUILD_CPPFLAGS += -DCONFIG_SPL_BUILD
i'm not going to make recommendations one way or the other; merely
pointing out that i have scripts that display such things, and people
are free to do what they wish with the results.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] watchdog: fix typo "CONFIG_MPC8XX_WATCHDOG" -> "MPC8XX_WATCHDOG"
Kbuild "select" directive should not use "CONFIG_" prefix. Signed-off-by: Robert P. J. Day --- diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 34e78beb2a..a89cc6edec 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -149,7 +149,7 @@ config WDT_MT7621 config WDT_MPC8xx bool "MPC8xx watchdog timer support" depends on WDT && MPC8xx - select CONFIG_MPC8xx_WATCHDOG + select MPC8xx_WATCHDOG help Select this to enable mpc8xx watchdog timer -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] doing anything about "bad" Kbuild configuration options?
at risk of boring, i'll mention a couple more scripts i have for locating oddities or inconsistencies in the Kbuild structure, which people are welcome to play with. the first is called "find_badref_selects.sh", which specifically locates "select" directives in Kconfig files that are selecting non-existing Kbuild options, which makes them pointless. example (focusing attention on arch/arm directory): $ find_badref_selects.sh arch/arm >>>>> CPU_ARM926EJS1 arch/arm/mach-imx/mx2/Kconfig:20: select CPU_ARM926EJS1 >>>>> SPL_DISABLE_OF_CONTROL arch/arm/mach-exynos/Kconfig:119: select SPL_DISABLE_OF_CONTROL arch/arm/mach-exynos/Kconfig:153: select SPL_DISABLE_OF_CONTROL $ and a second script called "find_badref_make_configs.sh" specifically finds Kconfig references in Makefiles that point to non-existent Kconfig options. for example: $ find_badref_make_configs.sh drivers/gpio >>>>> ADI_GPIO2 ./drivers/gpio/Makefile:obj-$(CONFIG_ADI_GPIO2) += adi_gpio2.o >>>>> DB8500_GPIO ./drivers/gpio/Makefile:obj-$(CONFIG_DB8500_GPIO) += db8500_gpio.o >>>>> DM644X_GPIO ./drivers/gpio/Makefile:obj-$(CONFIG_DM644X_GPIO) += da8xx_gpio.o $ if anyone's interested, i can post those scripts on a couple more wiki pages this weekend, with an example or two. and on that note, i will shut up about this now. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] doing anything about "bad" Kbuild configuration options?
only a few months ago, i jumped into a discussion regarding Kbuild
config options that were defined in some Kconfig* file, but were
unused anywhere in the source tree:
http://u-boot.10912.n7.nabble.com/policy-regarding-unused-code-td351802.html#a351835
many years ago, i wrote a script to locate such entries in the linux
kernel source tree and, once u-boot adoopted the Kbuild build system,
i could obviously use the same script on the u-boot source -- so far,
so good. but i wrote some associated scripts to locate other oddities,
and one of them was to find what i called "badref" options.
now, "unused" options are typically not serious -- a Kbuild option
is defined that is simply not tested anywhere in the source. normally,
that's because someone removed some source and just forgot to remove
the associated Kconfig option.
"badref" options, on the other hand, are exactly the opposite --
options that *are* tested somewhere in the code, but are not defined
anywhere in a Kconfig file. in short, the code is testing some
CONFIG_* option that will never, ever succeed as it isn't defined,
which should typically be treated as a potentially more serious issue.
i wrote up an example of this here:
https://crashcourse.ca/dokuwiki/doku.php?id=u-boot_badref
where you can see the result of running the script and asking it to
scan the entire u-boot "drivers" directory once upon a time -- the
output consists of a string for which the corresponding
CONFIG_ is being tested somewhere in the argument directory,
but for which there is no apparent Kconfig definition; the output for
each string consists of a tree-wide search for that string.
as an example, note the very first example found:
>>>>> ACX517AKN
drivers/video/pxa_lcd.c:201:#ifdef CONFIG_ACX517AKN
drivers/video/pxa_lcd.c:231:#endif /* CONFIG_ACX517AKN */
drivers/video/pxa_lcd.c:297:#endif /* CONFIG_ACX517AKN */
scripts/config_whitelist.txt:15:CONFIG_ACX517AKN
so CONFIG_ACX517AKN is clearly being tested, while there is no
definition for that option *anywhere* in the tree. (the script might
not be perfect, there might be the occasional false negative or
positive, but one can always verify manually if there's any doubt.)
one of the worst culprits appears to be CONFIG_SPL_BUILD, which
appears all over the tree, but one can see a recent commit that takes
that into account:
commit 0ef692084363f2de8547db93397c6a69123d26ca
Author: Baruch Siach
Date: Thu Feb 7 13:21:16 2019 +0200
Kconfig: fix BUILD_TARGET for ARCH_MVEBU
Commit dc146ca11187 ("Kconfig: Migrate CONFIG_BUILD_TARGET") made the
mvebu default build target depend on CONFIG_SPL_BUILD. Unfortunately,
there is no such Kconfig symbol. Use the CONFIG_SPL symbol instead to
fix that.
Cc: Jagan Teki
Signed-off-by: Baruch Siach
Reviewed-by: Stefan Roese
Reviewed-by: Jagan Teki
Signed-off-by: Stefan Roese
the output for that example in my wiki page is a bit overwhelming,
which is why my badref script takes an optional directory to search,
so you can focus your attention as finely as you want. as an example,
check only drivers/mmc, which appears to find exactly four bad
references:
$ find_badref_configs.sh drivers/mmc
>>>>> HSMMC3_8BIT
drivers/mmc/omap_hsmmc.c:1577:#if defined(CONFIG_DRA7XX) &&
defined(CONFIG_HSMMC3_8BIT)
>>>>> MMC_RPMB_TRACE
drivers/mmc/rpmb.c:98:#ifdef CONFIG_MMC_RPMB_TRACE
drivers/mmc/rpmb.c:115:#ifdef CONFIG_MMC_RPMB_TRACE
drivers/mmc/rpmb.c:131:#ifdef CONFIG_MMC_RPMB_TRACE
drivers/mmc/rpmb.c:147:#ifdef CONFIG_MMC_RPMB_TRACE
drivers/mmc/rpmb.c:154:#ifdef CONFIG_MMC_RPMB_TRACE
scripts/config_whitelist.txt:1225:CONFIG_MMC_RPMB_TRACE
>>>>> MMC_SPI_CRC_ON
drivers/mmc/mmc_spi.c:94:#ifdef CONFIG_MMC_SPI_CRC_ON
drivers/mmc/mmc_spi.c:123:#ifdef CONFIG_MMC_SPI_CRC_ON
drivers/mmc/mmc.c:2259:#ifdef CONFIG_MMC_SPI_CRC_ON
scripts/config_whitelist.txt:1228:CONFIG_MMC_SPI_CRC_ON
arch/arm/include/asm/arch-pxa/regs-mmc.h:66:#define MMC_SPI_CRC_ON
(1 << 1)
>>>>> ZYNQ_HISPD_BROKEN
drivers/mmc/zynq_sdhci.c:263:#ifdef CONFIG_ZYNQ_HISPD_BROKEN
scripts/config_whitelist.txt:4637:CONFIG_ZYNQ_HISPD_BROKEN
$
in any event, i am not planning to do anything about this, i just
thought others might want to check whatever part of the code base for
which they are a maintainer, and see if any such things exist. and as
forrest gump once said, "that's all i have to say about that."
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] in drivers/mtd/nand/spi/core.c, what means "#ifdef CONFIG_OF"?
prettu sure there is no Kbuild "config OF" setting, should that be #ifdef CONFIG_OF_CONTROL or something related? i checked for the maintainer of that file, but it listed enough alleged maintainers that i thought i would just ask the list. rday -- ======== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] why does "board_init_r()" accept a second arg of "ulong dest_addr"?
On Fri, 12 Apr 2019, Robert P. J. Day wrote:
> On Fri, 12 Apr 2019, Simon Glass wrote:
>
> > Hi Robert,
> >
> > On Fri, 12 Apr 2019 at 06:31, Robert P. J. Day
> > wrote:
> > >
> > >
> > > was tracing the ARM-based boot sequence and ended up at the call to
> > > board_init_r():
> > >
> > > void board_init_r(gd_t *new_gd, ulong dest_addr)
> > > {
> > > /*
> > > * Set up the new global data pointer. So far only x86 does this
> > > * here.
> > > * TODO(s...@chromium.org): Consider doing this for all archs, or
> > > * dropping the new_gd parameter.
> > > */
> > > ... snip ...
> > >
> > > but as i read board_init_r(), it's not clear what that routine is
> > > doing with that second argument, "dest_addr".
>
> ... snip ...
>
> > I believe this is not used. The value is available in gd->dest_addr
> > and we now read it from there.
> >
> > So perhaps this argument could be dropped.
>
> massive sigh of relief here as i was totally prepared for a response
> like, "oh, come on, how can you not see how it's being used?" :-)
>
> anyway, i can take a shot at a patch unless someone else wants to do
> it. i'm just relieved that it wasn't that dumb a question after all.
i take it back ... there are, of course, calls to board_init_r()
from all over the place, across all architectures, so if someone
higher up the food chain wants to do something about that, that's fine
-- all i needed to confirm was that that second argument wasn't doing
anything. thanks. movin' on ...
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] why does "board_init_r()" accept a second arg of "ulong dest_addr"?
On Fri, 12 Apr 2019, Simon Glass wrote:
> Hi Robert,
>
> On Fri, 12 Apr 2019 at 06:31, Robert P. J. Day wrote:
> >
> >
> > was tracing the ARM-based boot sequence and ended up at the call to
> > board_init_r():
> >
> > void board_init_r(gd_t *new_gd, ulong dest_addr)
> > {
> > /*
> > * Set up the new global data pointer. So far only x86 does this
> > * here.
> > * TODO(s...@chromium.org): Consider doing this for all archs, or
> > * dropping the new_gd parameter.
> > */
> > ... snip ...
> >
> > but as i read board_init_r(), it's not clear what that routine is
> > doing with that second argument, "dest_addr".
... snip ...
> I believe this is not used. The value is available in gd->dest_addr
> and we now read it from there.
>
> So perhaps this argument could be dropped.
massive sigh of relief here as i was totally prepared for a response
like, "oh, come on, how can you not see how it's being used?" :-)
anyway, i can take a shot at a patch unless someone else wants to do
it. i'm just relieved that it wasn't that dumb a question after all.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] why does "board_init_r()" accept a second arg of "ulong dest_addr"?
was tracing the ARM-based boot sequence and ended up at the call to
board_init_r():
void board_init_r(gd_t *new_gd, ulong dest_addr)
{
/*
* Set up the new global data pointer. So far only x86 does this
* here.
* TODO(s...@chromium.org): Consider doing this for all archs, or
* dropping the new_gd parameter.
*/
... snip ...
but as i read board_init_r(), it's not clear what that routine is
doing with that second argument, "dest_addr".
there is no explicit reference to that argument in that routine that
i can see. i backtracked to arch/arm/lib/crt0.S to see the setup for
the call:
/* call board_init_r(gd_t *id, ulong dest_addr) */
mov r0, r9 /* gd_t */
ldr r1, [r9, #GD_RELOCADDR] /* dest_addr */
/* call board_init_r */
#if CONFIG_IS_ENABLED(SYS_THUMB_BUILD)
ldr lr, =board_init_r /* this is auto-relocated! */
bx lr
#else
ldr pc, =board_init_r /* this is auto-relocated! */
#endif
/* we should not return here. */
#endif
so i can see the assignment to registers r0 and r1, and thought maybe
there's something down the road that expects that argument explicitly
in r1 but i can't tell.
i'm currently reading doc/README.arm-relocation to see if i've
overlooked something trivially obvious, but is there a simple
explanation as to the purpose of that second argument being passed to
board_init_r()?
rday
--
========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] how many (few?) supported boards don't specify SYS_VENDOR?
On Wed, 10 Apr 2019, Andy Pont wrote: > Robert wrote... > > > i'd never thought about it so, as a quick check, i just tried this > >to see how many board files actually lived directly under > >board// and got: > > > > $ ls board/*/board.c > > board/sunxi/board.c > > $ > > > >i thought that was interesting -- all of one board > For most boards the primary source file is not called board.c but is > .c. E.g. board/cobra5272/cobra5272.c ack, i totally missed that, sorry. i should know better. rday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] how many (few?) supported boards don't specify SYS_VENDOR?
(yes, more nitpickery for which i apologize ahead of time ...) another oddity that was asked of me yesterday ... was explaining to a couple colleagues how the Kconfig system worked for u-boot, especially this part from doc/README.kconfig: Define CONFIG_SYS_VENDOR="vendor" to compile board//common/* and board///* Define CONFIG_SYS_BOARD="board" to compile board//* (or board///* if CONFIG_SYS_VENDOR is defined) at which point one of those colleagues asked, "how many boards don't specify a vendor? wouldn't that be kind of weird? a board without a vendor?" i'd never thought about it so, as a quick check, i just tried this to see how many board files actually lived directly under board// and got: $ ls board/*/board.c board/sunxi/board.c $ i thought that was interesting -- all of one board (unless i'm misreading something). a quick "git log" shows that that sunxi content was added back in may 2014, before the Kbuild system was incorporated. is that really the only supported board that does not identify a vendor? and if it is, why not just refactor that content to add its vendor (allwinner??), at which point is there any need to support vendorless boards? or perhaps i am just misreading what i'm looking at. it's just a curiosity i had no answer for when asked about. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] content in a defconfig file versus in a header file -- clarification?
On Wed, 10 Apr 2019, Michal Simek wrote: > On 09. 04. 19 13:00, Robert P. J. Day wrote: > > > > i'm rewriting a bunch of u-boot tutorial pages (publicly available > > if anyone wants to read them), > > Would be easier to put link here that others can take a look and review. i've barely started, it's all going to be here after a while: https://crashcourse.ca/dokuwiki/doku.php?id=u-boot lots more to come. rday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] "best practice" for including common header file content?
more excruciatingly pedantic queries ... what is the best practice for header files under include/configs including common header files also in that same directory. i give you: $ git grep zynq-common.h bitmain_antminer_s9.h:#include syzygy_hub.h: * See zynq-common.h for Zynq common configs syzygy_hub.h:#include topic_miami.h: * See zynq-common.h for Zynq common configs topic_miami.h:#include "zynq-common.h" zynq_cse.h: * See zynq-common.h for Zynq common configs zynq_cse.h:#include $ so some of them include "zynq-common.h", while others include . naturally, both work -- does u-boot have a stylistic preference? rday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] content in a defconfig file versus in a header file -- clarification?
i'm rewriting a bunch of u-boot tutorial pages (publicly available if anyone wants to read them), and i want to clarify the proper location to put configuration content -- a defconfig file versus a header file -- knowing that the trend lately has been to move content into defconfig files where appropriate, so some potentially trivial questions. first, each defconfig file represents the configuration for a single, specific target board, so that, in an ideal world, any "CONFIG_" Kbuild settings for that board should be placed there, correct? the exception would be any content that is in some way common across a family of closely-related boards but, other than that, configuration "OPTIONS", as defined in the README file, belong in the board's defconfig file. i ask since, unsurprisingly, there are exceptions. for example, CONFIG_ENV_SIZE is a popular config setting, defined in env/Kconfig (and other Kconfig files), so one would think that that setting should be set in the defconfig files. but for the most part, the majority of settings are in the include/configs/*.h header files. as a specific example, consider the bubblegum 96 board. its defconfig file does not set that Kconfig variable; rather, it's set in include/configs/bubblegum_96.h. it still works fine, of course, but according to current U-Boot standards, would that properly be in the defconfig file? (i have no intention of trying to clean any of that up, just wanting to clarify best practices.) thanks. rday p.s. of course settings like that would belong in any "common" header file covering multiple boards, such as tegra-common.h, zynq-common.h and so on. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] should "make distclean" remove "tools/env/embedded.c"?
was verifying that "make distclean" really removed all generated artifacts of a build and, after building and distcleaning, while "git status" showed no remaining untracked content, there was this: $ git status --ignored On branch master Your branch is up to date with 'origin/master'. Ignored files: (use "git add -f ..." to include in what will be committed) tools/env/embedded.c nothing to commit, working tree clean $ so while that file is clearly produced by a build, and it is referenced in a very short tools/env/.gitignore file: embedded.c fw_printenv fw_printenv_unstripped it is obviously not removed by "make distclean". is this deliberate? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] why is there no ".u-boot.map.cmd" generated?
On Mon, 8 Apr 2019, Chris Packham wrote: > Hi Robert, > > On Mon, Apr 8, 2019 at 4:51 AM Robert P. J. Day wrote: > > > > > > short followup to earlier question ... i was going to check the file > > .u-boot.map.cmd to see which command was used to generate it but, > > unlike numerous other files of that form, that file has no associated > > .cmd file. any reason for that? > > > > The reason is that u-boot.map isn't a target, you can't run 'make > u-boot.map'. It gets generated as side-effect of the final link (see > cmd_u_boot__ in the main Makefile). You can see the command that > generates it in .uboot.cmd. ok, i see how it works (i think). this is the first time i've actually taken a close look at those .u-boot.*.cmd files. just to confirm, each of those files represents a *single* command executed to produce one (or more) of the final artifacts of the build process. and in the case of u-boot.map, it's the "-Map u-boot.map" option to the linker that specifies the output for the map file. it all makes sense once one is clued in. thanks for that. rday p.s. i may have more occasional questions that seem trivially obvious to others, as i am currently digging into parts of u-boot i've never hacked around in before. -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] using objdump/readelf/nm to dump symbols by individual source file?
On Mon, 8 Apr 2019, Chris Packham wrote:
> On Mon, Apr 8, 2019 at 7:45 PM Chris Packham wrote:
> >
> > On Mon, Apr 8, 2019 at 4:29 AM Robert P. J. Day
> > wrote:
> > >
> > >
> > > i'm doing this in the context of building for ARM with a linaro
> > > toolchain, but i'm sure it's equally valid in the context of a native
> > > build.
> > >
> > > i'm trying to generate the same output as u-boot.map, but more
> > > condensed and with each symbol associated with its original source
> > > file (if that's even possible).
> > >
> > > for example, there are a couple weak symbols in board_f.c:
> > >
> > > __weak int arch_cpu_init(void)
> > > {
> > > return 0;
> > > }
> > >
> > > __weak int mach_cpu_init(void)
> > > {
> > > return 0;
> > > }
> > >
> > > so depending on the target board, the final included version of such a
> > > routine might come from board_f.c, or it might be overridden at the
> > > board level.
> > >
> > > you can sort of see this in u-boot.map:
> > >
> > > .text.arch_cpu_init
> > > 0x0x8 common/built-in.o
> > >
> > > ...
> > > .text.mach_cpu_init
> > > 0x04011cac0x8 common/built-in.o
> > > 0x04011cacmach_cpu_init
> > >
> > > except i was hoping to be able to list included symbols by their
> > > *original* source file, and listed one file at a time, so the output
> > > would have the format:
> > >
> > > board_f.o
> > > mach_cpu_init
> > > ... other stuff from board_f.o
> > >
> > > i could swear i once knew how to do this, but i've forgotten (or
> > > perhaps i'm misremembering). is there some variation of objdump,
> > > readelf or nm that will do what i want? i need nothing other than, for
> > > each source file, the symbols that were included in the final ELF file
> > > from that source file.
> > >
> > > can i do this?
> > >
> >
> > nm -l u-boot seems to give me what you're asking for
> >
> >
> > $ nm -l u-boot
> > 0089b8d8 b a_b /home/chrisp/src/u-boot/cmd/load.c:573
> > 0089f62c b act.10860
> > 00857780 t add_ino /home/chrisp/src/u-boot/fs/ubifs/recovery.c:1261
> > 00828b34 T add_mtd_device
> > /home/chrisp/src/u-boot/drivers/mtd/mtdcore.c:410
> > 00829f7c T add_mtd_partitions
> > /home/chrisp/src/u-boot/drivers/mtd/mtdpart.c:865
> > 00835b2c t add_to_list
> > 0085188c t adjust_lpt_heap.isra.1
> > /home/chrisp/src/u-boot/fs/ubifs/lprops.c:635
> > 0086b110 T adler32
> > 008775e0 T __aeabi_idiv /home/chrisp/src/u-boot/arch/arm/lib/lib1funcs.S:251
> > 008776c4 T __aeabi_idivmod
> > /home/chrisp/src/u-boot/arch/arm/lib/lib1funcs.S:340
> > 00877544 T __aeabi_uidiv
> > /home/chrisp/src/u-boot/arch/arm/lib/lib1funcs.S:199
> > 008776ac T __aeabi_uidivmod
> > /home/chrisp/src/u-boot/arch/arm/lib/lib1funcs.S:324
> > 008776ec T __aeabi_uldivmod
> > /home/chrisp/src/u-boot/arch/arm/lib/uldivmod.S:38
> > 00820fd4 t alloc_priv
> > 0081ac20 t alloc_simple /home/chrisp/src/u-boot/common/malloc_simple.c:17
>
> Just re-read your question. You might need to do some post processing
> to group by the source file.
yes, that's the info i'm after, i could swear i once identified a
command that would give it to me in the format i was suggesting. or
perhaps i'm misremembering. thanks.
rday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] why is there no ".u-boot.map.cmd" generated?
On Mon, 8 Apr 2019, Chris Packham wrote: > Hi Robert, > > On Mon, Apr 8, 2019 at 4:51 AM Robert P. J. Day wrote: > > > > > > short followup to earlier question ... i was going to check the file > > .u-boot.map.cmd to see which command was used to generate it but, > > unlike numerous other files of that form, that file has no associated > > .cmd file. any reason for that? > > > > The reason is that u-boot.map isn't a target, you can't run 'make > u-boot.map'. It gets generated as side-effect of the final link (see > cmd_u_boot__ in the main Makefile). You can see the command that > generates it in .uboot.cmd. ah, understood. rday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] why is there no ".u-boot.map.cmd" generated?
short followup to earlier question ... i was going to check the file .u-boot.map.cmd to see which command was used to generate it but, unlike numerous other files of that form, that file has no associated .cmd file. any reason for that? rday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] using objdump/readelf/nm to dump symbols by individual source file?
i'm doing this in the context of building for ARM with a linaro
toolchain, but i'm sure it's equally valid in the context of a native
build.
i'm trying to generate the same output as u-boot.map, but more
condensed and with each symbol associated with its original source
file (if that's even possible).
for example, there are a couple weak symbols in board_f.c:
__weak int arch_cpu_init(void)
{
return 0;
}
__weak int mach_cpu_init(void)
{
return 0;
}
so depending on the target board, the final included version of such a
routine might come from board_f.c, or it might be overridden at the
board level.
you can sort of see this in u-boot.map:
.text.arch_cpu_init
0x0x8 common/built-in.o
...
.text.mach_cpu_init
0x04011cac0x8 common/built-in.o
0x04011cacmach_cpu_init
except i was hoping to be able to list included symbols by their
*original* source file, and listed one file at a time, so the output
would have the format:
board_f.o
mach_cpu_init
... other stuff from board_f.o
i could swear i once knew how to do this, but i've forgotten (or
perhaps i'm misremembering). is there some variation of objdump,
readelf or nm that will do what i want? i need nothing other than, for
each source file, the symbols that were included in the final ELF file
from that source file.
can i do this?
rday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] has anyone documented the entire "make ..._defconfig" process?
for the sake of an upcoming embedded linux class, i want to demonstrate how various files in the current u-boot contribute to, and are processed by, the initial configuration step to finally produce the resulting .config file. first, a possibly dumb question -- is the .config file the sole generated artifact of the configuration process? it would appear to be based on using git to see what else was created, and .config seems to be it. is that true? and getting into the meat of the question, as an example, i decided to document how u-boot processes numerous files to produce that .config file for the zynq zedboard, and i've already written some of that here: https://crashcourse.ca/dokuwiki/doku.php?id=u-boot_configuration the point is to show how, from the simple command: $ make zynq_zed_defconfig u-boot consults various Makefile, Kconfig, config.mk files, board files and so on to come up with the final .config. if someone already did that once upon a time, that'd be great, but i'm going to guess i'm on my own here. thoughts? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Makefile: have "make distclean" remove CHANGELOG
Ensure that "make distclean" deletes an existing CHANGELOG file. Signed-off-by: Robert P. J. Day --- diff --git a/Makefile b/Makefile index 3be9fc5c34..b9e8b0952c 100644 --- a/Makefile +++ b/Makefile @@ -1795,7 +1795,7 @@ distclean: mrproper -o -name '.*.rej' -o -name '*%' -o -name 'core' \ -o -name '*.pyc' \) \ -type f -print | xargs rm -f - @rm -f boards.cfg + @rm -f boards.cfg CHANGELOG backup: F=`basename $(srctree)` ; cd .. ; \ -- ======== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] should "BUILD_DIR" say "KBUILD_OUTPUT" in manual?
pretty sure it should, but on manual wiki page: http://www.denx.de/wiki/view/DULG/UBootConfiguration should references to "BUILD_DIR" actually refer to "KBUILD_OUTPUT"? i can fix that, just want to make sure it's correct. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] common/board_f.c: init_sequence_f_r used for which arches?
just noticed in common/board_f.c the inconsistency: #if defined(CONFIG_X86) || defined(CONFIG_ARC) /* * For now this code is only used on x86. ... snip ... * NOTE: At present only x86 uses this route, but it is intended that * all archs will move to this when generic relocation is implemented. */ so should the comment be changed to refer to both x86 and arc, or is there a long-term plan for all archs, or what? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] policy regarding unused code
On Tue, 11 Dec 2018, Tom Rini wrote: ... snip ... > > This is not a small list and a lot of them we probably want to keep. > > > > ['CONFIG_MX8M', 'CONFIG_POWER_PMIC_MAX77693', 'CONFIG_TPM2_TIS_SANDBOX', > > 'CONFIG_TPM_ST33ZP24_SPI', 'CONFIG_USB_SL811HS', 'CONFIG_RAM_SUPPORT', > > 'CONFIG_BCM2835_WDT', 'CONFIG_ENV_IS_IN_SATA', 'CONFIG_IO64', > > 'CONFIG_NAND_SUPPORT', 'CONFIG_NOR_SUPPORT', 'CONFIG_RISCV_ISA_A', > > 'CONFIG_I2C_MUX_GPIO', 'CONFIG_POWER_FG_MAX17042', 'CONFIG_DNET', > > 'CONFIG_CMD_SH_ZIMAGEBOOT', 'CONFIG_USE_DEFAULT_ENV_FILE', > > 'CONFIG_CMD_IOTRACE', 'CONFIG_ALI152X', 'CONFIG_M5271', > > 'CONFIG_CPU_MPC83XX', 'CONFIG_NXP_TDA19988', 'CONFIG_IMX', ... big snip ... > I suspect this splits into three categories: > - Dead symbols and code to drop. > - Typos/thinkos > - Mistake in your grep? I see CONFIG_VIRTIO_SANDBOX is used today for > example. what did you run to get that list of CONFIG_* symbols? years ago, i wrote some scripts that scanned the linux source tree looking for things like that; i just dragged that script out of mothballs and ran it against the current u-boot tree and got over 4,500 lines of output, but my script lists apparently unused CONFIG variables, then does a recursive search against a given directory to show anywhere that symbol shows up, a symbol at a time. for example, my script for "badref" goes looking for CONFIG settings that are being tested somewhere but that have no corresponding "config" stanza in a Kconfig file somewhere. $ find_badref_configs.sh drivers the first few lines of output: >>>>> ACX517AKN drivers/video/pxa_lcd.c:201:#ifdef CONFIG_ACX517AKN drivers/video/pxa_lcd.c:231:#endif /* CONFIG_ACX517AKN */ drivers/video/pxa_lcd.c:297:#endif /* CONFIG_ACX517AKN */ scripts/config_whitelist.txt:15:CONFIG_ACX517AKN >>>>> ACX544AKN drivers/video/pxa_lcd.c:233:#ifdef CONFIG_ACX544AKN drivers/video/pxa_lcd.c:263:#endif /* CONFIG_ACX544AKN */ scripts/config_whitelist.txt:16:CONFIG_ACX544AKN >>>>> ADNPESC1 drivers/net/smc9.h:253:#ifdef CONFIG_ADNPESC1 drivers/net/smc9.h:262:#ifdef CONFIG_ADNPESC1 drivers/net/smc9.h:444:#elif defined(CONFIG_ADNPESC1) scripts/config_whitelist.txt:20:CONFIG_ADNPESC1 ... snip ... as you can see, that shows that there is a CONFIG_ACX517AKN being tested, while there is no apparent "config" definition for it anywhere (not sure whether being in the whitelist.txt file means anything relative to that). and so on, and so on. i can see the OP's FPGA_LATTICE in my output: >>>>> FPGA_LATTICE drivers/fpga/Makefile:13:obj-$(CONFIG_FPGA_LATTICE) += ivm_core.o lattice.o drivers/fpga/fpga.c:103:#if defined(CONFIG_FPGA_LATTICE) drivers/fpga/fpga.c:276:#if defined(CONFIG_FPGA_LATTICE) drivers/fpga/fpga.c:318:#if defined(CONFIG_FPGA_LATTICE) which is clearly being tested, while never being defined. so, yes, my script locates a *ton* of variables like that. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] so u-boot can be configured to try to update itself on every boot?
On Wed, 29 Mar 2017, Wolfgang Denk wrote: > Dear Robert, > > In message <alpine.lfd.2.20.1703290927110.21...@uk63952.mitel.com> you wrote: > > > > kind of a trivial question but i was just perusing the code related > > to FIT images and ran across this in main.c: > ... > > #if defined(CONFIG_UPDATE_TFTP) > > update_tftp(0UL, NULL, NULL);<- THERE > > #endif /* CONFIG_UPDATE_TFTP */ > > ... snip ... > > > > i'm assuming that, given the proper configuration, u-boot will try > > to update its own binary on every single boot, yes? not sure why i > > never noticed that before. > > This is documented in the "README" and especially in the > "doc/README.update" files. It also describes how one would normally > use the "updatefile" environment variable to enable / disable this > feature. But yes, if you keep this vaiable around, this will repeat > on every boot, according to good old UNIX philosophy: > > "UNIX was not designed to stop you from doing stupid things, because > that would also stop you from doing clever things." - Doug Gwyn yup, i eventually found that README.update file, this behaviour is just fine for what i'm doing, thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] is the sandbox FIT image demo broken?
i'm following along the instructions to use the sandbox to demo a
FIT image:
$ make O=sandbox sandbox_config
$ make O=sandbox
$ ./test/image/test-fit.py -u sandbox/u-boot
but running that last command produces only:
FIT Tests
=
Warning (unit_address_vs_reg): Node /reset@0 has a unit name, but no reg
property
Warning (unit_address_vs_reg): Node /images/kernel@1 has a unit name, but no
reg property
Warning (unit_address_vs_reg): Node /images/kernel@2 has a unit name, but no
reg property
Warning (unit_address_vs_reg): Node /images/fdt@1 has a unit name, but no reg
property
Warning (unit_address_vs_reg): Node /images/fdt@1/signature@1 has a unit name,
but no reg property
Warning (unit_address_vs_reg): Node /images/ramdisk@1 has a unit name, but no
reg property
Warning (unit_address_vs_reg): Node /images/ramdisk@2 has a unit name, but no
reg property
Warning (unit_address_vs_reg): Node /configurations/conf@1 has a unit name, but
no reg property
Kernel load
Traceback (most recent call last):
File "./test/image/test-fit.py", line 481, in
run_tests()
File "./test/image/test-fit.py", line 470, in run_tests
run_fit_test(mkimage, options.u_boot)
File "./test/image/test-fit.py", line 385, in run_fit_test
stdout = command.Output(u_boot, '-d', control_dtb, '-c', cmd)
File "./test/image/../../tools/patman/command.py", line 109, in Output
return RunPipe([cmd], capture=True, raise_on_error=raise_on_error).stdout
File "./test/image/../../tools/patman/command.py", line 91, in RunPipe
raise Exception("Error running '%s': %s" % (user_pipestr, str))
Exception: Error running 'sandbox/u_boot -d /tmp/tmp7Cs2dr/u-boot.dtb -c
sb load hostfs 0 1000 /tmp/tmp7Cs2dr/test.fit
fdt addr 1000
bootm start 1000
bootm loados
sb save hostfs 0 4 /tmp/tmp7Cs2dr/kernel-out.bin da3
sb save hostfs 0 8 /tmp/tmp7Cs2dr/fdt-out.dtb c1
sb save hostfs 0 c /tmp/tmp7Cs2dr/ramdisk-out.bin 11ef
sb save hostfs 0 10 /tmp/tmp7Cs2dr/loadables1-out.bin da3
sb save hostfs 0 14 /tmp/tmp7Cs2dr/loadables2-out.bin 11ef
reset
':
$
i could have sworn that, once upon a time, there was more output
than this. am i misremembering? is this what i should expect?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] confusing error message in common/update.c
at the top of that file: #if !(defined(CONFIG_FIT) && defined(CONFIG_OF_LIBFDT)) #error "CONFIG_FIT and CONFIG_OF_LIBFDT are required for auto-update feature" #endif #if defined(CONFIG_UPDATE_TFTP) && !defined(CONFIG_MTD_NOR_FLASH) #error "CONFIG_UPDATE_TFTP and !CONFIG_MTD_NOR_FLASH needed for legacy behaviour" #endif i get the first #error message, it actually matches the test being done. but that second error message doesn't seem to make sense in terms of matching what is being tested; it seems to be testing two conditions, then generating an #error message saying that what seems to be true is exactly what is "needed." am i just misreading that? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] so u-boot can be configured to try to update itself on every boot?
kind of a trivial question but i was just perusing the code related
to FIT images and ran across this in main.c:
/* We come here after U-Boot is initialised and ready to process commands */
void main_loop(void)
{
const char *s;
bootstage_mark_name(BOOTSTAGE_ID_MAIN_LOOP, "main_loop");
#ifdef CONFIG_VERSION_VARIABLE
setenv("ver", version_string); /* set version variable */
#endif /* CONFIG_VERSION_VARIABLE */
cli_init();
run_preboot_environment_command();
#if defined(CONFIG_UPDATE_TFTP)
update_tftp(0UL, NULL, NULL);<- THERE
#endif /* CONFIG_UPDATE_TFTP */
... snip ...
i'm assuming that, given the proper configuration, u-boot will try to
update its own binary on every single boot, yes? not sure why i never
noticed that before.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] should u-boot have FIT support even without selecting CONFIG_FIT?
not sure if i'm misreading this, but in the top-level Kconfig file, i can see how one selects support for FIT images: config FIT bool "Support Flattened Image Tree" select MD5 help This option allows you to boot the new uImage structure, Flattened Image Tree. FIT is formally a FDT, which can include images of various types (kernel, FDT blob, ramdisk, etc.) in a single blob. To boot this new uImage structure, pass the address of the blob to the "bootm" command. FIT is very flexible, supporting compression, multiple images, multiple configurations, verification through hashing and also verified boot (secure boot using RSA). if FIT config FIT_SIGNATURE bool "Enable signature verification of FIT uImages" ... etc etc ..., so far, so good. but in the tools/ directory, there's this in the Makefile: hostprogs-y += dumpimage mkimage hostprogs-$(CONFIG_FIT_SIGNATURE) += fit_info fit_check_sign that seems to make sense, the host progs dumpimage and mkimage will be built regardless of whether or not FIT support is selected, but further down: # common objs for dumpimage and mkimage dumpimage-mkimage-objs := aisimage.o \ atmelimage.o \ $(FIT_SIG_OBJS-y) \ common/bootm.o \ lib/crc32.o \ default_image.o \ lib/fdtdec_common.o \ lib/fdtdec.o \ fit_common.o \ fit_image.o \ common/image-fit.o \ ... snip ... isn't this adding at least a few FIT-related routines to those hostprogs, regardless of whether FIT support is selected? can someone clarify this? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] building cross_tools, _POSIX_C_SOURCE and _XOPEN_SOURCE are redefined
On Fri, 17 Mar 2017, Tom Rini wrote: > On Wed, Mar 15, 2017 at 04:02:20AM -0400, Robert P. J. Day wrote: > > > > to build cross_tools, i ran: > > > > $ make sandbox_defconfig > > $ make cross_tools > > > > and while it appeared to work, i got: > > > > ... snip ... > > > > LDFLAGS="" python ./lib/libfdt/setup.py \ > > "-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer > > -DCONFIG_FIT_SIGNATURE -include ./include/libfdt_env.h -idirafterinclude > > -idirafter./arch/sandbox/include -I./lib/libfdt -I./tools -DUSE_HOSTCC > > -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE " lib/libfdt/fdt.c > > lib/libfdt/fdt_ro.c lib/libfdt/fdt_rw.c lib/libfdt/fdt_strerror.c > > lib/libfdt/fdt_wip.c lib/libfdt/fdt_region.c lib/libfdt/fdt_sw.c > > tools/libfdt_wrap.c > > In file included from /usr/include/python2.7/pyconfig.h:6:0, > > from /usr/include/python2.7/Python.h:8, > > from tools/libfdt_wrap.c:143: > > /usr/include/python2.7/pyconfig-64.h:1203:0: warning: "_POSIX_C_SOURCE" > > redefined > > #define _POSIX_C_SOURCE 200112L > > ^ > > In file included from /usr/include/stdint.h:25:0, > > from > > /usr/lib/gcc/x86_64-redhat-linux/5.3.1/include/stdint.h:9, > > from ././include/compiler.h:19, > > from ././include/libfdt_env.h:12, > > from :0: > > /usr/include/features.h:225:0: note: this is the location of the previous > > definition > > # define _POSIX_C_SOURCE 200809L > > ^ > > In file included from /usr/include/python2.7/pyconfig.h:6:0, > > from /usr/include/python2.7/Python.h:8, > > from tools/libfdt_wrap.c:143: > > /usr/include/python2.7/pyconfig-64.h:1225:0: warning: "_XOPEN_SOURCE" > > redefined > > #define _XOPEN_SOURCE 600 > > ^ > > In file included from /usr/include/stdint.h:25:0, > > from > > /usr/lib/gcc/x86_64-redhat-linux/5.3.1/include/stdint.h:9, > > from ././include/compiler.h:19, > > from ././include/libfdt_env.h:12, > > from :0: > > /usr/include/features.h:166:0: note: this is the location of the previous > > definition > > # define _XOPEN_SOURCE 700 > > ^ > > > > > > not sure if that concerns anyone enough to want to tweak it. > > This is the second report I've gotten about this. But, we don't set any > of those things directly. It's something related to the python install > you have. Can you please dig a bit more? Thanks! if no one else has figured out what is going on here, i'll try poking around this weekend. but AFAIK, i haven't done anything out of the ordinary with my python installation. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] testing sandbox FIT image: "Expected '%s' but not found in output:"
Data Size:193 Bytes = 193 Bytes
Architecture: Sandbox
Sign algo:sha1,rsa2048:dev
Sign value: unavailable
Timestamp:unavailable
Verifying Hash Integrity ... sha1,rsa2048:dev- OK
Booting using the fdt blob at 0x002d30
Loading Kernel Image ... OK
3491 bytes written in 0 ms
193 bytes written in 0 ms
4591 bytes written in 0 ms
3491 bytes written in 0 ms
4591 bytes written in 0 ms
Traceback (most recent call last):
File "./test/image/test-fit.py", line 481, in
run_tests()
File "./test/image/test-fit.py", line 470, in run_tests
run_fit_test(mkimage, options.u_boot)
File "./test/image/test-fit.py", line 395, in run_fit_test
line = find_matching(stdout, 'Booting using the FDT blob at ')
File "./test/image/test-fit.py", line 286, in find_matching
raise ValueError('Test aborted')
ValueError: Test aborted
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] under tools/, need couple more cleanings and .gitignore entries
this cleanup should be part of a single patch, but since i'm not confident i can do it properly, i will simply explain. before configure and build: $ git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean $ next: $ make sandbox_defconfig $ make cross_tools ... $ git status On branch master Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add ..." to include in what will be committed) tools/_libfdt.so tools/libfdt.py tools/libfdt_wrap.c nothing added to commit but untracked files present (use "git add" to track) $ then after doing a real cleaning: $ make distclean $ git status On branch master Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add ..." to include in what will be committed) tools/libfdt.py tools/libfdt_wrap.c nothing added to commit but untracked files present (use "git add" to track) $ all this suggests a more thorough cleaning, and some entries added to tools/.gitignore, which i will leave to someone higher up the food chain. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] building cross_tools, _POSIX_C_SOURCE and _XOPEN_SOURCE are redefined
to build cross_tools, i ran: $ make sandbox_defconfig $ make cross_tools and while it appeared to work, i got: ... snip ... LDFLAGS="" python ./lib/libfdt/setup.py \ "-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DCONFIG_FIT_SIGNATURE -include ./include/libfdt_env.h -idirafterinclude -idirafter./arch/sandbox/include -I./lib/libfdt -I./tools -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE " lib/libfdt/fdt.c lib/libfdt/fdt_ro.c lib/libfdt/fdt_rw.c lib/libfdt/fdt_strerror.c lib/libfdt/fdt_wip.c lib/libfdt/fdt_region.c lib/libfdt/fdt_sw.c tools/libfdt_wrap.c In file included from /usr/include/python2.7/pyconfig.h:6:0, from /usr/include/python2.7/Python.h:8, from tools/libfdt_wrap.c:143: /usr/include/python2.7/pyconfig-64.h:1203:0: warning: "_POSIX_C_SOURCE" redefined #define _POSIX_C_SOURCE 200112L ^ In file included from /usr/include/stdint.h:25:0, from /usr/lib/gcc/x86_64-redhat-linux/5.3.1/include/stdint.h:9, from ././include/compiler.h:19, from ././include/libfdt_env.h:12, from :0: /usr/include/features.h:225:0: note: this is the location of the previous definition # define _POSIX_C_SOURCE 200809L ^ In file included from /usr/include/python2.7/pyconfig.h:6:0, from /usr/include/python2.7/Python.h:8, from tools/libfdt_wrap.c:143: /usr/include/python2.7/pyconfig-64.h:1225:0: warning: "_XOPEN_SOURCE" redefined #define _XOPEN_SOURCE 600 ^ In file included from /usr/include/stdint.h:25:0, from /usr/lib/gcc/x86_64-redhat-linux/5.3.1/include/stdint.h:9, from ././include/compiler.h:19, from ././include/libfdt_env.h:12, from :0: /usr/include/features.h:166:0: note: this is the location of the previous definition # define _XOPEN_SOURCE 700 ^ not sure if that concerns anyone enough to want to tweak it. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] test-fit.py: Minor grammar/spelling/clarification tweaks
* Add note that execution needs Python development package installed
* Standardize on upper case "FIT", "FDT" as necessary for clarity
* Fix "tempoerary", "linex" typos
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
diff --git a/test/image/test-fit.py b/test/image/test-fit.py
index db0649f..b0d0538 100755
--- a/test/image/test-fit.py
+++ b/test/image/test-fit.py
@@ -11,6 +11,9 @@
# make O=sandbox sandbox_config
# make O=sandbox
# ./test/image/test-fit.py -u sandbox/u-boot
+#
+# Note: The above testing requires the Python development package, typically
+# called python-devel or something similar.
import doctest
from optparse import OptionParser
@@ -115,8 +118,8 @@ base_fdt = '''
};
'''
-# This is the U-Boot script that is run for each test. First load the fit,
-# then do the 'bootm' command, then save out memory from the places where
+# This is the U-Boot script that is run for each test. First load the FIT,
+# then run the 'bootm' command, then save out memory from the places where
# we expect 'bootm' to write things. Then quit.
base_script = '''
sb load hostfs 0 %(fit_addr)x %(fit)s
@@ -266,7 +269,7 @@ def find_matching(text, match):
>>> find_matching('first line:10\\nsecond_line:20', 'first line:')
'10'
->>> find_matching('first line:10\\nsecond_line:20', 'second linex')
+>>> find_matching('first line:10\\nsecond_line:20', 'second line')
Traceback (most recent call last):
...
ValueError: Test aborted
@@ -389,7 +392,7 @@ def run_fit_test(mkimage, u_boot):
fail('Ramdisk loaded but should not be', stdout)
# Find out the offset in the FIT where U-Boot has found the FDT
-line = find_matching(stdout, 'Booting using the fdt blob at ')
+line = find_matching(stdout, 'Booting using the FDT blob at ')
fit_offset = int(line, 16) - params['fit_addr']
fdt_magic = struct.pack('>L', 0xd00dfeed)
data = read_file(fit)
@@ -469,7 +472,7 @@ def run_tests():
print '\nTests passed'
print 'Caveat: this is only a sanity check - test coverage is poor'
-# Remove the tempoerary directory unless we are asked to keep it
+# Remove the temporary directory unless we are asked to keep it
if options.keep:
print "Output files are in '%s'" % base_dir
else:
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] .gitignore: Ignore the generated top-level "sandbox/" directory
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca> --- am i safe in assuming that the top-level sandbox/ directory only ever exists as the result of a build? diff --git a/.gitignore b/.gitignore index 7fac5b3..32a8d5b 100644 --- a/.gitignore +++ b/.gitignore @@ -48,6 +48,7 @@ /LOG /spl/ /tpl/ +/sandbox/ /defconfig # -- ==== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] GPIO: Correct doc typo "confguration" -> "configuration"
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca> --- Since it's just inline doc, should have no runtime effects. diff --git a/drivers/gpio/db8500_gpio.c b/drivers/gpio/db8500_gpio.c index db32db6..eefb56d 100644 --- a/drivers/gpio/db8500_gpio.c +++ b/drivers/gpio/db8500_gpio.c @@ -174,7 +174,7 @@ void db8500_gpio_set_output(unsigned gpio, int val) /** * config_pin - configure a pin's mux attributes - * @cfg: pin confguration + * @cfg: pin configuration * * Configures a pin's mode (alternate function or GPIO), its pull up status, * and its sleep mode based on the specified configuration. The @cfg is -- ==== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] where is (eg) "BOOT_TARGET_DEVICES_references_MMC_without_CONFIG_CMD_MMC" defined?
i'm sure i'm missing something obvious, but i'm perusing "include/config_distro_bootcmd.h" for the first time, and i can understand the *principle* behind: /* * A note on error handling: It is possible for BOOT_TARGET_DEVICES to * reference a device that is not enabled in the U-Boot configuration, e.g. * it may include MMC in the list without CONFIG_CMD_MMC being enabled. Given * that BOOT_TARGET_DEVICES is a macro that's expanded by the C pre-processor * at compile time, it's not possible to detect and report such problems via * a simple #ifdef/#error combination. Still, the code needs to report errors. * The best way I've found to do this is to make BOOT_TARGET_DEVICES expand to * reference a non-existent symbol, and have the name of that symbol encode * the error message. Consequently, this file contains references to e.g. * BOOT_TARGET_DEVICES_references_MMC_without_CONFIG_CMD_MMC. Given the * prevalence of capitals here, this looks like a pre-processor macro and * hence seems like it should be all capitals, but it's really an error * message that includes some other pre-processor symbols in the text. */ but, still, how is that name resolved to the corresponding error message? what am i missing here? rday -- ======== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] drivers/video/cfb_console.c: Correct "COFNIG_NDS32" typo.
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index a4cbc44..3c0696e 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -1968,7 +1968,7 @@ static void *video_logo(void)
static int cfb_fb_is_in_dram(void)
{
bd_t *bd = gd->bd;
-#if defined(CONFIG_ARM) || defined(CONFIG_AVR32) || defined(COFNIG_NDS32) || \
+#if defined(CONFIG_ARM) || defined(CONFIG_AVR32) || defined(CONFIG_NDS32) || \
defined(CONFIG_SANDBOX) || defined(CONFIG_X86)
ulong start, end;
int i;
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] scripts to sanity-check the Kconfig files
On Fri, 13 Jan 2017, Masahiro Yamada wrote: > Hi Michal, > > 2017-01-05 0:22 GMT+09:00 Michal Simek <mon...@monstr.eu>: > > I looked at this. Correct name should be CONFIG_CMD_MX_CYCLIC and for > > the rest s/CONFIG_MX_CYCLIC/CONFIG_CMD_MX_CYCLIC/g with move to defconfig. > > + in Kconfig there should be dependecy on CMD_MEMORY. > > Could you fix this please? i wasn't sure if someone was expecting *me* to fix this simply because i pointed it out, but don't forget, there is a *ton* of Kbuild cleanup that could be done: http://www.crashcourse.ca/wiki/index.php/U-Boot_Kconfig_cleanup rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] final u-boot cleanup -- Makefiles testing non-existent CONFIG vars
last example of cleanup script for today, i promise. one more cleanup script i wrote a while back identified something very specific; Makefiles that were testing CONFIG_ variables when those variables did not seem to be set anywhere. as in, if a Makefile contained the line: obj-$(CONFIG_RDAY) += rday.o it would only make sense that the variable "CONFIG_RDAY" would need to be set *somewhere* (or at the very least defined in a Kconfig file), otherwise, that file would never be compiled. i dumped the output of that script to the same wiki page: http://www.crashcourse.ca/wiki/index.php/U-Boot_Kconfig_cleanup it's the last section, and it might contain a few false positives since the Makefile itself might hardcode that variable, or might add a compilation option of "-DCONFIG_RDAY", and so on. for the most part, though, the list looks pretty good. as an example, there's this: >>>>> ALI152X ./drivers/misc/Makefile:obj-$(CONFIG_ALI152X) += ali512x.o that means that that Makefile is testing that variable, when it does not seem to be set by anything in the entire code base: $ grep -r ALI152X * drivers/misc/Makefile:obj-$(CONFIG_ALI152X) += ali512x.o $ here's another example: >>>>> CMD_FITUPD ./cmd/Makefile:obj-$(CONFIG_CMD_FITUPD) += fitupd.o absolutely nothing sets that variable, so that command will never be compiled into the image. one suspects that an entry for that command should be added to cmd/Kconfig, no? finally, here's an interesting example: >>>>> YAFFS2 ./fs/Makefile:obj-$(CONFIG_YAFFS2) += yaffs2/ ./cmd/Makefile:obj-$(CONFIG_YAFFS2) += yaffs2.o and if you search for the string "YAFFS2", you get: cmd/yaffs2.c:#ifdef YAFFS2_DEBUG cmd/Makefile:obj-$(CONFIG_YAFFS2) += yaffs2.o fs/yaffs2/yaffs_packedtags1.h:/* This is used to pack YAFFS1 tags, not YAFFS2 tags. */ fs/yaffs2/yaffs_guts.h:#define YAFFS_MIN_YAFFS2_CHUNK_SIZE 1024 fs/yaffs2/yaffs_guts.h:#define YAFFS_MIN_YAFFS2_SPARE_SIZE 32 fs/yaffs2/yaffs_guts.h:/* Sequence numbers are used in YAFFS2 to determine block allocation order. fs/yaffs2/yaffs_guts.h:/* Stuff used for extended tags in YAFFS2 */ fs/yaffs2/yaffs_guts.h: /* YAFFS2 stuff */ fs/yaffs2/yaffs_guts.h: /* Extra info if this is an object header (YAFFS2 only) */ fs/yaffs2/yaffs_guts.h: * However, if this state is returned on a YAFFS2 device, fs/yaffs2/yaffs_packedtags2.h:/* This is used to pack YAFFS2 tags, not YAFFS1tags. */ fs/yaffs2/Makefile: -DCONFIG_YAFFS_YAFFS2 -DNO_Y_INLINE \ fs/yaffs2/yaffs_yaffs2.h:#ifndef __YAFFS_YAFFS2_H__ fs/yaffs2/yaffs_yaffs2.h:#define __YAFFS_YAFFS2_H__ fs/yaffs2/yaffs_guts.c: * Correction for YAFFS2: This could happen quite a lot and we fs/yaffs2/yaffs_guts.c: * Backwards scanning YAFFS2: The old one is what fs/yaffs2/yaffs_guts.c: /* Handle YAFFS2 case (backward scanning) fs/yaffs2/yaffs_mtdif2.c:/* mtd interface for YAFFS2 */ fs/Makefile:obj-$(CONFIG_YAFFS2) += yaffs2/ scripts/config_whitelist.txt:CONFIG_YAFFS2 uh, this line looks interesting: fs/yaffs2/Makefile: -DCONFIG_YAFFS_YAFFS2 -DNO_Y_INLINE \ is that a typo? should it read: fs/yaffs2/Makefile: -DCONFIG_YAFFS2 -DNO_Y_INLINE \ anyway, that's it for today ... feel free to peruse that new list to see what parts of Makefiles seem to not be compiled. rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday \ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Kconfig cleanup -- identifying CONFIG variables not defined in any Kconfig file
as a followup to my earlier post, one of my other linux kernel cleanup scripts was to identify "CONFIG_*" variables that *were* being tested in the source somewhere, but for which there was no definition for that variable in any Kconfig file. for example, if there exists a line: #if defined(CONFIG_RDAY) then one should expect some Kconfig file to contain the definition: config RDAY ... blah blah ... sadly, that doesn't work so well with u-boot given the plethora of CONFIG_* variables that are simply hard-coded in header files, rather than being defined in any Kconfig file. still, there seems to be a ton of that stuff; for example: $ grep -r CONFIG_I2CFAST * common/board_r.c:#if defined(CONFIG_I2CFAST) common/board_r.c:#endif /* CONFIG_I2CFAST */ README: CONFIG_I2CFAST (PPC405GP|PPC405EP only) scripts/config_whitelist.txt:CONFIG_I2CFAST $ so there we have a CONFIG variable that is clearly being tested, but does not seem to be defined *anywhere*, even hard-coded in a header file. however, since it exists, it ends up in the whitelist file. another short example: $ grep -r MTD_UBI_BLOCK * drivers/mtd/ubi/ubi.h:#ifdef CONFIG_MTD_UBI_BLOCK include/ubi_uboot.h:#undef CONFIG_MTD_UBI_BLOCK scripts/config_whitelist.txt:CONFIG_MTD_UBI_BLOCK $ anyway, there's plenty of that sort of thing scattered through the code base. rday -- ======== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] scripts to sanity-check the Kconfig files
On Wed, 4 Jan 2017, Michal Simek wrote: ... snip ... > > so it would appear that the *correct* spelling is "CONFIG_MX_CYCLIC" > > as defined in the header file, which is what is being tested in the > > source file cmd/mem.c. > > I looked at this. Correct name should be CONFIG_CMD_MX_CYCLIC and for > the rest s/CONFIG_MX_CYCLIC/CONFIG_CMD_MX_CYCLIC/g with move to defconfig. > + in Kconfig there should be dependecy on CMD_MEMORY. whoever is responsible for that code/feature/whatever is welcome to submit a patch for it; i wasn't offering to fix all this stuff. :-) rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] scripts to sanity-check the Kconfig files
On Wed, 4 Jan 2017, Michal Simek wrote: > I looked at this. Correct name should be CONFIG_CMD_MX_CYCLIC and > for the rest s/CONFIG_MX_CYCLIC/CONFIG_CMD_MX_CYCLIC/g with move to > defconfig. > + in Kconfig there should be dependecy on CMD_MEMORY. for better or worse, i ran that cleanup script and posted the output here: http://www.crashcourse.ca/wiki/index.php/U-Boot_Kconfig_cleanup that list is *allegedly* variables that are defined in some Kconfig file, but are never tested anywhere in the code. the output isn't perfect, there are a bunch of false positives since what i consider a variable being "tested" is if, somewhere in the code base, there is a RE of the form: "if.*" that script worked pretty well on kernel code, but doesn't take into account testing in the u-boot source involving "$(SPL_)" variants or testing with "CONFIG_IS_ENABLED", or config variables whose only purpose in life is to further "select" other variables. in any case, the output isn't that lengthy, feel free to look through it to see if anything looks familiar. i've got a couple other scripts i'm going to run on the code base shortly. rday p.s. that output allegedly represents variables that are defined in a Kconfig file but are never tested, which is typically not considered that big a deal -- that normally happens when one removes a feature but forgets to remove the Kconfig variable corresponding to it. i have a second script that identified the opposite -- Kconfig variables that *are* being tested but do not seem to be defined in any Kconfig file, normally a more serious issue. -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] scripts to sanity-check the Kconfig files
while i'm in a chatty mood, a few years back, i wrote some simple shell scripts that scanned the linux kernel source tree for inconsistencies in the Kconfig files, and pointed out things like "config" entries that were never used or tested, "select" directives that referred to non-existent variables, and so on. i just ran that first script on the current u-boot source, and there are quite a number of these. as just partial output, here are some Kconfig variables that are (apparently, as long as i didn't screw up anything in the script) defined but never used or tested anywhere: ... snip ... >>>>> CMD_MX_CYCLIC cmd/Kconfig:338:config CMD_MX_CYCLIC >>>>> CPU_SPECIFIC_OPTIONS arch/x86/cpu/ivybridge/Kconfig:23:config CPU_SPECIFIC_OPTIONS arch/x86/cpu/broadwell/Kconfig:21:config CPU_SPECIFIC_OPTIONS >>>>> DEBUG_EFI_CONSOLE drivers/serial/Kconfig:115:config DEBUG_EFI_CONSOLE >>>>> DM_MOD_EXP drivers/crypto/rsa_mod_exp/Kconfig:1:config DM_MOD_EXP ... snip ... so as to that first example, that shows that the variable CMD_MX_CYCLIC is defined in cmd/Kconfig: config CMD_MX_CYCLIC bool "mdc, mwc" help mdc - memory display cyclic mwc - memory write cyclic but is never tested for anything, and a grep seems to show that: $ grep -r CMD_MX_CYCLIC * cmd/Kconfig:config CMD_MX_CYCLIC configs/sandbox_noblk_defconfig:CONFIG_CMD_MX_CYCLIC=y configs/sandbox_spl_defconfig:CONFIG_CMD_MX_CYCLIC=y configs/sandbox_defconfig:CONFIG_CMD_MX_CYCLIC=y $ OTOH, if you search for just "MX_CYCLIC": $ grep -r MX_CYCLIC *A cmd/Kconfig:config CMD_MX_CYCLIC cmd/mem.c:#ifdef CONFIG_MX_CYCLIC cmd/mem.c:#endif /* CONFIG_MX_CYCLIC */ cmd/mem.c:#ifdef CONFIG_MX_CYCLIC cmd/mem.c:#endif /* CONFIG_MX_CYCLIC */ configs/sandbox_noblk_defconfig:CONFIG_CMD_MX_CYCLIC=y configs/sandbox_spl_defconfig:CONFIG_CMD_MX_CYCLIC=y configs/sandbox_defconfig:CONFIG_CMD_MX_CYCLIC=y include/configs/ea20.h:#define CONFIG_MX_CYCLIC include/configs/lwmon5.h:#define CONFIG_MX_CYCLIC1 /* enable mdc/mwc commands */ include/configs/M5249EVB.h:#define CONFIG_MX_CYCLIC 1 /* enable mdc/mwc commands */ include/configs/PMC405DE.h:#define CONFIG_MX_CYCLIC 1 /* enable mdc/mwc commands */ include/configs/x600.h:#define CONFIG_MX_CYCLIC /* enable mdc/mwc commands */ include/configs/ipam390.h:#define CONFIG_MX_CYCLIC include/configs/da850evm.h:#define CONFIG_MX_CYCLIC include/configs/bcm23550_w1d.h:#define CONFIG_MX_CYCLIC include/configs/bcm28155_ap.h:#define CONFIG_MX_CYCLIC include/configs/omapl138_lcdk.h:#define CONFIG_MX_CYCLIC include/configs/bcm_ep_board.h:#define CONFIG_MX_CYCLIC include/configs/amcore.h:#define CONFIG_MX_CYCLIC 1 /* enable mdc/mwc commands*/ include/configs/digsy_mtc.h:#define CONFIG_MX_CYCLIC1 include/configs/amcc-common.h:#define CONFIG_MX_CYCLIC /* enable mdc/mwc commands */ include/configs/xtfpga.h:#define CONFIG_MX_CYCLIC include/configs/xilinx-ppc.h:#define CONFIG_MX_CYCLIC /* enable mdc/mwc commands */ include/configs/ti_armv7_keystone2.h:#define CONFIG_MX_CYCLIC include/configs/PMC440.h:#define CONFIG_MX_CYCLIC 1 /* enable mdc/mwc commands */ include/configs/calimain.h:#define CONFIG_MX_CYCLIC include/configs/legoev3.h:#define CONFIG_MX_CYCLIC README:- CONFIG_MX_CYCLIC scripts/config_whitelist.txt:CONFIG_MX_CYCLIC $ so it would appear that the *correct* spelling is "CONFIG_MX_CYCLIC" as defined in the header file, which is what is being tested in the source file cmd/mem.c. a more obvious example: $ grep -r DM_MOD_EXP * drivers/crypto/rsa_mod_exp/Kconfig:config DM_MOD_EXP $ there is, however, "UCLASS_MOD_EXP"; perhaps that's what was meant: $ grep -r UCLASS_MOD_EXP * board/freescale/common/fsl_validate.c: ret = uclass_get_device(UCLASS_MOD_EXP, 0, _exp_dev); drivers/crypto/fsl/fsl_rsa.c: .id = UCLASS_MOD_EXP, drivers/crypto/rsa_mod_exp/mod_exp_sw.c:.id = UCLASS_MOD_EXP, drivers/crypto/rsa_mod_exp/mod_exp_uclass.c:.id = UCLASS_MOD_EXP, include/dm/uclass-id.h: UCLASS_MOD_EXP, /* RSA Mod Exp device */ lib/rsa/rsa-verify.c: ret = uclass_get_device(UCLASS_MOD_EXP, 0, _exp_dev); $ there appears to be quite a lot of stuff like this. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] a couple questions about "CONFIG_*" variables and the whitelist
more random questions about stuff ... i see in the top-level README the explanation: "There are two classes of configuration variables: * Configuration _OPTIONS_: These are selectable by the user and have names beginning with "CONFIG_". * Configuration _SETTINGS_: These depend on the hardware etc. and should not be meddled with if you don't know what you're doing; they have names beginning with "CONFIG_SYS_". so, perhaps put another way, regular CONFIG_ variables represent things that a user has the right to configure to affect the end result, while CONFIG_SYS_ variables represent values tied somehow to the underlying hardware that u-boot *needs* to know to function properly on that hardware? is that a remotely accurate description? but that's not a really hard-and-fast rule, is it? as one example from cmd/Kconfig: config SYS_PROMPT string "Shell prompt" default "=> " help This string is displayed in the command line to the left of the cursor. obviously, the user has the right to set the prompt to whatever he or she wants, and i'm sure there are other examples. so the distinction between those two classes of config variables is not as sharp as the README suggests, is it? or am i misreading the explanation? second question -- i'm pretty sure the standard policy is that *any* config variables that start with "CONFIG_" are supposed to be defined somewhere in a Kconfig file, correct? given the history of u-boot, this clearly isn't true, but in a perfect world, it would be, yes? so that if one wanted to define some local macro names in a header file or something, it should never start with the prefix "CONFIG_" unless it comes from the Kbuild structure. at least that's the standard i remember from the linux kernel. now the whitelist -- i'd never looked at it before, read the first part of scripts/build-whitelist.sh, so apparently, the whitelist represents all of the "CONFIG_"-prefixed variables found scattered throughout the code base, or constructed via CONFIG_SYS_EXTRA_OPTIONS. and i can see there are over 8,000 of them. yeesh. however, given that CONFIG_SYS_EXTRA_OPTIONS is deprecated, and if one follows the rule i mentioned earlier (that CONFIG_ prefixed variables should always be defined in a Kconfig file), in a perfect world, that whitelist would be empty, would it not? and, finally, i'm currently digging through the mtdparts code, and noticed that "CONFIG_MTDPARTS" is in the whitelist file, but there is no Kbuild entry "config MTDPARTS", so i did a quick grep to see: $ grep -r CONFIG_MTDPARTS * include/configs/sheevaplug.h:#define CONFIG_MTDPARTS\ include/configs/sheevaplug.h: "=ttyS0,115200 mtdparts="CONFIG_MTDPARTS \ include/configs/sheevaplug.h: "mtdparts="CONFIG_MTDPARTS include/configs/iconnect.h:#define CONFIG_MTDPARTS \ include/configs/iconnect.h: "mtdparts="CONFIG_MTDPARTS \ include/configs/guruplug.h:#define CONFIG_MTDPARTS \ include/configs/guruplug.h: "mtdparts="CONFIG_MTDPARTS \ include/configs/guruplug.h: "mtdparts="CONFIG_MTDPARTS include/configs/nsa310s.h:#define CONFIG_MTDPARTS \ include/configs/nsa310s.h: "mtdparts="CONFIG_MTDPARTS \ include/configs/ib62x0.h:#define CONFIG_MTDPARTS \ include/configs/ib62x0.h: "mtdparts="CONFIG_MTDPARTS \ include/configs/dockstar.h:#define CONFIG_MTDPARTS "mtdparts=orion_nand:1m(uboot),-(root)\0" include/configs/dockstar.h: "mtdparts="CONFIG_MTDPARTS \ include/configs/goflexhome.h:#define CONFIG_MTDPARTS \ include/configs/goflexhome.h: "mtdparts="CONFIG_MTDPARTS \ scripts/config_whitelist.txt:CONFIG_MTDPARTS $ the above suggests that CONFIG_MTDPARTS is an entirely local variable in a small number of header files, whose scope is never seen outside each of those header files. in that case, it would seem inappropriate to have used that name for that variable, since it gives the impression of being part of the Kbuild structure. i'm not suggesting changing any of that (or maybe i am :-), it just seems silly that using that name causes that variable to end up in the whitelist file for no obvious reason. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] are DM/SPL dependencies in drivers/core/Kconfig correct?
quite prepared to be told i'm totally off-base here, but the DM/SPL dependencies in the drivers/core/Kconfig file seem a bit odd, but that might be just my misunderstanding of how DM and SPL work together. first quick observation -- based on the naming convention i read somewhere, it seems that the Kbuild variable "SPL_DM" should actually be "DM_SPL". i'm sure i remember reading that the naming standard for DM-related variables should be "CONFIG_DM_*" but that's not a big deal. onward ... using a wandboard configuration, and enabling SPL, then driver model *and* driver model for SPL, one sees (partial list only) the Kbuild entries: [*] Enable Driver Model [*] Enable Driver Model for SPL [*] Support numbered aliases in device tree [ ] Support numbered aliases in device tree in SPL [*] Support register maps [*] Support register maps in SPL [*] Support system controllers [*] Support system controllers in SPL [*] Support simple-bus driver [ ] Support simple-bus driver in SPL [*] Translate addresses using fdt_translate_address [ ] Translate addresses using fdt_translate_address in SPL where the list above represents pairs of settings, one non-SPL, one for SPL. so far, so good. but if one then deselects "Enable Driver Model for SPL", one is still left with some of those (ostensibly) SPL-related entries: [ ] Support numbered aliases in device tree in SPL [*] Support register maps in SPL [*] Support system controllers in SPL a quick look at the Kconfig file shows that some of those "for SPL" entries depend on SPL_DM, while the others depend only on DM. is that the way it's meant to be? i don't know enough about how the driver model relates to SPL, so it's entirely possible the above is entirely correct, it just looks a bit weird. in any event, that Kconfig file could still be refactored to avoid new entries popping up in arbitrary places depending on what you select or deselect. thoughts? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] question about boot timing -- should it all depend on BOOTSTAGE?
looking at another Kconfig file -- common/Kconfig -- and i find it curious that there are a couple BOOTSTAGE config options that don't depend on BOOTSTAGE: config BOOTSTAGE_USER_COUNT hex "Number of boot ID numbers available for user use" default 20 help This is the number of available user bootstage records. Each time you call bootstage_mark(BOOTSTAGE_ID_ALLOC, ...) a new ID will be allocated from this stash. If you exceed the limit, recording will stop. ... snip ... config BOOTSTAGE_STASH_ADDR hex "Address to stash boot timing information" default 0 help Provide an address which will not be overwritten by the OS when it starts, so that it can read this information when ready. config BOOTSTAGE_STASH_SIZE hex "Size of boot timing stash region" default 4096 help This should be large enough to hold the bootstage stash. A value of 4096 (4KiB) is normally plenty. endmenu do those Kbuild options really not need BOOTSTAGE to be selected first? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Kconfig: Refactoring of top-level Kconfig file
Some refactoring of the top-level Kconfig file which includes: * using "if" to remove numerous identical dependency tests * reordering config entries to group related ones * spelling and grammar fixes There should be no functional changes, only aesthetic ones. Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca> --- AFAICT, there should be no functional difference, but i'm willing to be corrected. diff --git a/Kconfig b/Kconfig index a44ac91..93c0ec7 100644 --- a/Kconfig +++ b/Kconfig @@ -126,7 +126,7 @@ config TOOLS_DEBUG it is possible to set breakpoints on particular lines, single-step debug through the source code, etc. -endif +endif # EXPERT config PHYS_64BIT bool "64bit physical address support" @@ -142,35 +142,26 @@ menu "Boot images" config FIT bool "Support Flattened Image Tree" help - This option allows to boot the new uImage structrure, + This option allows you to boot the new uImage structure, Flattened Image Tree. FIT is formally a FDT, which can include images of various types (kernel, FDT blob, ramdisk, etc.) in a single blob. To boot this new uImage structure, pass the address of the blob to the "bootm" command. FIT is very flexible, supporting compression, multiple images, multiple configurations, verification through hashing and also - verified boot (secure boot using RSA). This option enables that - feature. + verified boot (secure boot using RSA). -config SPL_FIT - bool "Support Flattened Image Tree within SPL" - depends on FIT - depends on SPL - -config FIT_VERBOSE - bool "Display verbose messages on FIT boot" - depends on FIT +if FIT config FIT_SIGNATURE bool "Enable signature verification of FIT uImages" - depends on FIT depends on DM select RSA help This option enables signature verification of FIT uImages, using a hash signed and verified using RSA. If CONFIG_SHA_PROG_HW_ACCEL is defined, i.e support for progressive - hashing is available using hardware, then then RSA library will use + hashing is available using hardware, then the RSA library will use it. See doc/uImage.FIT/signature.txt for more details. WARNING: When relying on signed FIT images with a required signature @@ -179,15 +170,16 @@ config FIT_SIGNATURE format support in this case, enable it using CONFIG_IMAGE_FORMAT_LEGACY. -config SPL_FIT_SIGNATURE - bool "Enable signature verification of FIT firmware within SPL" - depends on SPL_FIT - depends on SPL_DM - select SPL_RSA +config FIT_VERBOSE + bool "Show verbose messages when FIT images fail" + help + Generally a system will have valid FIT images so debug messages + are a waste of code space. If you are debugging your images then + you can enable this option to get more verbose information about + failures. config FIT_BEST_MATCH bool "Select the best match for the kernel device tree" - depends on FIT help When no configuration is explicitly selected, default to the one whose fdt's compatibility field best matches that of @@ -195,14 +187,55 @@ config FIT_BEST_MATCH most specific compatibility entry of U-Boot's fdt's root node. The order of entries in the configuration's fdt is ignored. -config FIT_VERBOSE - bool "Show verbose messages when FIT images fails" - depends on FIT +config FIT_IMAGE_POST_PROCESS + bool "Enable post-processing of FIT artifacts after loading by U-Boot" + depends on TI_SECURE_DEVICE help - Generally a system will have valid FIT images so debug messages - are a waste of code space. If you are debugging your images then - you can enable this option to get more verbose information about - failures. + Allows doing any sort of manipulation to blobs after they got extracted + from FIT images like stripping off headers or modifying the size of the + blob, verification, authentication, decryption etc. in a platform or + board specific way. In order to use this feature a platform or board- + specific implementation of board_fit_image_post_process() must be + provided. Also, anything done during this post-processing step would + need to be comprehended in how the images were prepared before being + injected into the FIT creation (i.e. the blobs would have been pre- + processed before being added to the FIT image). + +config SPL_FIT + bool "Support Flattened Image Tree within SPL" + depends on SPL + +config SPL_FIT_SIG
[U-Boot] why two "config FIT_VERBOSE" lines in top-level Kconfig?
weird ... config FIT_VERBOSE bool "Display verbose messages on FIT boot" depends on FIT ... jump to a bit lower down ... config FIT_VERBOSE bool "Show verbose messages when FIT images fails" depends on FIT help Generally a system will have valid FIT images so debug messages are a waste of code space. If you are debugging your images then you can enable this option to get more verbose information about failures. this is really a lead-in to a larger question -- any objection to refactoring some of the Kconfig files that have numerous identical dependency lines which could be replaced by a simpler "if" test? that top-level Kconfig file is a candidate, given the number of "depends on FIT" lines that could be removed and surrounded by: if FIT ... endif and some Kconfig files have entries in a weird order such that, if you select a feature, dependent features suddenly pop up somewhere else in the display, a bit disconcerting. anyway, i'll post a refactored top-level Kconfig, so people can see what i'm talking about. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] some questions about u-boot's driver model
i'm currently trying to wrap my head around the aspects of converting the various u-boot subsystems to use the driver model, and i'll do this in a number of posts so as to not have one monstrously large post, and i'm sure i will have some truly dumb questions, so apologies beforehand for those. i'm working off this page as a starting point: http://www.denx.de/wiki/U-Boot/DriverModel and pawing through the code base to try to understand the big picture, so first question. i can see that general driver model support is defined in drivers/core/Kconfig: menu "Generic Driver Options" config DM bool "Enable Driver Model" help This config option enables Driver Model. This brings in the core support, including scanning of platform data on start-up. If CONFIG_OF_CONTROL is enabled, the device tree will be scanned also when available. (side note about that file: seems like a lot of Kbuild entries in that file contain the line "depends on DM", when it looks like one could just wrap a large part of that file in a single "if DM" testi to simplify things. but ... onward.) i initially thought driver model support was included by one having to specifically select that option, until i saw all the "select DM" Kbuild lines scattered throughout the code base that explicitly selected that option based on architecture or target board. for instance, here's some snippets from arch/Kconfig (irrelevant lines removed): config NIOS2 bool "Nios II architecture" select SUPPORT_OF_CONTROL select OF_CONTROL select DM select CPU config SANDBOX bool "Sandbox" select SUPPORT_OF_CONTROL select DM select DM_KEYBOARD select DM_SPI_FLASH select DM_SERIAL select DM_I2C select DM_SPI select DM_GPIO select DM_MMC config X86 bool "x86 architecture" select CREATE_ARCH_SYMLINK select HAVE_PRIVATE_LIBGCC select SUPPORT_OF_CONTROL select DM select DM_KEYBOARD select DM_SERIAL select DM_GPIO select DM_SPI select DM_SPI_FLASH so i can see that a variety of driver model support is selected either at the architecture level, in some cases including driver model support for particular subsystems, or if not at the architecture level: config ARM bool "ARM architecture" select CREATE_ARCH_SYMLINK select HAVE_PRIVATE_LIBGCC if !ARM64 select SUPPORT_OF_CONTROL then possibly at the CPU or board level: arch/arm/Kconfig: config ARCH_MVEBU bool "Marvell MVEBU family (Armada XP/375/38x/3700/7K/8K)" select OF_CONTROL select OF_SEPARATE select DM select DM_ETH select DM_SERIAL select DM_SPI select DM_SPI_FLASH or: arch/arm/mach-litesom/Kconfig: config LITESOM bool select MX6UL select DM select DM_THERMAL select SUPPORT_SPL so what is the general workflow for adding/selecting driver model support? seems like it can be selected/defined at a number of levels: * entire architecture * CPU * target board is there a recipe for how driver model is slowly added to u-boot, based on updating Kconfig files for the above? more questions coming as i keep reading ... rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] any remaining value to "board_flash_wp_on()" routine?
the adventure digging through flash code continues ... i just ran
across this:
$ grep -rw board_flash_wp_on *
board/xes/common/fsl_8xxx_misc.c:int board_flash_wp_on(void)
common/board_r.c:__weak int board_flash_wp_on(void)
common/board_r.c: if (board_flash_wp_on())
$
i can see the general value in a weak routine checking on flash
protection:
__weak int board_flash_wp_on(void)
{
/*
* Most flashes can't be detected when write protection is enabled,
* so provide a way to let U-Boot gracefully ignore write protected
* devices.
*/
return 0;
}
...
static int initr_flash(void)
{
ulong flash_size = 0;
bd_t *bd = gd->bd;
puts("Flash: ");
if (board_flash_wp_on())
printf("Uninitialized - Write Protect On\n");
else
flash_size = flash_init();
but it does seem odd that, in the entire u-boot code base, only one
board takes advantage of that, board/xes/common/fsl_8xxx_misc.c, and
in what appears to be a very restricted way:
#include
#include
#ifdef CONFIG_PCA953X
#include
/*
* Determine if a board's flashes are write protected
*/
int board_flash_wp_on(void)
{
if (pca953x_get_val(CONFIG_SYS_I2C_PCA953X_ADDR0) &
CONFIG_SYS_PCA953X_NVM_WP)
return 1;
return 0;
}
#endif
is there really a need for a feature for which only a single board
overrides that routine? or is there something else here i'm
overlooking?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] any ongoing value to "CONFIG_SYS_FLASH_CHECKSUM" config variable?
still going through common/board_r.c, and ran across the above CONFIG
variable, but it seems to have very little use these days. as you can
see from a recursive grep:
$ grep -r SYS_FLASH_CHECKSUM *
it shows up in board_r.c:
common/board_r.c:#ifdef CONFIG_SYS_FLASH_CHECKSUM
common/board_r.c:#endif /* CONFIG_SYS_FLASH_CHECKSUM */
then some under include/configs wherein only a small number of config
header files #define it (all the rest #undef it):
include/configs/P1010RDB.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/M5249EVB.h:#define CONFIG_SYS_FLASH_CHECKSUM <--
include/configs/MPC8315ERDB.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/socrates.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/yucca.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/mpc5121ads.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8323ERDB.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/M52277EVB.h:# define CONFIG_SYS_FLASH_CHECKSUM <--
include/configs/MPC8544DS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/bamboo.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8536DS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/vme8349.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/ac14xx.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8641HPCN.h:#undefCONFIG_SYS_FLASH_CHECKSUM
include/configs/katmai.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/M54418TWR.h:#define CONFIG_SYS_FLASH_CHECKSUM <--
include/configs/MPC837XEMDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/p1_twr.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/p1_p2_rdb_pc.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC832XEMDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/UCP1020.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8610HPCD.h:#undefCONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8548CDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/M5282EVB.h:#define CONFIG_SYS_FLASH_CHECKSUM <--
include/configs/M54455EVB.h:# define CONFIG_SYS_FLASH_CHECKSUM <--
include/configs/redwood.h:#undefCONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC837XERDB.h:#undefCONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8568MDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8540ADS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/sbc8548.h:#undefCONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8349EMDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/M54451EVB.h:# define CONFIG_SYS_FLASH_CHECKSUM <--
include/configs/MPC8541CDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/TQM834x.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/sbc8641d.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8572DS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/BSC9132QDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8569MDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/sbc8349.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/mecp5123.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8560ADS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/aria.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8555CDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
scripts/config_whitelist.txt:CONFIG_SYS_FLASH_CHECKSUM
and in:
scripts/config_whitelist.txt:CONFIG_SYS_FLASH_CHECKSUM
and that's it. the code in board_r.c is:
#ifdef CONFIG_SYS_FLASH_CHECKSUM
/*
* Compute and print flash CRC if flashchecksum is set to 'y'
*
* NOTE: Maybe we should add some WATCHDOG_RESET()? XXX
*/
if (getenv_yesno("flashchecksum") == 1) {
printf(" CRC: %08X", crc32(0,
(const unsigned char *) CONFIG_SYS_FLASH_BASE,
flash_size));
}
#endif /* CONFIG_SYS_FLASH_CHECKSUM */
wherein, even if that variable is set, a further test is made of the
environment variable "flashchecksum."
is there still value to this CONFIG variable given that only a
half-dozen boards define it? am i overlooking something obvious?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] any value to "#if defined(CONFIG_OXC) || defined(CONFIG_RMU)" test in board_r.c?
still pawing through the flash support code in u-boot for my personal edification, and ran across this snippet in common/board_r.c: #if defined(CONFIG_OXC) || defined(CONFIG_RMU) /* flash mapped at end of memory map */ bd->bi_flashoffset = CONFIG_SYS_TEXT_BASE + flash_size; #elif CONFIG_SYS_MONITOR_BASE == CONFIG_SYS_FLASH_BASE bd->bi_flashoffset = monitor_flash_len; /* reserved area for monitor */ #endif in that first test, the "defined(CONFIG_OXC)" part seems dead as the OXC board was scrapped some time ago: OXC powerpc MPC8240309a292 2011-12-07 and i'm not sure anything needs that second test either, does it? can that entire first preprocessor test be deleted? or am i missing something? rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] doc/README.cfi: Update code snippet, and add example.
First, update the code snippet referenced in the README file. And
since there are only two boards that override flash_cmd_reset(),
might as well show them both.
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
figured since i was there, and there were only two boards in the
entire code base that defined their own flash_cmd_reset(), might as
well show them both. anything else worth adding to this README?
or is there any code simplification that could be done to remove
even these exceptional cases?
diff --git a/doc/README.cfi b/doc/README.cfi
index 81e7cf1..ad52850 100644
--- a/doc/README.cfi
+++ b/doc/README.cfi
@@ -1,7 +1,7 @@
The common CFI driver provides this weak default implementation for
flash_cmd_reset():
-void __flash_cmd_reset(flash_info_t *info)
+static void __flash_cmd_reset(flash_info_t *info)
{
/*
* We do not yet know what kind of commandset to use, so we issue
@@ -9,22 +9,43 @@ void __flash_cmd_reset(flash_info_t *info)
* that AMD flash roms ignore the Intel command.
*/
flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
+ udelay(1);
flash_write_cmd(info, 0, 0, FLASH_CMD_RESET);
}
void flash_cmd_reset(flash_info_t *info)
__attribute__((weak,alias("__flash_cmd_reset")));
+Some flash chips seem to have trouble with this reset sequence.
+In this case, board-specific code can override this weak default
+version with a board-specific function.
-Some flash chips seems to have trouble with this reset sequence. In this case
-the board specific code can override this weak default version with a board
-specific function. For example the digsy_mtc board equipped with the M29W128GH
-from Numonyx needs this version to function properly:
+At the time of writing, there are two boards that define their own
+routine for this.
+
+First, the digsy_mtc board equipped with the M29W128GH from Numonyx
+needs this version to function properly:
void flash_cmd_reset(flash_info_t *info)
{
flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
}
+In addition, the t3corp board defines the routine thusly:
+
+void flash_cmd_reset(flash_info_t *info)
+{
+ /*
+* FLASH at address CONFIG_SYS_FLASH_BASE is a Spansion chip and
+* needs the Spansion type reset commands. The other flash chip
+* is located behind a FPGA (Xilinx DS617) and needs the Intel type
+* reset command.
+*/
+ if (info->start[0] == CONFIG_SYS_FLASH_BASE)
+ flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
+ else
+ flash_write_cmd(info, 0, 0, FLASH_CMD_RESET);
+}
+
see also:
http://www.mail-archive.com/u-boot@lists.denx.de/msg24368.html
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] digsy_mtc.c: Minor spelling/grammar fixes.
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca> --- diff --git a/board/intercontrol/digsy_mtc/digsy_mtc.c b/board/intercontrol/digsy_mtc/digsy_mtc.c index 37eb6c7..05d673d 100644 --- a/board/intercontrol/digsy_mtc/digsy_mtc.c +++ b/board/intercontrol/digsy_mtc/digsy_mtc.c @@ -41,7 +41,7 @@ extern int usb_cpu_init(void); #if defined(CONFIG_DIGSY_REV5) /* - * The M29W128GH needs a specail reset command function, + * The M29W128GH needs a special reset command function, * details see the doc/README.cfi file */ void flash_cmd_reset(flash_info_t *info) @@ -76,7 +76,7 @@ static void sdram_start(int hi_addr) /* * ATTENTION: Although partially referenced initdram does NOT make real use *use of CONFIG_SYS_SDRAM_BASE. The code does not work if - *CONFIG_SYS_SDRAM_BASE is something else than 0x. + *CONFIG_SYS_SDRAM_BASE is something other than 0x. */ phys_size_t initdram(int board_type) -- ==== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] doc/README.cfi: Update code snippet for flash_cmd_reset()
Minor update in code snippet in the doc file to match source.
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
diff --git a/doc/README.cfi b/doc/README.cfi
index 81e7cf1..6b8be41 100644
--- a/doc/README.cfi
+++ b/doc/README.cfi
@@ -1,7 +1,7 @@
The common CFI driver provides this weak default implementation for
flash_cmd_reset():
-void __flash_cmd_reset(flash_info_t *info)
+static void __flash_cmd_reset(flash_info_t *info)
{
/*
* We do not yet know what kind of commandset to use, so we issue
@@ -9,12 +9,12 @@ void __flash_cmd_reset(flash_info_t *info)
* that AMD flash roms ignore the Intel command.
*/
flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
+ udelay(1);
flash_write_cmd(info, 0, 0, FLASH_CMD_RESET);
}
void flash_cmd_reset(flash_info_t *info)
__attribute__((weak,alias("__flash_cmd_reset")));
-
Some flash chips seems to have trouble with this reset sequence. In this case
the board specific code can override this weak default version with a board
specific function. For example the digsy_mtc board equipped with the M29W128GH
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] curious snippet in drivers/mtd/dataflash.c
not sure about this bit of code in that source file:
/* Set the environment according to the label...*/
if(protected == FLAG_PROTECT_INVALID) {
dataflash_info[i].Device.area_list[j].protected =
FLAG_PROTECT_INVALID;
} else {
dataflash_info[i].Device.area_list[j].protected =
protected;
}
is that not just setting the value to "protected" in both cases? what
is the point of that conditional?
rday
--
========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] i'm assuming comment "/* board/?/flash.c */" in flash.h is way obsolete
digging around in CONFIG_SYS_FLASH_PROTECTION, and i see this snippet in include/flash.h: /* board/?/flash.c */ #if defined(CONFIG_SYS_FLASH_PROTECTION) extern int flash_real_protect(flash_info_t *info, long sector, int prot); extern void flash_read_user_serial(flash_info_t * info, void * buffer, int offset, int len); extern void flash_read_factory_serial(flash_info_t * info, void * buffer, int offset, int len); #endif /* CONFIG_SYS_FLASH_PROTECTION */ i'm assuming that opening comment is long-since obsolete, yes? i can submit a patch to trash it, but since i'm poring over that file, i can collect any other tweaks anyone else wants to suggest to make it worth it. any other content in that file that needs updating or removal? no rush. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] *preferred* place in u-boot to tweak device tree?
a while back, i asked about the best way to have u-boot extract the
MAC address from a well-known address in flash, and add it to the
device tree to pass to the kernel; discussion was here:
http://lists.denx.de/pipermail/u-boot/2016-May/255856.html
i notice that another option for tweaking the MAC address that is
popular is to add that code to a board's misc_init_r(). so both ways
work just fine, but i'm assuming that the *proper* place to do it is
in ft_board_setup(), since the routine image_setup_libfdt() pretty
much handles everything, and all that's left to do is extend
ft_board_setup() to set the env variable:
eth_setenv_enetaddr("ethaddr", );
is that what you'd call "best practice"?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] inconsistent use of semi-colons when invoking macros
just noticed this in lib/bzip2/bzlib_decompress.c (around line 240):
... snip ...
switch (s->state) {
GET_UCHAR(BZ_X_MAGIC_1, uc);
if (uc != BZ_HDR_B) RETURN(BZ_DATA_ERROR_MAGIC);
GET_UCHAR(BZ_X_MAGIC_2, uc);
if (uc != BZ_HDR_Z) RETURN(BZ_DATA_ERROR_MAGIC);
GET_UCHAR(BZ_X_MAGIC_3, uc) <---
if (uc != BZ_HDR_h) RETURN(BZ_DATA_ERROR_MAGIC);
GET_BITS(BZ_X_MAGIC_4, s->blockSize100k, 8) <---
... snip ...
note the lack of terminating semi-colon on a couple of those macro
invocations. now, given those macro definitions in the same file:
#define GET_BITS(lll,vvv,nnn) \
case lll: s->state = lll; \
while (True) { \
if (s->bsLive >= nnn) { \
UInt32 v;\
v = (s->bsBuff >>\
(s->bsLive-nnn)) & ((1 << nnn)-1); \
s->bsLive -= nnn;\
vvv = v; \
break; \
} \
if (s->strm->avail_in == 0) RETURN(BZ_OK); \
s->bsBuff \
= (s->bsBuff << 8) | \
((UInt32) \
(*((UChar*)(s->strm->next_in; \
s->bsLive += 8; \
s->strm->next_in++; \
s->strm->avail_in--;\
s->strm->total_in_lo32++; \
if (s->strm->total_in_lo32 == 0)\
s->strm->total_in_hi32++;\
}
#define GET_UCHAR(lll,uuu)\
GET_BITS(lll,uuu,8)
it turns out those semi-colons are unnecessary but, still, it would be
stylistically nice to be consistent. is there a coding standard in
cases where a macro invocation doesn't need a terminating semi-colon?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] is there any issue with creating and using more than one hashtable?
On Sat, 1 Oct 2016, Wolfgang Denk wrote:
... snip ...
> Actually the TFTP will not access the environment directly to
> determine the boot parameters like bootfile, ipaddr, gatewayip,
> netmask, serverip, etc.; instead, it uses internal variables. So
> your environment settings for "ipaddr" and "gatewayip" may contain
> totally different values than the variables net_ip resp.
> net_gateway which get used by the TFTP code.
>
> These variables get set through the U_BOOT_ENV_CALLBACK functionality,
> i. e. as a callback whenever the corresponfing variable gets set.
> "setting" here means that the value in the hash table gets changed -
> see function _compare_and_overwrite_entry() in "hashtable.c":
>
> 244 /* If there is a callback, call it */
> 245 if (htab->table[idx].entry.callback &&
> 246 htab->table[idx].entry.callback(item.key,
> 247 item.data, env_op_overwrite, flag)) {
> 248 debug("callback() rejected setting
> variable "
> 249 "%s, skipping it!\n", item.key);
> 250 __set_errno(EINVAL);
> 251 *retval = NULL;
> 252 return 0;
> 253 }
... snip ...
i'm going to assume other net-related commands have this behaviour
as well, yes? like ping? which would explain why ping'ing even the
alleged gateway didn't work in this context.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] is there any issue with creating and using more than one hashtable?
On Sat, 1 Oct 2016, Wolfgang Denk wrote:
> Dear Robert,
>
> In message <alpine.LFD.2.20.1610010456050.5186@localhost.localdomain> you
> wrote:
> >
> > > 244 /* If there is a callback, call it */
> > > 245 if (htab->table[idx].entry.callback &&
> > > 246 htab->table[idx].entry.callback(item.key,
> ...
>
> > just to follow up, the simple solution for me would be to *not*
> > create that second hashtable with recognized u-boot variable names
> > like "ipaddr", "gatewayip", "serverip" unless i absolutely plan on
> > using those new values.
>
> Well, I guess you don't need the callback funtionality for your
> purposes, and you will probably not pull the data from the second
> hash table back into the primary one, so why can you not just clear
> the "callback" for any entries you process?
>
> That would suppress the unwanted actions...
>
> > this is what i use to add/modify a new env variable -- is this the
> > correct approach, to add it to the "env_htab" hashtable?
> >
> > int
> > add_entry_to_env(ENTRY* e)
> > {
> > ENTRY* ep;
> >
> > printf("Adding stuff k: [%s], d: [%s] to env.\n", e->key, e->data);
>
> Insert:
>
> e->callback = NULL;
>
> here?
that would be one solution, yes. i assume i would, of course, set
that callback before adding the entry to the hashtable; otherwise,
wouldn't do much good.
ok, i think we've settled this, thanks.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] is there any issue with creating and using more than one hashtable?
On Sat, 1 Oct 2016, Wolfgang Denk wrote:
> Dear Robert,
... snip ...
> Actually the TFTP will not access the environment directly to
> determine the boot parameters like bootfile, ipaddr, gatewayip,
> netmask, serverip, etc.; instead, it uses internal variables. So
> your environment settings for "ipaddr" and "gatewayip" may contain
> totally different values than the variables net_ip resp.
> net_gateway which get used by the TFTP code.
>
> These variables get set through the U_BOOT_ENV_CALLBACK functionality,
> i. e. as a callback whenever the corresponfing variable gets set.
> "setting" here means that the value in the hash table gets changed -
> see function _compare_and_overwrite_entry() in "hashtable.c":
>
> 244 /* If there is a callback, call it */
> 245 if (htab->table[idx].entry.callback &&
> 246 htab->table[idx].entry.callback(item.key,
> 247 item.data, env_op_overwrite, flag)) {
> 248 debug("callback() rejected setting
> variable "
> 249 "%s, skipping it!\n", item.key);
> 250 __set_errno(EINVAL);
> 251 *retval = NULL;
> 252 return 0;
> 253 }
>
>
> So when you insert variable sof these registered names into your
> alternative hash table using the common code, then the respective
> callbacks will fire in the same way as if you had changed the
> environment settings through a setenv command.
just to follow up, the simple solution for me would be to *not*
create that second hashtable with recognized u-boot variable names
like "ipaddr", "gatewayip", "serverip" unless i absolutely plan on
using those new values.
an even simpler solution would be to skip the second hashtable
creation altogether, walk through my first hashtable (which should
have no conflicting variable names), and in one step, translate those
names and add them to the current environment.
this is what i use to add/modify a new env variable -- is this the
correct approach, to add it to the "env_htab" hashtable?
int
add_entry_to_env(ENTRY* e)
{
ENTRY* ep;
printf("Adding stuff k: [%s], d: [%s] to env.\n", e->key, e->data);
hsearch_r(*e, ENTER, , _htab, 0);
return 0;
}
if that's the way to do it, i'll just do away with the second
hashtable and avoid the issue altogether.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] is there any issue with creating and using more than one hashtable?
s get set through the U_BOOT_ENV_CALLBACK
> functionality, i. e. as a callback whenever the corresponding
> variable gets set. "setting" here means that the value in the hash
> table gets changed - see function _compare_and_overwrite_entry() in
> "hashtable.c":
>
> 244 /* If there is a callback, call it */
> 245 if (htab->table[idx].entry.callback &&
> 246 htab->table[idx].entry.callback(item.key,
> 247 item.data, env_op_overwrite, flag)) {
> 248 debug("callback() rejected setting
> variable "
> 249 "%s, skipping it!\n", item.key);
> 250 __set_errno(EINVAL);
> 251 *retval = NULL;
> 252 return 0;
> 253 }
>
>
> So when you insert variables of these registered names into your
> alternative hash table using the common code, then the respective
> callbacks will fire in the same way as if you had changed the
> environment settings through a setenv command.
oh ... crap ... that would appear to be the issue, then.
> It is obvious that the U-Boot design did not anticipate a situation
> where an alternative hash table with different settings would be
> created.
i will admit i didn't see any documentation that told me explicitly
that i *could* have additional hashtables; i just assumed, hey, it's
just another data structure, it has some useful functionality, i'll
just create another couple of them to save me some coding.
i *did* try to verify that there was no shared data; things like
making sure "strdup" was used to avoid sharing things like strings. i
never thought of checking the callback structure.
> A quick but ugly workaround could be to re-set the variables to the
> values stored in the environment by running something like
>
> setenv ipaddr ${ipaddr}
>
> etc.
>
>
> Hope this helps.
massively, thanks. it just means that my attempt at cleverness in
using a couple more hashtables wasn't as clever as i thought.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] is there any issue with creating and using more than one hashtable?
short version: migrating target board from legacy OS to linux and, in a fixed address in flash, there is a legacy "bootline" of the form var=value var=value ... etc etc ... that i want to convert to u-boot compatible values such as ipaddr, gatewayip, serverip and so on. in misc_init_r(), i create a new hashtable to just grab the contents of that bootline as is. i then create a *second* hashtable and selectively move over just those keys i want from the first hashtable, possibly renaming them in the process. in the end, i end up with a small hashtable of u-boot compatible values, which i dump by walking through that second hashtable: Walking populated bootline_htab_2... k: [gatewayip], d: [192.168.1.1] k: [netmask], d: [255.255.255.0] k: [ipaddr], d: [192.168.1.2] now here's the thing ... after all that, i manually check whether the CRC for the env table in persistent storage is valid and, if it is, i do *nothing* with all that hashtable content -- that was all wasted cycles, but it should not do any harm. but it does, because this is what happens: TFTP from server 10.35.5.37; our IP address is 192.168.1.2; sending through gateway 192.168.1.1 the server address is correct, but the IP address and gateway are totally wrong -- they should have been untouched and been completely different values; instead, they now equal the values in that second hashtable, which i chose to do nothing with. is there some weird issue with re-entrancy here? if i print "ipaddr" and "gatewayip", they seem correct. if i "md" the environment in persistent storage, again, they seem correct. and yet, when TFTP kicks in, it seems to pick up the values from that hashtable. thoughts? is there some weird way that values from one hashtable can "bleed" into another one? i'm baffled. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] "CONFIG_*" versus "CONFIG_SYS_*" variables in u-boot?
from README file:
There are two classes of configuration variables:
* Configuration _OPTIONS_:
These are selectable by the user and have names beginning with
"CONFIG_".
* Configuration _SETTINGS_:
These depend on the hardware etc. and should not be meddled with if
you don't know what you're doing; they have names beginning with
"CONFIG_SYS_".
historically, i've always understood (from kernel stuff) that
macros that begin with "CONFIG_" should *always* be user-selectable
through the Kbuild system. so i'm not sure how to interpret a
"CONFIG_SYS_" prefix.
i ask given a couple examples i just ran across. first, this
regarding the macro "CONFIG_MAC_OFFSET":
board/cm5200/cm5200.c: if (i2c_read(CONFIG_SYS_I2C_EEPROM, CONFIG_MAC_OFFSET,
2, buf, 6) == 0) {
board/cm5200/cm5200.c: CONFIG_MAC_OFFSET);
include/configs/cm5200.h:#define CONFIG_MAC_OFFSET 0x35/* MAC address
offset in I2C EEPROM */
to me, that *clearly* should not have used "CONFIG_MAC_OFFSET", but
rather just "MAC_OFFSET."
the second example, though, is not quite as clear:
board/pdm360ng/pdm360ng.c:
CONFIG_SYS_I2C_EEPROM_MAC_OFFSET, 1, buf, 6);
board/pdm360ng/pdm360ng.c:
CONFIG_SYS_I2C_EEPROM_MAC_OFFSET);
include/configs/pdm360ng.h:#define CONFIG_SYS_I2C_EEPROM_MAC_OFFSET 0x10
so even though this second example is also not defined by the Kbuild
system, is it somehow more acceptable because it begins with
"CONFIG_SYS_"? i'm having trouble appreciating the distinction.
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] couple questions on driver model for gpio, and gpio in sandbox
currently crawling through the gpio code in u-boot so, question one,
i see in include/asm-generic/gpio.h, the explicitly listed as
"deprecated" old API routines:
int gpio_request(unsigned gpio, const char *label)
int gpio_free(unsigned gpio)
int gpio_direction_input(unsigned gpio)
int gpio_direction_output(unsigned gpio, int value)
int gpio_get_value(unsigned gpio)
int gpio_set_value(unsigned gpio, int value)
is that it? are those the entirety of the old-style gpio API that are
now deprecated? as in, all else in that header file is relevant for
the newer driver model?
also, i note in that same file enum and flags for the states of a
gpio:
/* State of a GPIO, as reported by get_function() */
enum gpio_func_t {
GPIOF_INPUT = 0,
GPIOF_OUTPUT,
GPIOF_UNUSED, /* Not claimed */
GPIOF_UNKNOWN, /* Not known */
GPIOF_FUNC, /* Not used as a GPIO */
GPIOF_COUNT,
};
struct udevice;
struct gpio_desc {
struct udevice *dev;/* Device, NULL for invalid GPIO */
unsigned long flags;
#define GPIOD_REQUESTED (1 << 0)/* Requested/claimed */
#define GPIOD_IS_OUT(1 << 1)/* GPIO is an output */
#define GPIOD_IS_IN (1 << 2)/* GPIO is an input */
#define GPIOD_ACTIVE_LOW(1 << 3)/* value has active low */
#define GPIOD_IS_OUT_ACTIVE (1 << 4)/* set output active */
uint offset;/* GPIO offset within the device */
/*
* We could consider adding the GPIO label in here. Possibly we could
* use this structure for internal GPIO information.
*/
};
however, i note this in drivers/gpio/sandbox.c:
/* Flags for each GPIO */
#define GPIOF_OUTPUT(1 << 0)/* Currently set as an output */
#define GPIOF_HIGH (1 << 1)/* Currently set high */
#define GPIOF_ODR (1 << 2)/* Currently set to open drain mode */
this looks like sandbox is (re)defining some GPIO-related flags ... is
there some reason it doesn't just use the flag definitions from the
earlier header file? or is that a silly question?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] long-term plans to get rid of include/configs/ directory?
correct me if i'm wrong, but i vaguely recall that the long-term goal is to remove the include/configs/ directory, and move all target-specific content to defconfig files, is that right? in combination with adding all that content to the Kbuild structure, of course. am i understanding that correctly? because that would imply that i really shouldn't add any more content for my particular target boards to include/configs/ if i can help it, yes? just trying to avoid doing anything i'll have to totally refactor later. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] how to programatically add a second hash table to the environment?
i'm hoping this is a simple question -- at boot time, i've added a misc_init_r() routine that digs around in some legacy flash, pulls out a string of (vxworks) "var=val" settings, and imports that in one shot into an initial hash table. works fine. as the second step, i walk that table and, for the vxworks settings i care about, i translate them to u-boot env variable names, possibly massage the data values, and add those values to a *second* hash table that now contains proper keys and values as u-boot would understand them. (for example, vxworks would have "g=gateway", whereas i translate that to "gatewayip=gateway" for the second hash table.) i now want to just add/overwrite the current u-boot environment with what's in that second hash, and as i see it, i could just walk that second hash and, for each ENTRY, do a call to hsearch_r() referring to the hash table "env_htab", yes? i see no single call that allows me to combine hash tables, but it's not as if i will have a lot of values to enter, so is that the right approach -- just a short series of calls of the form: hsearch_r(entry, ENTER, , _htab, 0); seems straightforward enough, just want to confirm i'm not overlooking anything. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended place to add some custom settings to u-boot environment?
On Wed, 14 Sep 2016, Wolfgang Denk wrote: > Dear Robert, > > In message <alpine.lfd.2.20.1609140935240.5...@ca624034.mitel.com> you wrote: > > > > > It will not realy work. "space-separated" is not good enough as a > > > space character is a legal part of the value of an environment > > > variable. You would need to tweak the import code. > > > > but himport_r() explicitly takes a separator character, and i can > > guarantee the strings being "imported" have no embedded space > > characters in their values. so as long as that's the case, shouldn't > > himport_r() properly handle that given a separator of space? > > Well, yes, but it sounds a bit fragile to me. Experience tells me > that very soon someone _will_ use a space in a variable. in this case, no ... it's legacy info that will never, ever change at this point. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended place to add some custom settings to u-boot environment?
On Wed, 14 Sep 2016, Wolfgang Denk wrote: > Dear Robert, > > In message <alpine.lfd.2.20.1609140902380.2...@ca624034.mitel.com> you wrote: > > > > it needs to be done programatically, and i *believe* himport_r() can > > handle it, as the string is space-separated and null-terminated, so > > i'm about to test that. > > It will not realy work. "space-separated" is not good enough as a > space character is a legal part of the value of an environment > variable. You would need to tweak the import code. but himport_r() explicitly takes a separator character, and i can guarantee the strings being "imported" have no embedded space characters in their values. so as long as that's the case, shouldn't himport_r() properly handle that given a separator of space? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] does it make sense to define misc_init_r() not conditional on CONFIG_MISC_INIT_R?
another oddity i noted in my travels ... in common/board_r.c, this:
#ifdef CONFIG_MISC_INIT_R
misc_init_r,/* miscellaneous platform-dependent init */
#endif
suggests that any *definition* of a board's misc_init_r() routine
should be similarly conditional, but there are well over a hundred
counter-examples like, say, this from km83xx.c:
int misc_init_r(void)
{
ivm_read_eeprom(ivm_content, CONFIG_SYS_IVM_EEPROM_MAX_LEN);
return 0;
}
doesn't hurt, of course ... binary just ends up containing a
superfluous misc_init_r() routine that's never called. i suspect
there's a lot of that with other routines as well.
or is there something else going on here more subtle that i don't
understand?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
