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
[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 v
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
Re: [U-Boot] Quickstart-Manual for u-boot?
On Mon, 13 Jan 2014, Fred Fisch wrote: > Hi, > > I already found > > - the sources in GIT > - the config-name of my board > - the (really huge) manual > > Since all I want to do is just compile MLO/u-boot.img for BeagleBone > Black the latter seems to be totally oversized for me. > > So my question: is there some kind of quick-start/cookbook available > that just describes the steps to compile U-Boot for a single > platform? a while back, i wrote a number of wiki pages for boards including the BBB, and here's the basic recipe for u-boot for the BBB: http://www.crashcourse.ca/wiki/index.php/U-Boot_on_the_BBB#Building_a_stock_u-boot_for_the_BBB last time i looked, that recipe worked just fine. 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] Correct single misspelling of "consitant" in source tree.
Signed-off-by: Robert P. J. Day --- diff --git a/include/config_distro_defaults.h b/include/config_distro_defaults.h index 5d18a4b..1ecc0bb 100644 --- a/include/config_distro_defaults.h +++ b/include/config_distro_defaults.h @@ -10,7 +10,7 @@ /* * List of all commands and options that when defined enables support for * features required by distros to support boards in a standardised and - * consitant manner. + * consistent manner. */ #define CONFIG_BOOTP_BOOTPATH -- 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] Correct two non-functional misspellings "overrided".
Signed-off-by: Robert P. J. Day --- given that the typoes occur in Kconfig help and a comment, the changes are effectively non-functional. diff --git a/dts/Kconfig b/dts/Kconfig index 83ba7a6..5fe63f8 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -49,7 +49,7 @@ config DEFAULT_DEVICE_TREE string "Default Device Tree for DT control" help This option specifies the default Device Tree used for DT control. - It can be overrided from the command line: + It can be overridden from the command line: $ make DEVICE_TREE= endmenu diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh index 81b0c61..efa4733 100755 --- a/scripts/kconfig/merge_config.sh +++ b/scripts/kconfig/merge_config.sh @@ -87,7 +87,7 @@ TMP_FILE=$(mktemp ./.tmp.config.XX) echo "Using $INITFILE as base" cat $INITFILE > $TMP_FILE -# Merge files, printing warnings on overrided values +# Merge files, printing warnings on overridden values for MERGE_FILE in $MERGE_LIST ; do echo "Merging $MERGE_FILE" CFG_LIST=$(sed -n "$SED_CONFIG_EXP" $MERGE_FILE) -- ================ 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] "make help" talks about "starred" targets when nothing is starred
running "make help" concludes with the claim: "Execute "make" or "make all" to build all targets marked with [*]" but i see no make targets marked that way -- i suspect that was just a copy and paste from the kernel Makefile, yes? rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] "make help" talks about "starred" targets when nothing is starred
On Wed, 22 Oct 2014, Masahiro Yamada wrote: > > > > > On Tue, 21 Oct 2014 16:23:24 -0400 (EDT) > "Robert P. J. Day" wrote: > > > > > running "make help" concludes with the claim: > > > > "Execute "make" or "make all" to build all targets marked with [*]" > > > > but i see no make targets marked that way -- i suspect that was just a > > copy and paste from the kernel Makefile, yes? > > > > rday > > > > > Yes. > > > I think at least > > u-boot- Build the bare u-boot > > > should be marked with * > > > (although u-boot.bin and some other SoC-specific boot images > are generally created.) i'll let someone higher up the food chain handle that, just wanted to make sure i wasn't misunderstanding 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] practicality of demonstrating u-boot in a QEMU session?
i'm teaching some embedded linux next week and, while i will have physical boards for the students to play with, i'd also like to demonstrate basic u-boot within a QEMU session as far as that's practical. the boards themselves will be powerpc-based lite5200 (icecube) systems all currently populated with u-boot (some old versions, some newer) so certainly they'll have u-boot on the systems when the time comes to start running them. regarding the QEMU session, i get the impression that QEMU and powerpc still have problems but, if it's a QEMU session, i'm free to choose the architecture so picking ARM is probably a good bet. i found a couple useful articles online: http://balau82.wordpress.com/2010/03/10/u-boot-for-arm-on-qemu/ http://balau82.wordpress.com/2010/04/12/booting-linux-with-u-boot-on-qemu-arm/ so i can use them as a starting point, but both of them are well over a year old so i'm wondering if there's a more recent, canonical online explanation of emulating u-boot in a QEMU session just for demo purposes, and at what point the emulation breaks down given the lack of actual underlying hardware. thanks for any pointers. i've never tried u-boot in a QEMU session before; hence the fairly intro-level request for help. 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] practicality of demonstrating u-boot in a QEMU session?
On Mon, 28 Nov 2011, Wolfgang Denk wrote: > Dear "Robert P. J. Day", > > In message you wrote: > > > > i'm teaching some embedded linux next week and, while i will have > > physical boards for the students to play with, i'd also like to > > demonstrate basic u-boot within a QEMU session as far as that's > > practical. > > Or use sandbox? ah, i was unaware of that, 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
[U-Boot] having trouble booting a simple kernel on a TQM860 board
(since it's been a while since i've had to mess with u-boot, it is entirely possible that i'm doing something amazingly dumb but here we go.) i've got two different types of PPC boards in front of me -- some lite5200's and some tqm860's -- and all i want to do is verify that i can build a kernel for each, TFTP it down to the board and boot that kernel. i don't care that it will fall over when it tries to mount a root filesystem, i just want to see the early kernel boot output to verify that at least that part of the process is working. i'm using the 2.6.37 kernel for both and while the lite5200s have a fairly new version of u-boot (2010.12), the TQMs have an ancient version (0.4.0, possibly slightly newer), and i have no freedom to update those so don't even make the suggestion. i just have to live with that. the lite5200s are no problem. with them, i just: $ make ARCH=powerpc 52xx/lite5200b_defconfig $ make ARCH=powerpc and eventually, i get arch/powerpc/boot/cuImage.lite5200, download that and go. so the lite5200s are not an issue. with the tqm860's, i'm following some documentation that was given to me that allegedly has worked in the past, so i run: $ make ARCH=powerpc tqm8xx_defconfig $ make ARCH=powerpc uImage what i get in arch/powerpc/boot is: $ file uImage uImage: u-boot legacy uImage, Linux-2.6.37, Linux/PowerPC, OS Kernel Image (gzip), 1301506 bytes, Fri Dec 2 18:08:06 2011, Load Address: 0x, Entry Point: 0x, Header CRC: 0x476FD0BD, Data CRC: 0xE355BE2A $ $ mkimage -l uImage Image Name: Linux-2.6.37 Created: Fri Dec 2 18:08:06 2011 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1301506 Bytes = 1271.00 kB = 1.24 MB Load Address: Entry Point: which *seems* all right, but i'm not a powerpc expert. so i copy this to the TFTP dir under the name "uImage.tqm860", and on the board: => tftp 40 uImage.tqm860 TFTP from server 192.168.202.100; our IP address is 192.168.202.79 Filename 'uImage.tqm860'. Load address: 0x40 Loading: ... snip ... done Bytes transferred = 1301570 (13dc42 hex) => i can check that the download worked: => imi 40 ## Checking Image at 0040 ... Image Name: Linux-2.6.37 Created: 2011-12-02 23:08:06 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1301506 Bytes = 1.2 MB Load Address: Entry Point: Verifying Checksum ... OK => and, at this point, i would think that all i need to do is: => bootm 40 ## Booting image at 0040 ... Image Name: Linux-2.6.37 Created: 2011-12-02 23:08:06 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1301506 Bytes = 1.2 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK and that's where it hangs. i have no idea if it's still booting properly but i've simply screwed up the serial port setting. does this set of steps look reasonable? the configuration, the building, the TFTP, the verification steps, the "bootm" command? this is what's printed when the board resets: U-Boot 0.4.0 (Apr 13 2004 - 15:01:22) CPU: XPC860xxZPnnD4 at 80 MHz: 16 kB I-Cache 8 kB D-Cache FEC present Board: TQM860LDB0A3-P80.208 DRAM: 16 MB FLASH: 8 MB In:serial Out: serial Err: serial Net: SCC ETHERNET [PRIME], FEC ETHERNET PCMCIA: No Card found am i just missing something obvious? what should i use for the kernel console setting? i'm open to suggestions. 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] having trouble booting a simple kernel on a TQM860 board
On Fri, 2 Dec 2011, Scott Wood wrote: > On 12/02/2011 05:19 PM, Robert P. J. Day wrote: > > and, at this point, i would think that all i need to do is: > > > > => bootm 40 > > ## Booting image at 0040 ... > >Image Name: Linux-2.6.37 > >Created: 2011-12-02 23:08:06 UTC > >Image Type: PowerPC Linux Kernel Image (gzip compressed) > >Data Size:1301506 Bytes = 1.2 MB > >Load Address: > >Entry Point: > >Verifying Checksum ... OK > >Uncompressing Kernel Image ... OK > > You need to use a cuImage, just as you did with lite5200. ok, so what's the "make" invocation to get one of those? i'm not a ppc expert so i don't know much about device trees. i tried the following: $ make ARCH=powerpc cuImage.tqm8xx CHK include/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h CALLarch/powerpc/kernel/systbl_chk.sh /home/rpjday/karim/el/ws/tqm860/kernel/linux-2.6.37/scripts/dtc/dtc -O dtb -o arch/powerpc/boot/tqm8xx.dtb -b 0 -p 1024 /home/rpjday/karim/el/ws/tqm860/kernel/linux-2.6.37/arch/powerpc/boot/dts/tqm8xx.dts DTC: dts->dtb on file "/home/rpjday/karim/el/ws/tqm860/kernel/linux-2.6.37/arch/powerpc/boot/dts/tqm8xx.dts" WRAParch/powerpc/boot/cuImage.tqm8xx powerpc-unknown-linux-gnu-ld: arch/powerpc/boot/cuboot-tqm8xx.o: No such file: No such file or directory make[1]: *** [arch/powerpc/boot/cuImage.tqm8xx] Error 1 rm arch/powerpc/boot/tqm8xx.dtb make: *** [cuImage.tqm8xx] Error 2 so i'm open to suggestions. 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] having trouble booting a simple kernel on a TQM860 board
On Fri, 2 Dec 2011, Scott Wood wrote: > On 12/02/2011 05:41 PM, Robert P. J. Day wrote: > > ok, so what's the "make" invocation to get one of those? i'm not a > > ppc expert so i don't know much about device trees. i tried the > > following: > > > > $ make ARCH=powerpc cuImage.tqm8xx > > CHK include/linux/version.h > > CHK include/generated/utsrelease.h > > CALLscripts/checksyscalls.sh > > CHK include/generated/compile.h > > CALLarch/powerpc/kernel/systbl_chk.sh > > /home/rpjday/karim/el/ws/tqm860/kernel/linux-2.6.37/scripts/dtc/dtc -O > > dtb -o arch/powerpc/boot/tqm8xx.dtb -b 0 -p 1024 > > /home/rpjday/karim/el/ws/tqm860/kernel/linux-2.6.37/arch/powerpc/boot/dts/tqm8xx.dts > > DTC: dts->dtb on file > > "/home/rpjday/karim/el/ws/tqm860/kernel/linux-2.6.37/arch/powerpc/boot/dts/tqm8xx.dts" > > WRAParch/powerpc/boot/cuImage.tqm8xx > > powerpc-unknown-linux-gnu-ld: arch/powerpc/boot/cuboot-tqm8xx.o: No > > such file: No such file or directory > > make[1]: *** [arch/powerpc/boot/cuImage.tqm8xx] Error 1 > > rm arch/powerpc/boot/tqm8xx.dtb > > make: *** [cuImage.tqm8xx] Error 2 > > > > so i'm open to suggestions. > > In the cuboot section of arch/powerpc/boot/wrapper, add "*-tqm8xx" to > the "*-mpc866ads|*-mpc885ads..." list. ok, that's looking better as i now have the following: $ mkimage -l /var/lib/tftpboot/cuImage.tqm8xx Image Name: Linux-2.6.37 Created: Fri Dec 2 18:53:22 2011 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1325774 Bytes = 1294.70 kB = 1.26 MB Load Address: 0040 Entry Point: 00400518 $ which suggests it's safe to TFTP it to 20 given its size and the load address, so ... => tftp 20 cuImage.tqm8xx TFTP from server 192.168.202.100; our IP address is 192.168.202.79 Filename 'cuImage.tqm8xx'. Load address: 0x20 Loading: ... snip ... done Bytes transferred = 1325838 (143b0e hex) => imi 20 ## Checking Image at 0020 ... Image Name: Linux-2.6.37 Created: 2011-12-02 23:53:22 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1325774 Bytes = 1.3 MB Load Address: 0040 Entry Point: 00400518 Verifying Checksum ... OK => setenv bootargs console=ttyCPM0,115000 => bootm 20 at which point i get the kernel uncompressing, followed by several lines of garbage, suggesting that perhaps my minicom setup is not right. any final suggestions about console port setup? i get the feeling i'm really close ... 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] having trouble booting a simple kernel on a TQM860 board
On Sat, 3 Dec 2011, Wolfgang Denk wrote: > Dear Robert, > > In message you wrote: > > > > i'm using the 2.6.37 kernel for both and while the lite5200s > > have a fairly new version of u-boot (2010.12), the TQMs have an > > ancient version (0.4.0, possibly slightly newer), and i have no > > freedom to update those so don't even make the suggestion. i just > > have to live with that. > > What you say boils down to: Please help me, but don't mention the > solution, because I'm not going to do that. In short, it's stupid. > You are wasting your time, and ours. > > In the first step, please update your U-Boot. 0.4.0 has no support > for device tree. as i already mentioned in an earlier e-mail, these are not my boards and i have no authority to do that. so i am *necessarily* restricted to trying to do this with u-boot 0.4.0, and that's just the way it is. sometimes, you just have to work with what you're given, wolfgang. sorry if that cramps your style. 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] TQM860L_config: u-boot.lds:76 cannot move location counter backwards
so i got permission to try to update u-boot on one of the TQM860 boards, so i checked out the u-boot git repo, ran: $ make TQM860L_config $ make and eventually got: u-boot.lds:76 cannot move location counter backwards (from 40008604 to 40008000) make: *** [u-boot] Error 1 i can read an explanation of what that allegedly means here: http://www.denx.de/wiki/view/DULG/PortingProblemCannotMoveLocationCounterBackwards but that explanation is in the context of someone *porting* u-boot to a new board. should i expect this for what should be an already supported board? in any event, it's late so i'll tackle this again tomorrow. 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] TQM860L_config: u-boot.lds:76 cannot move location counter backwards
On Sat, 3 Dec 2011, Marek Vasut wrote: > > so i got permission to try to update u-boot on one of the TQM860 > > boards, so i checked out the u-boot git repo, ran: > > > > $ make TQM860L_config > > $ make > > > > and eventually got: > > > > u-boot.lds:76 cannot move location counter backwards (from 40008604 to > > 40008000) make: *** [u-boot] Error 1 > > > > i can read an explanation of what that allegedly means here: > > > > http://www.denx.de/wiki/view/DULG/PortingProblemCannotMoveLocationCounterBa > > ckwards > > > > but that explanation is in the context of someone *porting* u-boot to > > a new board. should i expect this for what should be an already > > supported board? > > > > in any event, it's late so i'll tackle this again tomorrow. > > > > rday > > What version of uboot do you use? What compiler and it's version do you use? i'm using the latest "git pull" of u-boot, and: $ powerpc-unknown-linux-gnu-gcc --version powerpc-unknown-linux-gnu-gcc (crosstool-NG-1.10.0) 4.4.5 ... i get the same result with u-boot 2010.12. 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] TQM860L_config: u-boot.lds:76 cannot move location counter backwards
On Sat, 3 Dec 2011, Wolfgang Denk wrote: > Dear Robert, > > In message you wrote: > > > > > What version of uboot do you use? What compiler and it's version do you > > > use? > > > > i'm using the latest "git pull" of u-boot, and: > > > > $ powerpc-unknown-linux-gnu-gcc --version > > powerpc-unknown-linux-gnu-gcc (crosstool-NG-1.10.0) 4.4.5 > > ... > > > > i get the same result with u-boot 2010.12. > > Your tool chain is broken / generates inefcient code. ok, i'll grab another one, thanks. rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TQM860L_config: u-boot.lds:76 cannot move location counter backwards
On Sat, 3 Dec 2011, Marek Vasut wrote: > > On Sat, 3 Dec 2011, Wolfgang Denk wrote: > > > Dear Robert, > > > > > > In message you wrote: > > > > > What version of uboot do you use? What compiler and it's version do > > > > > you use? > > > > > > > > > i'm using the latest "git pull" of u-boot, and: > > > > $ powerpc-unknown-linux-gnu-gcc --version > > > > powerpc-unknown-linux-gnu-gcc (crosstool-NG-1.10.0) 4.4.5 > > > > ... > > > > > > > > i get the same result with u-boot 2010.12. > > > > > > Your tool chain is broken / generates inefcient code. > > > > ok, i'll grab another one, thanks. > > > > rday > > I think I told you already to try ELDK 5.0 / 5.1. downloading as we speak. rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TQM860L_config: u-boot.lds:76 cannot move location counter backwards
On Sat, 3 Dec 2011, Wolfgang Denk wrote: > Dear Robert, > > In message you wrote: > > > > > What version of uboot do you use? What compiler and it's version do you > > > use? > > > > i'm using the latest "git pull" of u-boot, and: > > > > $ powerpc-unknown-linux-gnu-gcc --version > > powerpc-unknown-linux-gnu-gcc (crosstool-NG-1.10.0) 4.4.5 > > ... > > > > i get the same result with u-boot 2010.12. > > Your tool chain is broken / generates inefcient code. > > Top of tree: > -> git describe > v2011.09-1259-g7708d8b > -> eldk-switch -r 4.2 ppc_8xx > Setup for ppc_8xx (using ELDK 4.2) i'm sure someone will yell at me for this question as well, but where does one find "eldk-switch"? i have a fully updated git clone of uboot and there is no such script (which is what i assume i'm looking for). rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TQM860L_config: u-boot.lds:76 cannot move location counter backwards
On Sat, 3 Dec 2011, Anatolij Gustschin wrote:
> Hi Robert,
>
> On Sat, 3 Dec 2011 12:47:47 -0500 (EST)
> "Robert P. J. Day" wrote:
> ...
> > > Top of tree:
> > > -> git describe
> > > v2011.09-1259-g7708d8b
> > > -> eldk-switch -r 4.2 ppc_8xx
> > > Setup for ppc_8xx (using ELDK 4.2)
> >
> > i'm sure someone will yell at me for this question as well, but
> > where does one find "eldk-switch"? i have a fully updated git clone
> > of uboot and there is no such script (which is what i assume i'm
> > looking for).
>
> eldk-switch is internally used script, it is not distributed with
> U-Boot since its purpose is to configure environment in preparation
> for building using desired ELDK version.
>
> You don't need this script. You can setup environment i. e. by
> running
>
> $ export ARCH=powerpc
> $ export CROSS_COMPILE=ppc_8xx-
> $ export PATH=/usr/bin:$PATH
>
> To check if the environment is set correctly you can try to run
> installed cross gcc, i.e. run:
>
> ${CROSS_COMPILE}gcc -v
>
> More info is available in ELDK documentation, i. e. [1]
um, my understanding for the need of that script (or its equivalent,
which i assume is just to switch to the git 4.2 branch), is to avoid
this issue:
http://lists.denx.de/pipermail/eldk/2011-November/002052.html
which is *precisely* what i ran into, so i'm assuming i need to back
off to v4.2. unless that issue has been addressed already in the ELDK
toolchain development branch but i didn't see any git commit that
referred to 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
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TQM860L_config: u-boot.lds:76 cannot move location counter backwards
On Sat, 3 Dec 2011, Anatolij Gustschin wrote: > On Sat, 3 Dec 2011 15:12:44 -0500 (EST) > "Robert P. J. Day" wrote: > ... > > um, my understanding for the need of that script (or its equivalent, > > which i assume is just to switch to the git 4.2 branch), is to avoid > > this issue: > > > > http://lists.denx.de/pipermail/eldk/2011-November/002052.html > > > > which is *precisely* what i ran into, so i'm assuming i need to back > > off to v4.2. unless that issue has been addressed already in the ELDK > > toolchain development branch but i didn't see any git commit that > > referred to it. > > For mpc860 you have to use pre-build ELDK-4.2, available at [1]. > Mount the iso file, install ppc_8xx cpu family version as described > in ELDK documentation [2]. > > Anatolij > > [1] > ftp://ftp.denx.de/pub/eldk/4.2/ppc-linux-x86/iso/ppc-2008-04-01_freescale.iso > [2] http://www.denx.de/wiki/view/DULG/ELDKInitialInstallation ok, i've gone through that process before, 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] having trouble booting a simple kernel on a TQM860 board
On Fri, 2 Dec 2011, Scott Wood wrote: > On 12/02/2011 05:19 PM, Robert P. J. Day wrote: > > and, at this point, i would think that all i need to do is: > > > > => bootm 40 > > ## Booting image at 0040 ... > >Image Name: Linux-2.6.37 > >Created: 2011-12-02 23:08:06 UTC > >Image Type: PowerPC Linux Kernel Image (gzip compressed) > >Data Size:1301506 Bytes = 1.2 MB > > Load Address: > >Entry Point: > >Verifying Checksum ... OK > >Uncompressing Kernel Image ... OK > > You need to use a cuImage, just as you did with lite5200. i believe i've solved this issue, at least. i downloaded ELDK 4.2 and installed the ppc_8xx- toolchain. with that, i managed to compile u-boot 2010.12 and flashed it to my TQM860, reset and, lo and behold, i have a 2010.12 u-boot. so my u-boot issue seems to be resolved. > Or update U-Boot and pass a device tree. > > > and that's where it hangs. > > > > i have no idea if it's still booting properly but i've simply > > screwed up the serial port setting. > > > > does this set of steps look reasonable? the configuration, the > > building, the TFTP, the verification steps, the "bootm" command? this > > is what's printed when the board resets: > > > > U-Boot 0.4.0 (Apr 13 2004 - 15:01:22) > > > > CPU: XPC860xxZPnnD4 at 80 MHz: 16 kB I-Cache 8 kB D-Cache FEC > > present > > Board: TQM860LDB0A3-P80.208 > > DRAM: 16 MB > > FLASH: 8 MB > > In:serial > > Out: serial > > Err: serial > > Net: SCC ETHERNET [PRIME], FEC ETHERNET > > PCMCIA: No Card found > > > > am i just missing something obvious? what should i use for the > > kernel console setting? i'm open to suggestions. > > console=ttyCPM0 ok, i'm still having trouble getting a bootable kernel so here's what i did. using 2.6.37 version of kernel source, i followed your advice and first just configured for the 860 with: $ make ARCH=powerpc tqm8xx_defconfig then $ make ARCH=powerpc uImage which generated a uImage file. but as i understand it, i want a cuImage-format file as i used with my lite5200, so i edited the file arch/powerpc/boot/wrapper (as you suggested) and made the following change: case "$platform" in *-mpc866ads|*-mpc885ads|*-adder875*|*-ep88xc|*-tqm8xx) ^ added which now allows me to do the following: $ make ARCH=powerpc cuImage.tqm8xx and it's my understanding that this is the file i'll TFTP down to the TQM860 board and boot, correct? here's a look at that file: $ mkimage -l /var/lib/tftpboot/cuImage.tqm8xx Image Name: Linux-2.6.37 Created: Sun Dec 4 20:51:56 2011 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1258640 Bytes = 1229.14 kB = 1.20 MB Load Address: 0x0040 Entry Point: 0x0040055C $ look reasonable? so i download to the board to address 20, check it: => imi 20 ## Checking Image at 0020 ... Legacy image found Image Name: Linux-2.6.37 Created: 2011-12-05 1:51:56 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1258640 Bytes = 1.2 MiB Load Address: 0040 Entry Point: 0040055c Verifying Checksum ... OK => but at this point, any attempt to "bootm 20" gives me (as before): ## Booting kernel from Legacy Image at 0020 ... Image Name: Linux-2.6.37 Created: 2011-12-05 1:51:56 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1258640 Bytes = 1.2 MiB Load Address: 0040 Entry Point: 0040055c Verifying Checksum ... OK Uncompressing Kernel Image ... OK immediately followed by a long line of diamonds with question marks inside them. i would assume i've just screwed up the console setting, but i've tried various combinations of tty0, ttyS0 and ttyCPM0, with different baud rates. any hint as to what i should be looking at? i suspect i'm close, i just have this last issue to deal with. thanks. rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] having trouble booting a simple kernel on a TQM860 board
On Mon, 5 Dec 2011, Wolfgang Denk wrote: > Dear Robert, > > In message you wrote: > > > > i believe i've solved this issue, at least. i downloaded ELDK 4.2 > > and installed the ppc_8xx- toolchain. with that, i managed to compile > > u-boot 2010.12 and flashed it to my TQM860, reset and, lo and behold, > > i have a 2010.12 u-boot. so my u-boot issue seems to be resolved. > > You update U-Boot, but to a version 4 releases old. Why not to > current code? i have a number of lite5200s as well that all have 2010.12 on them and since they work fine for now, i just wanted to make everything consistent for some people who will be using those boards this week. once this session is over, everything will be reflashed to the current version. your point is, of course, well taken. > > which generated a uImage file. but as i understand it, i want a > > cuImage-format file as i used with my lite5200, so i edited the file > > No. Now you don't need a cuImage nay more. Just use the DT as I > showed you in the builkd and boot log I sent before. ah, gotcha. i'll do that, 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] having trouble booting a simple kernel on a TQM860 board
On Mon, 5 Dec 2011, Wolfgang Denk wrote: > Dear Robert, > > In message you wrote: > > > > i believe i've solved this issue, at least. i downloaded ELDK 4.2 > > and installed the ppc_8xx- toolchain. with that, i managed to > > compile u-boot 2010.12 and flashed it to my TQM860, reset and, lo > > and behold, i have a 2010.12 u-boot. so my u-boot issue seems to > > be resolved. > > You update U-Boot, but to a version 4 releases old. Why not to > current code? > > > which generated a uImage file. but as i understand it, i want a > > cuImage-format file as i used with my lite5200, so i edited the file > > No. Now you don't need a cuImage nay more. Just use the DT as I > showed you in the builkd and boot log I sent before. for the sake of clarification, you write that i don't *need* cuImages anymore, but that's not the same as saying that i *must* move to using device trees. in fact, a cuImage file still works just fine for my lite5200 boards, so obviously the version of u-boot that i've flashed to my TQM boards can still handle that format. so while it's probably a good idea to move to the device tree recipe, that still doesn't explain why i can't use a cuImage file for my tqm boards. so i'll test the device tree process later today, but i'm still curious as to why a cuImage format file still fails in this case when it works just fine for the other boards. 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] having trouble booting a simple kernel on a TQM860 board
On Mon, 5 Dec 2011, Wolfgang Denk wrote: > Dear Robert, > > In message you wrote: > > > > > No. Now you don't need a cuImage nay more. Just use the DT as I > > > showed you in the builkd and boot log I sent before. > > > > for the sake of clarification, you write that i don't *need* > > cuImages anymore, but that's not the same as saying that i *must* move > > to using device trees. in fact, a cuImage file still works just fine > > True, you don't have to use the DT. You don't have to use the most > straightforward way that has been well tested for a ton of > combinations of recent U-Boot releases against recent kernel > releases. > > You are free to chose any untested, unsupported way you like. > > It's perfectly fine to ignore all good advice you get here. But > eventually you should then also stop asking further questions here. please stop being so defensive, wolfgang, it doesn't become you. i have no doubt that using a separate device tree is a better idea. but i also like to be very careful with my terminology. if someone says using a device tree is better, i'm fine with that. but an earlier claim of yours seemed to suggest that one *needed* to use a DT, and if that's the case, i just want to know that. i simply like to know what my options are in case Plan A doesn't work, i can try Plan B. also, i was *given* material to work with, and i'm making an effort to change as little of it as possible if i don't have to, at the request of the person who gave it to me. and sometimes, political reasons might trump technical reasons, as much as we don't want them to. 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 the online DULG-tqm8xxL guide reasonably up to date?
rather than cast around looking for a solution, i figure i can better invest my time just reading this end to end: http://www.denx.de/wiki/publish/DULG/DULG-tqm8xxl.html and testing it as i go. should i expect it to be relatively current? i'll make notes about anything that looks odd -- already noticed some minor typoes. 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 the online DULG-tqm8xxL guide reasonably up to date?
On Sat, 10 Dec 2011, Wolfgang Denk wrote: > Dear "Robert P. J. Day", > > In message you wrote: > > > > rather than cast around looking for a solution, i figure i can > > better invest my time just reading this end to end: > > > > http://www.denx.de/wiki/publish/DULG/DULG-tqm8xxl.html > > > > and testing it as i go. should i expect it to be relatively current? > > i'll make notes about anything that looks odd -- already noticed some > > minor typoes. > > Well, did you actually read it? > > It says: > > This document was generated at 01 Mar 2008 - 16:53. > > So the answer is: no, this document has notbeen maintained for a long. > long time. so ... if i ask questions *before* reading the docs, you'll snap at me. and if i propose that i will *now* read the docs before asking any further technical questions, you will ... apparently snap at me. keep up the good work. rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] should tools/env/README also recommend setting HOSTSTRIP?
On Mon, 4 Mar 2013, Tom Rini wrote: > On Thu, Feb 28, 2013 at 08:46:15AM -0500, Robert P. J. Day wrote: > > > it would seem that in addition to manually setting HOSTCC, a user > > should also set HOSTSTRIP when building fw_printenv, no? there's no > > mention of that in the README but the strip operation will certainly > > fail without it. > > True, the README wasn't updated back when we added HOSTSTRIP into the > mix. soon as i get a sec, i can patch that unless someone wants to beat me to 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 http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup
On Tue, 11 Dec 2012, Lukasz Majewski wrote: > Hi Pantelis, > > > Tomorrow I will prepare output of USB Ellisys analizer on my side, so > > we could get clue what is going on. > > Please find attached output from USB ellisys analizer. is it really appropriate to post 8M of output to a mailing list? what's wrong with pastebin? 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] Want to study U-Boot code
On Fri, 25 Jan 2013, Wolfgang Denk wrote: > Dear Woody Wu, > > In message > you > wrote: > > > > I want to firstly get a picture to basically understand how u-boot > > work, especially on an ARM9 based board. I think not everyone who > > want to understand u-boot has to read the full code. Thank. > > This depends on your definition of "understanding". On a highlevel, > you might start with reaing and digesting the manual, eventually > trying out how U-Boot works on some (real or emulated) board. if i can jump in, a good way to start playing is to configure and build for the "sandbox" architecture so you can run it on your x86 system. for the benefit of a couple friends, i whipped together a wiki page for that here: http://www.crashcourse.ca/wiki/index.php/U-Boot_sandbox very simple but enough to get you started, and you can match up running the commands with the underlying code. 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] cmd_usb.c: Make usb help info consistent for "start".
Make USB help info for "start" subcommand consistent with other USB
subcommands.
Signed-off-by: Robert P. J. Day
---
unless there's something different about the "start" subcommand,
this would seem to make sense for consistency.
diff --git a/common/cmd_usb.c b/common/cmd_usb.c
index dacdc2d..f04ee73 100644
--- a/common/cmd_usb.c
+++ b/common/cmd_usb.c
@@ -575,7 +575,7 @@ static int do_usb(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
U_BOOT_CMD(
usb,5, 1, do_usb,
"USB sub-system",
- "start - start (scan) USB controller\n"
+ "usb start - start (scan) USB controller\n"
"usb reset - reset (rescan) USB controller\n"
"usb stop [f] - stop USB [f]=force stop\n"
"usb tree - show USB device tree\n"
@@ -601,7 +601,7 @@ U_BOOT_CMD(
U_BOOT_CMD(
usb,5, 1, do_usb,
"USB sub-system",
- "start - start (scan) USB controller\n"
+ "usb start - start (scan) USB controller\n"
"usb reset - reset (rescan) USB controller\n"
"usb tree - show USB device tree\n"
"usb info [dev] - show available USB devices"
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_SYS_LONGHELP
first, is there any need for so many header files to define the macro CONFIG_SYS_LONGHELP individually? a quick count of how many u-boot source files do just that: $ grep -r "define.*CONFIG_SYS_LONGHELP" * | wc -l 479 $ is it really necessary for almost 500 source files to each define that macro? and second, i'm not sure how to read this out of cmd_pci.c: = start #ifdef CONFIG_SYS_LONGHELP static char pci_help_text[] = "[bus] [long]\n" "- short or long list of PCI devices on bus 'bus'\n" #ifdef CONFIG_CMD_PCI_ENUM "pci enum\n" "- re-enumerate PCI buses\n" #endif "pci header b.d.f\n" "- show header of PCI device 'bus.device.function'\n" "pci display[.b, .w, .l] b.d.f [address] [# of objects]\n" "- display PCI configuration space (CFG)\n" "pci next[.b, .w, .l] b.d.f address\n" "- modify, read and keep CFG address\n" "pci modify[.b, .w, .l] b.d.f address\n" "- modify, auto increment CFG address\n" "pci write[.b, .w, .l] b.d.f address value\n" "- write to CFG address"; #endif U_BOOT_CMD( pci,5, 1, do_pci, "list and access PCI Configuration Space", pci_help_text ); = end note how, if CONFIG_SYS_LONGHELP is defined, the symbol "pci_help_text" is created as the text, but its *usage* just below in the U_BOOT_CMD macro is *outside* of that preprocessor check. how would that work if CONFIG_SYS_LONGHELP is undefined? not at my dev host right this minute so i can't test, but it just looks ... 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 http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] a couple questions about CONFIG_SYS_LONGHELP
On Sat, 26 Jan 2013, Albert ARIBAUD wrote: > Hi Robert, > > On Sat, 26 Jan 2013 06:38:51 -0500 (EST), "Robert P. J. Day" > wrote: ... snip ... > > and second, i'm not sure how to read this out of cmd_pci.c: > > > > = start > > > > #ifdef CONFIG_SYS_LONGHELP > > static char pci_help_text[] = > > "[bus] [long]\n" > > "- short or long list of PCI devices on bus 'bus'\n" > > #ifdef CONFIG_CMD_PCI_ENUM > > "pci enum\n" > > "- re-enumerate PCI buses\n" > > #endif > > "pci header b.d.f\n" > > "- show header of PCI device 'bus.device.function'\n" > > "pci display[.b, .w, .l] b.d.f [address] [# of objects]\n" > > "- display PCI configuration space (CFG)\n" > > "pci next[.b, .w, .l] b.d.f address\n" > > "- modify, read and keep CFG address\n" > > "pci modify[.b, .w, .l] b.d.f address\n" > > "- modify, auto increment CFG address\n" > > "pci write[.b, .w, .l] b.d.f address value\n" > > "- write to CFG address"; > > #endif > > > > U_BOOT_CMD( > > pci,5, 1, do_pci, > > "list and access PCI Configuration Space", pci_help_text > > ); > > > > = end > > > > note how, if CONFIG_SYS_LONGHELP is defined, the symbol > > "pci_help_text" is created as the text, but its *usage* just below in > > the U_BOOT_CMD macro is *outside* of that preprocessor check. how > > would that work if CONFIG_SYS_LONGHELP is undefined? not at my dev > > host right this minute so i can't test, but it just looks ... weird. > > Probably would not work. Submit a fix. :) there appears to be a number of common/cmd_*.c files that have that structure: $ grep "ifdef.*CONFIG_SYS_LONGHELP" cmd*.c cmd_bootm.c:#ifdef CONFIG_SYS_LONGHELP cmd_bootm.c:#ifdef CONFIG_SYS_LONGHELP cmd_fdt.c:#ifdef CONFIG_SYS_LONGHELP cmd_help.c:#ifdef CONFIG_SYS_LONGHELP cmd_i2c.c:#ifdef CONFIG_SYS_LONGHELP cmd_mp.c:#ifdef CONFIG_SYS_LONGHELP cmd_mtdparts.c:#ifdef CONFIG_SYS_LONGHELP cmd_nand.c:#ifdef CONFIG_SYS_LONGHELP cmd_nvedit.c:#ifdef CONFIG_SYS_LONGHELP cmd_pci.c:#ifdef CONFIG_SYS_LONGHELP cmd_source.c:#ifdef CONFIG_SYS_LONGHELP cmd_ximg.c:#ifdef CONFIG_SYS_LONGHELP $ so it's not just one 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 http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_usb.c: Make usb help info consistent for "start".
On Sat, 26 Jan 2013, Robert P. J. Day wrote: > > Make USB help info for "start" subcommand consistent with other USB > subcommands. ACK, never mind, i just remembered that the first character string of the long help automatically gets the command name prepended. apologies. 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] a couple questions about CONFIG_SYS_LONGHELP
On Sat, 26 Jan 2013, Albert ARIBAUD wrote: > Hi Robert, > > On Sat, 26 Jan 2013 07:11:18 -0500 (EST), "Robert P. J. Day" > wrote: > > > On Sat, 26 Jan 2013, Albert ARIBAUD wrote: > > > > > Hi Robert, > > > > > > On Sat, 26 Jan 2013 06:38:51 -0500 (EST), "Robert P. J. Day" > > > wrote: > > > > ... snip ... > > > > > > and second, i'm not sure how to read this out of cmd_pci.c: > > > > > > > > = start > > > > > > > > #ifdef CONFIG_SYS_LONGHELP > > > > static char pci_help_text[] = > > > > "[bus] [long]\n" > > > > "- short or long list of PCI devices on bus 'bus'\n" > > > > #ifdef CONFIG_CMD_PCI_ENUM > > > > "pci enum\n" > > > > "- re-enumerate PCI buses\n" > > > > #endif > > > > "pci header b.d.f\n" > > > > "- show header of PCI device 'bus.device.function'\n" > > > > "pci display[.b, .w, .l] b.d.f [address] [# of objects]\n" > > > > "- display PCI configuration space (CFG)\n" > > > > "pci next[.b, .w, .l] b.d.f address\n" > > > > "- modify, read and keep CFG address\n" > > > > "pci modify[.b, .w, .l] b.d.f address\n" > > > > "- modify, auto increment CFG address\n" > > > > "pci write[.b, .w, .l] b.d.f address value\n" > > > > "- write to CFG address"; > > > > #endif > > > > > > > > U_BOOT_CMD( > > > > pci,5, 1, do_pci, > > > > "list and access PCI Configuration Space", pci_help_text > > > > ); > > > > > > > > = end > > > > > > > > note how, if CONFIG_SYS_LONGHELP is defined, the symbol > > > > "pci_help_text" is created as the text, but its *usage* just below in > > > > the U_BOOT_CMD macro is *outside* of that preprocessor check. how > > > > would that work if CONFIG_SYS_LONGHELP is undefined? not at my dev > > > > host right this minute so i can't test, but it just looks ... weird. > > > > > > Probably would not work. Submit a fix. :) > > > > there appears to be a number of common/cmd_*.c files that have that > > structure: > > > > $ grep "ifdef.*CONFIG_SYS_LONGHELP" cmd*.c > > cmd_bootm.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_bootm.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_fdt.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_help.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_i2c.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_mp.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_mtdparts.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_nand.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_nvedit.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_pci.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_source.c:#ifdef CONFIG_SYS_LONGHELP > > cmd_ximg.c:#ifdef CONFIG_SYS_LONGHELP > > $ > > > > so it's not just one file. > > The grep above just shows that there are files have conditionally > compiled code for CONFIG_SYS_LONGHELP; however it does not show per > se that these files wound not compile without it. i'm aware of that -- but i manually examined some of the files above, and all of the ones i looked at had the same "issue" as cmd_pci.c. the grep command was not meant as proof, i just used it as a guide for which files i wanted to look at more closely, and i see the same problem with all of them. so someone higher up the food chain than me can decide if this is something worth addressing. 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] fw_env.config: Correct "fw_saveenv" to "fw_setenv".
Fix a comment in the fw_env.config file, no functional change. Signed-off-by: Robert P. J. Day --- diff --git a/tools/env/fw_env.config b/tools/env/fw_env.config index 8e21d5a..9d3b1a4 100644 --- a/tools/env/fw_env.config +++ b/tools/env/fw_env.config @@ -1,4 +1,4 @@ -# Configuration file for fw_(printenv/saveenv) utility. +# Configuration file for fw_(printenv/setenv) utility. # Up to two entries are valid, in this case the redundant # environment sector is assumed present. # Notice, that the "Number of sectors" is ignored on NOR and SPI-dataflash. -- ======== 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] anyone implemented a failsafe upgrade involving two kernel/rootfs pairs?
i want to do pretty much what's described here:
https://github.com/DFE/HidaV/wiki/Safe-Update-and-boot-fallbacks
that is, a single u-boot and config in flash, followed by a pair of
kernel/rootfs partitions, that is remotely upgradeable by, from
userspace, determining the "older" (backup) of the pairs, overwriting
that pair with a new pair, then flipping the switch in the u-boot
configuration to always boot the newer kernel and rootfs (with an
emergency revert to the backup pair under circumstances i haven't
imagined yet).
it *looks* fairly straightforward, but while that's a nice write-up,
it does warn right up front that it hasn't been implemented so if
anyone has done something like this they care to share, that would be
delightful.
FYI, i'm using this pdlogic zoom am1808 experimenter kit:
http://www.logicpd.com/products/system-on-modules/zoom-am1808/
for testing and, at the very end, the only change i would have to make
is modify the solution to handle NOR flash that will be on the
production board.
if there's a writeup on this out there somewhere, that would be
great. if not, if i can get this done, i'll be happy to write it up
and post it publicly on my wiki for others.
at the moment, i'm using openembedded to build a bootable
kernel/rootfs pair for this board, and starting by adding the
u-boot-fw-utils package so i have fw_{printenv/setenv} onboard.
thanks for any pointers.
rday
p.s. i do have the bootable SD card that came with the kit, it's
based on the arago project so i know i have something that boots to
userspace as a starting point -- always good to know.
--
================
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] anyone implemented a failsafe upgrade involving two kernel/rootfs pairs?
On Thu, 31 Jan 2013, Wolfgang Denk wrote: > Dear Robert, > > In message you wrote: > > > > that is, a single u-boot and config in flash, followed by a pair of > > kernel/rootfs partitions, that is remotely upgradeable by, from > > userspace, determining the "older" (backup) of the pairs, overwriting > > that pair with a new pair, then flipping the switch in the u-boot > > configuration to always boot the newer kernel and rootfs (with an > > emergency revert to the backup pair under circumstances i haven't > > imagined yet). > > The emergency revert usually relies on two things: > > - Watchdog support that will reset (reboot) the system reliably in > case the Linux kernel does not boot or does not manage to start the > user space control application that will trigger the watchdog. > > - The "boot counter" feature that will allow to run an alternativce > boot command (i. e. booting from the backup) in case the number of > boot attempts exceeds the set limit. > > > it *looks* fairly straightforward, but while that's a nice write-up, > > it does warn right up front that it hasn't been implemented so if > > anyone has done something like this they care to share, that would be > > delightful. > > Things like that have been done a number of times before; the fact > that such features as watchdog support and boot counter were added to > U-Boot are an indication for this. However, in the cases known to me, > the actual implementation was done as shell scripts (i. e. environment > settings) which were not published. ok, i'm going to clear my schedule for the day and just read the u-boot manual cover to cover finally -- it will probably resolve a lot of my questions. if it's all right, i might update some of the manual wiki pages, like this one that corresponds to the patch i just submitted: http://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariablesInLinux where that comment should read: # Configuration file for fw_(printenv/setenv) utility. if it's anything more than just a trivial fix, i'll ask first. rday p.s. just edited that page, hope i did it correctly. onward ... -- 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 bunch of redundant "#define CONFIG_SH 1" lines?
notice the following, in which a number of config files for SH-related boards explicitly define the macro "CONFIG_SH": $ grep -rw CONFIG_SH * common/cmd_bdinfo.c:#elif defined(CONFIG_SH) drivers/bios_emulator/include/x86emu.h:#elif defined (CONFIG_SH) drivers/net/sh_eth.h:#if defined(CONFIG_SH) drivers/net/sh_eth.h:#endif /* defined(CONFIG_SH) */ examples/standalone/stubs.c:#elif defined(CONFIG_SH) include/configs/MigoR.h:#define CONFIG_SH 1 include/configs/ms7722se.h:#define CONFIG_SH1 include/configs/r0p7734.h:#define CONFIG_SH 1 include/configs/rsk7269.h:#define CONFIG_SH 1 include/configs/r2dplus.h:#define CONFIG_SH 1 include/configs/sh7785lcr.h:#define CONFIG_SH 1 include/configs/ms7720se.h:#define CONFIG_SH1 include/configs/sh7752evb.h:#define CONFIG_SH 1 include/configs/ms7750se.h:#define CONFIG_SH1 include/configs/shmin.h:#define CONFIG_SH 1 include/configs/sh7763rdp.h:#define CONFIG_SH 1 include/configs/ap325rxa.h:#define CONFIG_SH1 include/configs/sh7757lcr.h:#define CONFIG_SH 1 include/configs/rsk7264.h:#define CONFIG_SH 1 include/configs/mpr2.h:#define CONFIG_SH1 include/configs/ap_sh4a_4a.h:#define CONFIG_SH 1 include/configs/espt.h:#define CONFIG_SH1 include/configs/r7780mp.h:#define CONFIG_SH 1 include/configs/ecovec.h:#define CONFIG_SH 1 include/configs/rsk7203.h:#define CONFIG_SH 1 $ which is fine -- it doesn't hurt -- but aren't all those define's superfluous since that macro will be defined via this: arch/sh/config.mk:PLATFORM_CPPFLAGS += -DCONFIG_SH -D__SH__ ^^^ not suggesting they deserve immediate removal, just want to verify that my understanding is correct and that they're unnecessary. 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
[U-Boot] some dead code and redundant files for nios?
another observation about header files, this time related to
nios/nios2:
$ grep -r CONFIG_NIOS *
arch/nios2/config.mk:PLATFORM_CPPFLAGS += -DCONFIG_NIOS2 -D__NIOS2__
arch/nios2/cpu/epcs.c:#endif /* CONFIG_NIOS_EPCS */
board/psyent/common/AMDLV065D.c:#if defined(CONFIG_NIOS) <-- ???
board/altera/common/AMDLV065D.c:#if defined(CONFIG_NIOS) <-- ???
common/cmd_bdinfo.c:#elif defined(CONFIG_NIOS2)
examples/standalone/stubs.c:#elif defined(CONFIG_NIOS2)
$
first, given that there is no "nios" architecture anymore, isn't
that preprocessor test of:
#if defined(CONFIG_NIOS)
in those two files always going to be false? the usage is:
#if defined(CONFIG_NIOS)
#include
#else
#include
#endif
and there *is* no nios.h file, anyway, so that pretty clearly looks
like a removable test. more to the point, the same source file --
AMDLV065D.c -- is in two different directories, and they differ
slightly:
$ diff board/{altera,psyent}/common/AMDLV065D.c
175c175
< writeb (b, dst);
---
> writeb (dst, b);
$
that looks kind of weird, doesn't it? i haven't looked any more
closely but for two source files with the same name to have that
single, subtle difference just looks strange.
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] some dead code and redundant files for nios?
On Fri, 1 Feb 2013, Robert P. J. Day wrote:
> ... the same source file -- AMDLV065D.c -- is in two different
> directories, and they differ slightly:
>
> $ diff board/{altera,psyent}/common/AMDLV065D.c
> 175c175
> < writeb (b, dst);
> ---
> > writeb (dst, b);
> $
>
> that looks kind of weird, doesn't it? i haven't looked any more
> closely but for two source files with the same name to have that
> single, subtle difference just looks strange.
i took a couple minutes with "git blame" to discover this:
$ git show 3d22d0b8
diff --git a/board/psyent/common/AMDLV065D.c b/board/psyent/common/AMDLV065D.c
... snip ...
- *cmd = 0xaa;
- *cmd = 0x55;
- *cmd = 0xa0;
- *dst = b;
+ writeb (cmd, 0xaa);
+ writeb (cmd, 0x55);
+ writeb (cmd, 0xa0);
+ writeb (dst, b);
... snip ...
while over in the (almost) identical file:
git show 9e486ab1
commit 9e486ab1c98ea7ab357520307fe5d5a0847cd1bb
Author: Scott McNutt
Date: Tue Mar 30 20:26:15 2010 -0400
nios2: Fix AMDLV065D flash write bug in altera board common tree.
Signed-off-by: Scott McNutt
diff --git a/board/altera/common/AMDLV065D.c b/board/altera/common/AMDLV065D.c
index 72b0a9f..7a1b4d3 100644
--- a/board/altera/common/AMDLV065D.c
+++ b/board/altera/common/AMDLV065D.c
@@ -172,7 +172,7 @@ int write_buff (flash_info_t * info, uchar * src, ulong
addr, ulong cnt)
writeb (0xaa, cmd);
writeb (0x55, cmd);
writeb (0xa0, cmd);
- writeb (dst, b);
+ writeb (b, dst);
/* Verify write */
start = get_timer (0);
$
i don't know what the above is doing, but it would certainly seem
that if a flash write bug was being fixed in one of those files, it
would be fixed in the other. beyond that, i cannot say.
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] wiki page on "information" commands could use more entries?
it seems that the u-boot manual wiki page for "information" commands: http://www.denx.de/wiki/view/DULG/UBootCmdGroupInfo could use a few more entries. off the top of my head, it seems one could add "fatinfo", the mmc subcommands to display the current mmc status and so on. thoughts? certainly, some of the info commands won't apply to all boards, of course, but that page already lists "flinfo" which isn't relevant for boards with no flash. i would also add simple info commands like "version" to that page, just for fun. 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] arm: Clean up/standardize contents of ARM's u-boot.h
Tidy up indentation, and use what appears to be the standard of
"unsigned long" rather than "ulong" in u-boot.h files.
Signed-off-by: Robert P. J. Day
---
should be no functional change here, just aesthetics.
diff --git a/arch/arm/include/asm/u-boot.h b/arch/arm/include/asm/u-boot.h
index 2ba98bc..5b15781 100644
--- a/arch/arm/include/asm/u-boot.h
+++ b/arch/arm/include/asm/u-boot.h
@@ -38,16 +38,16 @@
typedef struct bd_info {
unsigned intbi_baudrate;/* serial console baudrate */
-ulong bi_arch_number; /* unique id for this board */
-ulong bi_boot_params; /* where this board expects params */
- unsigned long bi_arm_freq; /* arm frequency */
- unsigned long bi_dsp_freq; /* dsp core frequency */
- unsigned long bi_ddr_freq; /* ddr frequency */
-struct /* RAM configuration */
-{
- ulong start;
- ulong size;
-} bi_dram[CONFIG_NR_DRAM_BANKS];
+ unsigned long bi_arch_number; /* unique id for this board */
+ unsigned long bi_boot_params; /* where this board expects params */
+ unsigned long bi_arm_freq;/* arm frequency */
+ unsigned long bi_dsp_freq;/* dsp core frequency */
+ unsigned long bi_ddr_freq;/* ddr frequency */
+ struct /* RAM configuration */
+ {
+ unsigned long start;
+ unsigned long size;
+ } bi_dram[CONFIG_NR_DRAM_BANKS];
} bd_t;
/* For image.h:image_check_target_arch() */
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 global_data
first, in include/asm-generic/global_data_flags.h:
* transitional header until we merge global_data.h
what exactly is "transitional" about that header file, what sort of
merging is going to be done with respect to global_data.h?
and in the top-level README file:
"OTE: DECLARE_GLOBAL_DATA_PTR must be used with file-global scope,
or current versions of GCC may "optimize" the code too much."
but in arch/arm/include/asm/arch-at91/clk.h, you have a number of
static inlines of the form:
static inline unsigned long get_main_clk_rate(void)
{
DECLARE_GLOBAL_DATA_PTR;
return gd->main_clk_rate_hz;
}
and based on how gcc optimizes, i'm not convinced that that macro
invocation is going to be in file-global scope, or am i just
forgetting my C scoping rules?
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] why does supposedly generic flash code have references to jffs2?
perusing the code in cmd_flash.c and i'm puzzled by this: #if defined(CONFIG_CMD_MTDPARTS) #include why would supposedly low-level MTD partitioning code have any need for filesystem-specific header files -- in this case, jffs2? a similar example can be found in cmd_mtdparts.c: #include admittedly, i haven't followed the code all the way to the end, but it's not clear to me why fundamental flash, MTD and partitioning code should have any dependency on a particular filesystem type, but i'm certainly willing to be corrected. 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] cmd_mem.c: Fix simple typoes, no functional changes.
Signed-off-by: Robert P. J. Day --- based on perusal of entire file as i was reading code. undoubtedly more of these file-wide proofreads coming if no objections ... diff --git a/common/cmd_mem.c b/common/cmd_mem.c index 0f3ffc8..2568c04 100644 --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -462,7 +462,7 @@ static int do_mem_loop(cmd_tbl_t *cmdtp, int flag, int argc, if (argc < 3) return CMD_RET_USAGE; - /* Check for a size spefication. + /* Check for a size specification. * Defaults to long if no or incorrect specification. */ if ((size = cmd_get_data_size(argv[0], 4)) < 0) @@ -531,7 +531,7 @@ int do_mem_loopw (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if (argc < 4) return CMD_RET_USAGE; - /* Check for a size spefication. + /* Check for a size specification. * Defaults to long if no or incorrect specification. */ if ((size = cmd_get_data_size(argv[0], 4)) < 0) @@ -683,7 +683,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int argc, * Data line test: write a pattern to the first * location, write the 1's complement to a 'parking' * address (changes the state of the data bus so a -* floating bus doen't give a false OK), and then +* floating bus doesn't give a false OK), and then * read the value back. Note that we read it back * into a variable because the next time we read it, * it might be right (been there, tough to explain to @@ -747,7 +747,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int argc, * 1's test on the relevant bits of the * address and checking for aliasing. * This test will find single-bit -* address failures such as stuck -high, +* address failures such as stuck-high, * stuck-low, and shorted pins. The base * address and size of the region are * selected by the caller. -- ================ 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] [PATCH] cmd_mem.c: Fix simple typoes, no functional changes.
On Sat, 2 Feb 2013, Jeroen Hofstee wrote: > On 02/02/2013 05:04 PM, Robert P. J. Day wrote: > > Signed-off-by: Robert P. J. Day > > > > --- > > > >based on perusal of entire file as i was reading code. undoubtedly > > more of these file-wide proofreads coming if no objections ... > > > > diff --git a/common/cmd_mem.c b/common/cmd_mem.c > > index 0f3ffc8..2568c04 100644 > > --- a/common/cmd_mem.c > > +++ b/common/cmd_mem.c > > @@ -462,7 +462,7 @@ static int do_mem_loop(cmd_tbl_t *cmdtp, int flag, int > > argc, > > if (argc < 3) > > return CMD_RET_USAGE; > > > > - /* Check for a size spefication. > > + /* Check for a size specification. > > * Defaults to long if no or incorrect specification. > > */ > > if ((size = cmd_get_data_size(argv[0], 4)) < 0) .. snip ... > nitpicking: the summary line should not end with a dot. point taken, i can resubmit. > multi line comments in u-boot are commonly > > /* > * I span > * multiple lines > */ > > So while at it, you might want to add the empty opening line as well. in cases like this, it's kind of a judgment call. if that's truly a strict standard, then sure. but i'm pretty sure there's a *lot* of the above type of comment in the source and when i'm just fixing comments, i prefer to make as unobtrusive a change as possible. i'll let wolfgang decide, and i'll go with whatever he chooses. note carefully that you used the phrase "commonly", without claiming that it's a hard and fast standard, which is why i left it alone. 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] cmd_mem.c: Fix simple typoes, no functional changes
Signed-off-by: Robert P. J. Day --- i'm going to leave the comment format as it is since it matches all of the other brief comments in that file. diff --git a/common/cmd_mem.c b/common/cmd_mem.c index 0f3ffc8..2568c04 100644 --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -462,7 +462,7 @@ static int do_mem_loop(cmd_tbl_t *cmdtp, int flag, int argc, if (argc < 3) return CMD_RET_USAGE; - /* Check for a size spefication. + /* Check for a size specification. * Defaults to long if no or incorrect specification. */ if ((size = cmd_get_data_size(argv[0], 4)) < 0) @@ -531,7 +531,7 @@ int do_mem_loopw (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if (argc < 4) return CMD_RET_USAGE; - /* Check for a size spefication. + /* Check for a size specification. * Defaults to long if no or incorrect specification. */ if ((size = cmd_get_data_size(argv[0], 4)) < 0) @@ -683,7 +683,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int argc, * Data line test: write a pattern to the first * location, write the 1's complement to a 'parking' * address (changes the state of the data bus so a -* floating bus doen't give a false OK), and then +* floating bus doesn't give a false OK), and then * read the value back. Note that we read it back * into a variable because the next time we read it, * it might be right (been there, tough to explain to @@ -747,7 +747,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int argc, * 1's test on the relevant bits of the * address and checking for aliasing. * This test will find single-bit -* address failures such as stuck -high, +* address failures such as stuck-high, * stuck-low, and shorted pins. The base * address and size of the region are * selected by the caller. -- ================ 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] [PATCH] cmd_mem.c: Fix simple typoes, no functional changes.
On Sun, 3 Feb 2013, Wolfgang Denk wrote: > Dear Robert, > > In message you wrote: > > > > > multi line comments in u-boot are commonly > > > > > > /* > > > * I span > > > * multiple lines > > > */ > > > > > > So while at it, you might want to add the empty opening line as well. > > > > in cases like this, it's kind of a judgment call. if that's truly a > > strict standard, then sure. but i'm pretty sure there's a *lot* of > > the above type of comment in the source and when i'm just fixing > > comments, i prefer to make as unobtrusive a change as possible. > > If you are editing these, then please also fix the multi-line comment > style as suggested. Thanks. so what is the actual standard? besides the above, line space above? line space below? because i see all sorts of variations in the code, the most common of which is: ... snip ... static int mod_mem(cmd_tbl_t *, int, int, int, char * const []); /* Display values from last command. * Memory modify remembered values are different from display memory. */ static uint dp_last_addr, dp_last_size; ... snip ... which, as you can see, has a leading blank line but not a following one. so what's correct? is this written down somewhere? 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 v3] cmd_mem.c: Fix some typoes, no functional changes
Signed-off-by: Robert P. J. Day --- fixing a few simple typoes should not represent this much grief. diff --git a/common/cmd_mem.c b/common/cmd_mem.c index 0f3ffc8..d44aa1d 100644 --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -462,7 +462,8 @@ static int do_mem_loop(cmd_tbl_t *cmdtp, int flag, int argc, if (argc < 3) return CMD_RET_USAGE; - /* Check for a size spefication. + /* +* Check for a size specification. * Defaults to long if no or incorrect specification. */ if ((size = cmd_get_data_size(argv[0], 4)) < 0) @@ -531,7 +532,8 @@ int do_mem_loopw (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if (argc < 4) return CMD_RET_USAGE; - /* Check for a size spefication. + /* +* Check for a size specification. * Defaults to long if no or incorrect specification. */ if ((size = cmd_get_data_size(argv[0], 4)) < 0) @@ -683,7 +685,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int argc, * Data line test: write a pattern to the first * location, write the 1's complement to a 'parking' * address (changes the state of the data bus so a -* floating bus doen't give a false OK), and then +* floating bus doesn't give a false OK), and then * read the value back. Note that we read it back * into a variable because the next time we read it, * it might be right (been there, tough to explain to @@ -747,7 +749,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int argc, * 1's test on the relevant bits of the * address and checking for aliasing. * This test will find single-bit -* address failures such as stuck -high, +* address failures such as stuck-high, * stuck-low, and shorted pins. The base * address and size of the region are * selected by the caller. 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] should config_cmd_all.h list *all* possible commands?
i ask since i glanced at it and it clearly doesn't reference the "gpio" command: ... snip ... #define CONFIG_CMD_FLASH/* flinfo, erase, protect */ #define CONFIG_CMD_FPGA /* FPGA configuration Support */ #define CONFIG_CMD_GETTIME /* Get time since boot */ #define CONFIG_CMD_HASH /* calculate hash / digest */ #define CONFIG_CMD_HWFLOW /* RTS/CTS hw flow control */ ... snip ... i didn't look any further, just thought i'd ask about that 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] in cmd_df.c, why does U_BOOT_CMD reference cmd not defined in that file?
always willing to embarrass myself with silly questions, what is
going on in cmd_df.c? note the command defined is apparently "sf",
which invokes something called "do_serial_flash", which is nowhere to
be seen here:
/*
* Command for accessing DataFlash.
*
* Copyright (C) 2008 Atmel Corporation
*/
#include
#include
static int do_df(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
const char *cmd;
/* need at least two arguments */
if (argc < 2)
goto usage;
cmd = argv[1];
if (strcmp(cmd, "init") == 0) {
df_init(0, 0, 100);
return 0;
}
if (strcmp(cmd, "info") == 0) {
df_show_info();
return 0;
}
usage:
return CMD_RET_USAGE;
}
U_BOOT_CMD(
sf, 2, 1, do_serial_flash,
"Serial flash sub-system",
"probe [bus:]cs - init flash device on given SPI bus and CS")
i'm confused ...
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] cmd_load.c: Add #endif comments to reduce confusion
Signed-off-by: Robert P. J. Day --- i think i got this right ... those chunks are just long enough that comments are useful. diff --git a/common/cmd_load.c b/common/cmd_load.c index 2c8dab1..46db962 100644 --- a/common/cmd_load.c +++ b/common/cmd_load.c @@ -1064,8 +1064,8 @@ U_BOOT_CMD( "- save S-Record file over serial line with offset 'off' and size 'size'" ); #endif /* CONFIG_SYS_LOADS_BAUD_CHANGE */ -#endif -#endif +#endif /* CONFIG_CMD_SAVES */ +#endif /* CONFIG_CMD_LOADS */ #if defined(CONFIG_CMD_LOADB) @@ -1085,7 +1085,7 @@ U_BOOT_CMD( " with offset 'off' and baudrate 'baud'" ); -#endif +#endif /* CONFIG_CMD_LOADB */ /* */ @@ -1115,4 +1115,4 @@ U_BOOT_CMD( "[on|off]" ); -#endif +#endif /* CONFIG_CMD_HWFLOW */ -- ================ 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] "#if defined(CONFIG_CMD_REGINFO)" in cmd_reginfo.c redundant?
another simple clarification -- i realize that a lot of the source files of the form common/cmd_*.c might contain more than just the command code, they might contain infrastructure code that's necessary apart from the commands themselves. but in the case of cmd_reginfo.c, this code at the very end: #if defined(CONFIG_CMD_REGINFO) U_BOOT_CMD( reginfo,2, 1, do_reginfo, "print register information", "" ); #endif it seems that that preprocessor check is superfluous since the entire file is nothing more than the implementation of the "reginfo" command, and the relevant test is already being done in the Makefile: COBJS-$(CONFIG_CMD_REGINFO) += cmd_reginfo.o am i understanding that correctly? 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
[U-Boot] u-boot command list, grouped by source file
while i was scouring the source code in the common/ directory, i put together this lengthy list of all of the possible commands, grouped by their source file and annotated by whatever *additional* CONFIG settings they require: http://www.crashcourse.ca/wiki/index.php/U-Boot_command/file_reference not perfect, but it gives me a quick way to know what source files provide which commands, and under what circumstances. 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] common/cmd_disk.c doesn't actually define any "commands"
another observation from my weekend perusal of all of the common/cmd_*.c files is that, despite its "cmd_" filename prefix, the source file cmd_disk.c doesn't define any actual u-boot commands. according to what i see as u-boot filename naming conventions, it shouldn't be named "cmd_*", should it? rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] common/cmd_disk.c doesn't actually define any "commands"
Quoting Albert ARIBAUD : Hi Robert, On Mon, 04 Feb 2013 07:53:43 -0500, "Robert P. J. Day" wrote: another observation from my weekend perusal of all of the common/cmd_*.c files is that, despite its "cmd_" filename prefix, the source file cmd_disk.c doesn't define any actual u-boot commands. according to what i see as u-boot filename naming conventions, it shouldn't be named "cmd_*", should it? That's arguable: apparently it provides common_diskboot() which implements commands for cmd_ide, cmd_scsi, cmd_usb which use it for implementing their do_diskboot, du_scsiboot, do_usbboot commands respectively. It's purely related to cmd_*. just to be clear, i have no strong opinion on this either way, but my understanding is that source files with the name of "common/cmd_*.c" typically define at least one u-boot "command" with the U_BOOT_CMD macro. as far as i can tell, cmd_disk.c is the only counterexample of that. it may be true that that file provides utility routines for other actual "commmand" files, but so do many others. for example, cmd_fdt.c defines the behaviour of the actual "fdt" command, while fdt-related utility routines are in fdt_support.c or even in libfdt/. it's no big deal, i'm just pointing out that cmd_disk.c flies in the face of a fairly obvious pattern in u-boot filenaming convention. and on that note, i will shut up about it. :-) rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] common/cmd_disk.c doesn't actually define any "commands"
i know i mentioned it this weekend but the only reason i tripped over that cmd_disk.c thingie is that i built myself a cmd_*.c reference list, matching source files with defined commands and any preprocessor conditions that defined them here: http://www.crashcourse.ca/wiki/index.php/U-Boot_command/file_reference i just wanted a truly up-to-date list of u-boot commands, where they come from, and any CONFIG_ settings necessary for compiling them into the u-boot image. it was, unsurprisingly, a very educational experience, where i wandered across the occasional oddity. rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] the weirdness with cmd_df.c
i mentioned this this weekend as well, can someone clarify this? the source file cmd_df.c looks weird: U_BOOT_CMD( sf, 2, 1, do_serial_flash, "Serial flash sub-system", "probe [bus:]cs - init flash device on given SPI bus and CS") so the source file "cmd_df.c" allegedly defines a command called "sf", which invokes "do_serial_flash", which isn't even defined in that source file -- what's defined in that file is "do_df". i don't see "do_serial_flash" defined anywhere in the u-boot source tree. am i just being blind? i see no reference to that source file in Makefile, so i'm guessing it's historical cruft that could be deleted? rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_mtdparts.c: Correct "reseting" to "resetting" in error msgs
Signed-off-by: Robert P. J. Day
---
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index 06fc171..7398371 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -1422,7 +1422,7 @@ static int delete_partition(const char *id)
return 1;
if (generate_mtdparts_save(last_parts, MTDPARTS_MAXLEN) != 0) {
- printf("generated mtdparts too long, reseting to
null\n");
+ printf("generated mtdparts too long, resetting to
null\n");
return 1;
}
return 0;
@@ -1520,7 +1520,7 @@ static int spread_partitions(void)
index_partitions();
if (generate_mtdparts_save(last_parts, MTDPARTS_MAXLEN) != 0) {
- printf("generated mtdparts too long, reseting to null\n");
+ printf("generated mtdparts too long, resetting to null\n");
return 1;
}
return 0;
@@ -2018,7 +2018,7 @@ static int do_mtdparts(cmd_tbl_t *cmdtp, int flag, int
argc,
}
if (generate_mtdparts_save(last_parts, MTDPARTS_MAXLEN) != 0) {
- printf("generated mtdparts too long, reseting to
null\n");
+ printf("generated mtdparts too long, resetting to
null\n");
return 1;
}
--
================
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] cmd_df.c: Delete this clearly unused source file.
Nothing appears to use or compile cmd_df.c anymore.
Signed-off-by: Robert P. J. Day
---
hope this is the right format for deleting a file.
diff --git a/common/cmd_df.c b/common/cmd_df.c
deleted file mode 100644
index f7e5df3..000
--- a/common/cmd_df.c
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * Command for accessing DataFlash.
- *
- * Copyright (C) 2008 Atmel Corporation
- */
-#include
-#include
-
-static int do_df(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
-{
- const char *cmd;
-
- /* need at least two arguments */
- if (argc < 2)
- goto usage;
-
- cmd = argv[1];
-
- if (strcmp(cmd, "init") == 0) {
- df_init(0, 0, 100);
- return 0;
- }
-
- if (strcmp(cmd, "info") == 0) {
- df_show_info();
- return 0;
- }
-
-usage:
- return CMD_RET_USAGE;
-}
-
-U_BOOT_CMD(
- sf, 2, 1, do_serial_flash,
- "Serial flash sub-system",
- "probe [bus:]cs - init flash device on given SPI bus and CS")
--
================
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 configure u-boot to tell me more about NAND flash?
a few basic questions about a board i don't have access to right this minute but did yesterday and will later today. it's an AM1808 experimenter kit lookalike except that it has (allegedly) had its NOR flash replaced with 2G of NAND flash, and i want to figure out what i can add to the current u-boot da850evm configuration to let me poke around and get all the info i can on that flash because there seems to be something strange about the current setup. first, when i let the board boot fully into linux, "dmesg" told me this: "NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit)" that appears to tell me 512M of NAND flash, not 2G. i asked someone who was initially adamant that there was 2G but promised to check with the H/W folks to make absolutely sure. is there a possible reason why 2G would show up only as 512M in dmesg? (not really a u-boot question, just wondering.) next, the u-boot that was on the board didn't have the "flinfo" command so i created my own board based on the da850evm version that was currently being used, defined CONFIG_CMD_FLASH, rebuilt, reflashed, came up to u-boot so first check for flash (oh, u-boot version is 2010.12, so i can do some substantial upgrading later): rday > nand info Device 0: nand0, sector size 128 KiB rday > ok, that looks good, at least u-boot sees a NAND device. but now: rday > flinfo rday > should "flinfo" not tell me about my flash? do i need another config setting for this micron flash chip (whose identity is still a bit of a mystery)? finally, i ran "mtdparts" to get: rday > mtdparts mtdids not defined, no default present rday > so i guess i'll add mtdids in later when i get my hands on the board again. main question -- should flinfo not tell me about my flash? what might this configuration be missing? i should have access to the board in an hour or two. thanks. rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to configure u-boot to tell me more about NAND flash?
Quoting Eric Bénard : Hi Robert, Le Tue, 05 Feb 2013 08:37:20 -0500, "Robert P. J. Day" a écrit : main question -- should flinfo not tell me about my flash? what might this configuration be missing? i should have access to the board in an hour or two. thanks. you can read : doc/README.nand which contains quite a lot of details on how the nand flash are handled in u-boot and how to use the nand commands. *sigh* ... i totally forgot about the doc/ directory. thanks. rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] undefined/undocumented CONFIG_CMD_* macros in u-boot
some time ago, i wrote some simple shell scripts that scanned the kernel source tree and identified oddities in configuration files -- things like Kconfig variables that were defined but never used, macros that were being tested but were never set, etc. i just tweaked one of those scripts to scan the u-boot tree to locate CONFIG_CMD_* variables that were being tested, but weren't "#defined" anywhere. nothing wrong with that, most of them are still documented and i've added at the bottom the fairly short output of those u-boot variables as well as their occurrence in the tree. they fall into three categories, with examples. here's one where there's no #define, but the variable is at least documented so no problem: = CONFIG_CMD_DS4510_RST drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_RST drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_RST drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_RST README: CONFIG_CMD_DS4510_RST * ds4510 I2C rst command here's one where there's no #define, and apparently no documentation anywhere: = CONFIG_CMD_NAND_YAFFS common/cmd_nand.c:#ifdef CONFIG_CMD_NAND_YAFFS common/cmd_nand.c:#ifdef CONFIG_CMD_NAND_YAFFS drivers/mtd/nand/nand_util.c:#ifdef CONFIG_CMD_NAND_YAFFS drivers/mtd/nand/nand_util.c:#ifdef CONFIG_CMD_NAND_YAFFS include/configs/M54418TWR.h:#undef CONFIG_CMD_NAND_YAFFS finally, here's a case that looks like a reference to a command that was never added and thus represents pointless code: = CONFIG_CMD_FUSE arch/powerpc/cpu/mpc512x/iim.c:#ifdef CONFIG_CMD_FUSE arch/powerpc/cpu/mpc512x/iim.c:#endif /* CONFIG_CMD_FUSE */ board/esd/mecp5123/mecp5123.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) board/pdm360ng/pdm360ng.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) board/davedenx/aria/aria.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) board/freescale/mpc5121ads/mpc5121ads.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) include/configs/mecp5123.h:#undef CONFIG_CMD_FUSE include/configs/aria.h:#undef CONFIG_CMD_FUSE include/configs/mpc5121ads.h:#undef CONFIG_CMD_FUSE here's the full list -- not all that long: = CONFIG_CMD_DS4510_MEM drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_MEM drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_MEM drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_MEM drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_MEM drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_MEM README: CONFIG_CMD_DS4510_MEM * ds4510 I2C eeprom/sram commansd = CONFIG_CMD_DS4510_RST drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_RST drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_RST drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_RST README: CONFIG_CMD_DS4510_RST * ds4510 I2C rst command = CONFIG_CMD_ENV_CALLBACK common/cmd_nvedit.c:#if defined(CONFIG_CMD_ENV_CALLBACK) common/cmd_nvedit.c:#if defined(CONFIG_CMD_ENV_CALLBACK) common/cmd_nvedit.c:#if defined(CONFIG_CMD_ENV_CALLBACK) README: CONFIG_CMD_ENV_CALLBACK * display details about env callbacks = CONFIG_CMD_ENV_FLAGS common/cmd_nvedit.c:#if defined(CONFIG_CMD_ENV_FLAGS) common/cmd_nvedit.c:#if defined(CONFIG_CMD_ENV_FLAGS) common/cmd_nvedit.c:#if defined(CONFIG_CMD_ENV_FLAGS) common/env_flags.c:#ifdef CONFIG_CMD_ENV_FLAGS common/env_flags.c:#endif /* CONFIG_CMD_ENV_FLAGS */ include/env_flags.h:#ifdef CONFIG_CMD_ENV_FLAGS README: CONFIG_CMD_ENV_FLAGS* display details about env flags = CONFIG_CMD_FUSE arch/powerpc/cpu/mpc512x/iim.c:#ifdef CONFIG_CMD_FUSE arch/powerpc/cpu/mpc512x/iim.c:#endif /* CONFIG_CMD_FUSE */ board/esd/mecp5123/mecp5123.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) board/pdm360ng/pdm360ng.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) board/davedenx/aria/aria.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) board/freescale/mpc5121ads/mpc5121ads.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) include/configs/mecp5123.h:#undef CONFIG_CMD_FUSE include/configs/aria.h:#undef CONFIG_CMD_FUSE include/configs/mpc5121ads.h:#undef CONFIG_CMD_FUSE = CONFIG_CMD_LINK_LOCAL common/cmd_net.c:#if defined(CONFIG_CMD_LINK_LOCAL) common/cmd_net.c:#endif /* CONFIG_CMD_LINK_LOCAL */ doc/README.link-local:When CONFIG_CMD_LINK_LOCAL is defined in the board config file, doc/README.link-local:by env variables. It depends on CONFIG_CMD_LINK_LOCAL, CONFIG_CMD_DHCP, include/config_uncmd_spl.h:#undef CONFIG_CMD_LINK_LOCAL include/common.h: defined(CONFIG_CMD_LINK_LOCAL) lib/Makefile:COBJS-$(CONFIG_CMD_LINK_LOCAL) += rand.o net/arp.c:#ifdef CONFIG_CMD_LINK_LOCAL net/net.c:#if defined(CONFIG_CMD_LINK_LOCAL) net/link_local.h:#if defined(CONFIG_CMD_LINK_LOCAL) net/Makefile:COBJS-$(CONFIG_CMD_LINK_LOCAL) += link_local.o README: CONFIG_CMD_LINK_LOCAL * link-local IP address auto-configuration = CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES common/cmd_mtdparts.c:#if defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES) common/cmd_mtdparts.c:#if defined(
[U-Boot] "#define"d CONFIG_CMD_* variables that are never used -- short list
self-explanatory -- variables that are explicitly defined but are apparently never used anywhere in the code. amusingly, i had to open up the matching when i noticed the misspelling at the end. if all of these are superfluous, i can submit a single patch to remove it all. i will shut up and go back to work now, but if there's any particular scanning you want, i probably have a script that will do the trick. = CONFIG_CMD_CLEAR include/configs/nokia_rx51.h:#define CONFIG_CMD_CLEAR /* ANSI terminal clear screen command */ = CONFIG_CMD_DEFAULTENV_VARS include/configs/km/keymile-common.h:#define CONFIG_CMD_DEFAULTENV_VARS = CONFIG_CMD_DFL include/configs/armadillo-800eva.h:#define CONFIG_CMD_DFL include/configs/sh7752evb.h:#define CONFIG_CMD_DFL = CONFIG_CMD_MEMTEST include/configs/ppmc8260.h:#define CONFIG_CMD_MEMTEST = CONFIG_CMD_STORAGE include/configs/cam_enc_4xx.h:#define CONFIG_CMD_STORAGE /* inclue support for usb-storage cmd */ include/configs/da830evm.h:#define CONFIG_CMD_STORAGE /* inclue support for usb-storage cmd */ include/configs/davinci_dvevm.h:#define CONFIG_CMD_STORAGE include/configs/davinci_dm365evm.h:#define CONFIG_CMD_STORAGE /* include support for usb */ include/configs/davinci_dm365evm.h:#define CONFIG_CMD_STORAGE /* inclue support for usb-storage cmd */ = CONGIG_CMD_STORAGE include/configs/am3517_evm.h:#define CONGIG_CMD_STORAGE include/configs/am3517_crane.h:#define CONGIG_CMD_STORAGE include/configs/omap3_evm_common.h:#define CONGIG_CMD_STORAGE rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to configure u-boot to tell me more about NAND flash?
Quoting Scott Wood : On 02/05/2013 07:37:20 AM, Robert P. J. Day wrote: a few basic questions about a board i don't have access to right this minute but did yesterday and will later today. it's an AM1808 experimenter kit lookalike except that it has (allegedly) had its NOR flash replaced with 2G of NAND flash, and i want to figure out what i can add to the current u-boot da850evm configuration to let me poke around and get all the info i can on that flash because there seems to be something strange about the current setup. first, when i let the board boot fully into linux, "dmesg" told me this: "NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit)" that appears to tell me 512M of NAND flash, not 2G. i asked someone who was initially adamant that there was 2G but promised to check with the H/W folks to make absolutely sure. is there a possible reason why 2G would show up only as 512M in dmesg? (not really a u-boot question, just wondering.) Is it possible you have 4 chips, each of which are 512 MiB? false alarm ... i got bad initial info and the board really does have exactly 512M of NAND. whew ... wasn't looking forward to trying to debug that. rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] trying to understand u-boot-nand.ais file for AM1808 exp kit
i hope someone here can clear up what should be a simple question -- i'm trying to figure out what exactly is going on when building and flashing a u-boot image for my new AM1808 experimenter kit or, more accurately, someone else's modified version where the 8M of NOR flash has been replaced with 2G of NAND flash. i've downloaded the DaVinci PSP SDK (v03.22.00.02) and i'm trying to figure out what the prebuilt u-boot images mean, and what it means to flash them. the earlier PSP SDK used separate "ubl" and "u-boot" images, so i've seen examples of using the supplied windows-based sfh_OMAP-L138.exe utility to flash the board, in that it had to reference both binary files since, with that earlier PSP SDK, they were separate objects. with this current SDK, the build now creates a combination image, as explained in the User's Guide: "U-Boot included in this release will replace the UBL which was being used to copy U-Boot to external RAM." the contents of the ready-to-flash images directory in this PSP SDK is: u-boot-mmcsd.ais u-boot-mmcsd.bin u-boot-nand.ais u-boot-nor.bin u-boot-spi.ais so my questions are: 1) when one "flashes" these images to the board, where exactly are they being placed? in some SPI flash of some kind totally separate from the main NOR (or, in this case, NAND) flash? 2) given that the standard NOR flash has been replaced with NAND, which (now single) u-boot image file should i be flashing? i *think*, from the user guide, it would be u-boot-nand.ais, as the command for flashing to NAND flash is given as: > ..\sfh_OMAP-L138.exe -flash_noubl -flashType NAND it's just not clear what command i'd use for this situation, and where that single u-boot image would end up. 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] Fix a couple typoes in tools/env/README
Signed-off-by: Robert P. J. Day --- diff --git a/tools/env/README b/tools/env/README index df020e4..1020b57 100644 --- a/tools/env/README +++ b/tools/env/README @@ -8,7 +8,7 @@ In order to cross-compile fw_printenv, run in the root directory of the U-Boot distribution. For example, make HOSTCC=arm-linux-gcc env -For the run-time utiltity configuration uncomment the line +For the run-time utility configuration uncomment the line #define CONFIG_FILE "/etc/fw_env.config" in fw_env.h. @@ -34,7 +34,7 @@ following lines are relevant: #define DEVICE2_ESIZE 0x4000 #define DEVICE2_ENVSECTORS 2 -Un-define HAVE_REDUND, if you want to use the utlities on a system +Un-define HAVE_REDUND, if you want to use the utilities on a system that does not have support for redundant environment enabled. If HAVE_REDUND is undefined, DEVICE2_NAME is ignored, as is ENV2_SIZE and DEVICE2_ESIZE. -- 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] should tools/env/README also recommend setting HOSTSTRIP?
it would seem that in addition to manually setting HOSTCC, a user should also set HOSTSTRIP when building fw_printenv, no? there's no mention of that in the README but the strip operation will certainly fail without it. rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] still ongoing problems using minicom to talk to u-boot?
the current u-boot manual suggests there are still problems using minicom to connect to u-boot. does anyone know what those problems are, and if they still exist? i've been using minicom to connect to the pre-installed u-boot on my beagleboard for months now, and it's worked reliably, except for one situation. since my laptop has no serial port, i'd purchased a low-end USB-serial converter (with a prolific chipset), which failed utterly. i tried everything to debug my setup until someone else suggested that the converter was at fault. i purchased a different converter and everything was fine. so i'm still curious about potential problems with minicom and u-boot. rday -- ================ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] still ongoing problems using minicom to talk to u-boot?
On Wed, 19 Aug 2009, Wolfgang Denk wrote: > Dear "Robert P. J. Day", > > In message you wrote: > > > > i purchased a different converter and everything was fine. so i'm > > still curious about potential problems with minicom and u-boot. > > Just RTFM: http://www.denx.de/wiki/view/DULG/SystemSetup#Section_4.4. i *did* read that, which is why i was asking. i'm trying to figure out *what* specific problem minicom has that is avoided by the use of cu or kermit, something that short section doesn't address. rday -- ================ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] building u-boot using ELDK on 64-bit fedora 11
i spent a few minutes earlier this morning building the latest u-boot for my beagleboard using the ELDK 4.2 arm toolchain on my 64-bit fedora 11 system and since google showed me there was some discussion as to how to do that on 64-bit debian, i figured i'd just verify that what i did seemed sane. i downloaded the ELDK 4.2 arm iso and installed, at which point i got numerous errors about a missing zlib library. since i already had glibc.i586 installed for other reasons, i just did: # yum install zlib.i586 at which point another attempt at installing ELDK worked fine. at that point, i just did the following for the latest "git pull" of u-boot (the "master" branch"): $ make omap3_beagle_config $ make and the build worked without a single diagnostic. haven't had a chance to flash and try it yet, but the end results: -rwxrwxr-x. 1 rpjday rpjday 702862 2009-08-19 10:45 u-boot -rwxrwxr-x. 1 rpjday rpjday 182500 2009-08-19 10:45 u-boot.bin -rw-rw-r--. 1 rpjday rpjday 174549 2009-08-19 10:45 u-boot.map -rwxrwxr-x. 1 rpjday rpjday 547628 2009-08-19 10:45 u-boot.srec $ file u-boot u-boot: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped $ look reasonable. all in all, pretty simple unless someone wants to point out anything i did wrong. if i screwed up, it's just going on an SD card so there's little chance of me breaking anything. rday -- ============ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] will ELDK 4.2 arm toolchain work for beagleboard u-boot?
i want to use ELDK 4.2 to cross-compile u-boot for my beagleboard, can someone verify that it does that properly? thanks. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] any potential problems with beagle using OMAP34XX macros?
i asked about this on the beagleboard list but i figure i can ask here as well. while the beagleboard is based on the OMAP3530, if you check out board/ti/beagle: $ grep OMAP3 * beagle.c: gd->bd->bi_arch_number = MACH_TYPE_OMAP3_BEAGLE; beagle.c: gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100); beagle.c: struct gpio *gpio5_base = (struct gpio *)OMAP34XX_GPIO5_BASE; beagle.c: struct gpio *gpio6_base = (struct gpio *)OMAP34XX_GPIO6_BASE; beagle.h: "OMAP3 Beagle board", config.mk:# Beagle Board uses OMAP3 (ARM-CortexA8) cpu $ as in, note the references to OMAP34XX macros, not OMAP35XX. and that's because, in include/configs/omap3_beagle.h, all of the references seem to be to OMAP34XX, such as: /* * High Level Configuration Options */ #define CONFIG_ARMCORTEXA8 1 /* This is an ARM V7 CPU core */ #define CONFIG_OMAP 1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX 1 /* which is a 34XX */ #define CONFIG_OMAP3430 1 /* which is in a 3430 */ #define CONFIG_OMAP3_BEAGLE 1 /* working with BEAGLE */ almost all of the macros under include/asm/arch-omap3 are defined in terms of OMAP34XX as well and while that may work fine for now, is there any chance that could cause conflicts down the road? rday -- ================ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] README: Update the list of directories.
Bring the directory listing more into line with current content. Signed-off-by: Robert P. J. Day --- not meant to be comprehensive, just to get things more up-to-date. feel free to tweak as you see fit. diff --git a/README b/README index 2c77687..1e1bccc 100644 --- a/README +++ b/README @@ -138,6 +138,7 @@ U-Boot will always have a patchlevel of "0". Directory Hierarchy: +- api Machine/arch independent API for external apps - boardBoard dependent files - common Misc architecture independent functions - cpu CPU specific files @@ -178,8 +179,8 @@ Directory Hierarchy: - disk Code for disk drive partition handling - doc Documentation (don't expect too much) - drivers Commonly used device drivers -- dtt Digital Thermometer and Thermostat drivers - examples Example code for standalone applications, etc. +- fs Filesystem code (cramfs, ext2, jffs2, etc.) - include Header Files - lib_arm Files generic to ARM architecture - lib_avr32Files generic to AVR32 architecture @@ -187,9 +188,12 @@ Directory Hierarchy: - lib_generic Files generic to all architectures - lib_i386 Files generic to i386architecture - lib_m68k Files generic to m68karchitecture +- lib_microblaze Files generic to microblaze architecture - lib_mips Files generic to MIPSarchitecture - lib_nios Files generic to NIOSarchitecture +- lib_nios2Files generic to NIOS2 architecture - lib_ppc Files generic to PowerPC architecture +- lib_sh Files generic to SH architecture - lib_sparcFiles generic to SPARC architecture - libfdt Library files to support flattened device trees - net Networking code ============ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] README: Give an explicit example of adding a new board.
Explicitly demonstrate an example (BeagleBoard) of what was added/changed to support a new board. Signed-off-by: Robert P. J. Day --- obviously not critical, but it might be useful for readers to see explicitly what constitutes adding support for a new board, file by file. your choice to apply it or not. i *think* i got everything. diff --git a/README b/README index 2c77687..cc701b1 100644 --- a/README +++ b/README @@ -2874,6 +2874,73 @@ steps: [Of course, this last step is much harder than it sounds.] +A real-life example of adding a new board += + + As a working example of adding a new board, consider the files +and directories that were added/changed to support the OMAP3-based +BeagleBoard. + + First, the new files: + + ./board/ti/beagle/ + beagle.c + beagle.h + config.mk + Makefile + ./include/configs/omap3_beagle.h + +Followed by changes to existing files: + + Makefile + + + omap3_beagle_config : unconfig +@$(MKCONFIG) $(@:_config=) arm arm_cortexa8 beagle ti omap3 + + MAKEALL + === + + LIST_ARM_CORTEX_A8="\ +devkit8000 \ +omap3_beagle\ +omap3_overo \ +... + + include/asm-arm-types.h + === + + #ifdef CONFIG_MACH_OMAP3_BEAGLE + # ifdef machine_arch_type + # undef machine_arch_type + # define machine_arch_type __machine_arch_type + # else + # define machine_arch_type MACH_TYPE_OMAP3_BEAGLE + # endif + # define machine_is_omap3_beagle() (machine_arch_type == MACH_TYPE_OMAP3_BEAGLE) + #else + # define machine_is_omap3_beagle() (0) + #endif + + doc/README.omap3 + + + Build + = + + * BeagleBoard: + + make omap3_beagle_config + make + + MAINTAINERS + === + + Dirk Behme + +omap3_beagleARM CORTEX-A8 (OMAP3530 SoC) + + Testing of U-Boot Modifications, Ports to New Hardware, etc.: == rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] README: Give an explicit example of adding a new board.
On Tue, 17 Nov 2009, Dirk Behme wrote: > Robert P. J. Day wrote: > > Explicitly demonstrate an example (BeagleBoard) of what was > > added/changed to support a new board. > > > > Signed-off-by: Robert P. J. Day > > > > --- > > > > obviously not critical, but it might be useful for readers to see > > explicitly what constitutes adding support for a new board, file by > > file. your choice to apply it or not. i *think* i got everything. > > > > > > diff --git a/README b/README > > index 2c77687..cc701b1 100644 > > --- a/README > > +++ b/README > > @@ -2874,6 +2874,73 @@ steps: > > [Of course, this last step is much harder than it sounds.] > > > > > > +A real-life example of adding a new board > > += > > + > > + As a working example of adding a new board, consider the files > > +and directories that were added/changed to support the OMAP3-based > > +BeagleBoard. > > + > > + First, the new files: > > + > > + ./board/ti/beagle/ > > + beagle.c > > + beagle.h > > + config.mk > > + Makefile > > + ./include/configs/omap3_beagle.h > > Most probably the naming convention guys here want some hints about correct > directory and config file names ;) just to be clear, i wasn't trying to give methodical directions for *how* to add a board, just a summary of what the *end result* might be if someone wanted to see them. so, in a sense, i'm not trying to duplicate the instructions for how to add a board, just let people see what it ultimately represents. i just threw this together since *i* was curious about what ended up in the code base to support a single board and i figured others might want a summary, that's all. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] README: Add an example of adding a new board (BeagleBoard).
Show the simple end result of adding an example board (BeagleBoard). Signed-off-by: Robert P. J. Day --- based on dirk's earlier email, i'm emphasizing that this represents only the *end result* of adding BeagleBoard support to U-Boot. anything more involved than that wouldn't really belong in the README. diff --git a/README b/README index 2c77687..3e5bb69 100644 --- a/README +++ b/README @@ -2874,6 +2874,75 @@ steps: [Of course, this last step is much harder than it sounds.] +A real-life example of adding a new board += + + As a working example of the end result of adding a new board, +here's a list of files and directories that were added/changed to +support the OMAP3-based BeagleBoard. Note that these changes don't +represent *how* this board was added, they represent only the +end result. + + First, the new BeagleBoard-related files: + + ./board/ti/beagle/ + beagle.c + beagle.h + config.mk + Makefile + ./include/configs/omap3_beagle.h + +Followed by eventual changes to some existing files: + + Makefile + + + omap3_beagle_config : unconfig +@$(MKCONFIG) $(@:_config=) arm arm_cortexa8 beagle ti omap3 + + MAKEALL + === + + LIST_ARM_CORTEX_A8=" \ +devkit8000 \ +omap3_beagle\ +omap3_overo \ +... + + include/asm-arm/types.h + === + + #ifdef CONFIG_MACH_OMAP3_BEAGLE + # ifdef machine_arch_type + # undef machine_arch_type + # define machine_arch_type __machine_arch_type + # else + # define machine_arch_type MACH_TYPE_OMAP3_BEAGLE + # endif + # define machine_is_omap3_beagle() (machine_arch_type == MACH_TYPE_OMAP3_BEAGLE) + #else + # define machine_is_omap3_beagle() (0) + #endif + + doc/README.omap3 + + + Build + = + + * BeagleBoard: + + make omap3_beagle_config + make + + MAINTAINERS + === + + Dirk Behme + +omap3_beagleARM CORTEX-A8 (OMAP3530 SoC) + + Testing of U-Boot Modifications, Ports to New Hardware, etc.: == rday -- ================ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] README: Add an example of adding a new board.
Show the simple end result of adding an example board (BeagleBoard). Signed-off-by: Robert P. J. Day --- based on dirk's earlier email, i'm emphasizing that this represents only the *end result* of adding BeagleBoard support to U-Boot. anything more involved than that wouldn't really belong in the README and would more properly be described in, say, an ARM porting guide. diff --git a/README b/README index 2c77687..3e5bb69 100644 --- a/README +++ b/README @@ -2874,6 +2874,75 @@ steps: [Of course, this last step is much harder than it sounds.] +A real-life example of adding a new board += + + As a working example of the end result of adding a new board, +here's a list of files and directories that were added/changed to +support the OMAP3-based BeagleBoard. Note that these changes don't +represent *how* this board was added, they represent only the +end result. + + First, the new BeagleBoard-related files: + + ./board/ti/beagle/ + beagle.c + beagle.h + config.mk + Makefile + ./include/configs/omap3_beagle.h + +Followed by eventual changes to some existing files: + + Makefile + + + omap3_beagle_config : unconfig +@$(MKCONFIG) $(@:_config=) arm arm_cortexa8 beagle ti omap3 + + MAKEALL + === + + LIST_ARM_CORTEX_A8=" \ +devkit8000 \ +omap3_beagle\ +omap3_overo \ +... + + include/asm-arm/types.h + === + + #ifdef CONFIG_MACH_OMAP3_BEAGLE + # ifdef machine_arch_type + # undef machine_arch_type + # define machine_arch_type __machine_arch_type + # else + # define machine_arch_type MACH_TYPE_OMAP3_BEAGLE + # endif + # define machine_is_omap3_beagle() (machine_arch_type == MACH_TYPE_OMAP3_BEAGLE) + #else + # define machine_is_omap3_beagle() (0) + #endif + + doc/README.omap3 + + + Build + = + + * BeagleBoard: + + make omap3_beagle_config + make + + MAINTAINERS + === + + Dirk Behme + +omap3_beagleARM CORTEX-A8 (OMAP3530 SoC) + + Testing of U-Boot Modifications, Ports to New Hardware, etc.: == rday -- ================ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] help: Correct syntax of nandecc help output.
"nandecc" help output should not reproduce the command name, nor have a trailing newline. Signed-off-by: Robert P. J. Day --- compiled, loaded and run to verify correct output. diff --git a/cpu/arm_cortexa8/omap3/board.c b/cpu/arm_cortexa8/omap3/board.c index dd2c940..2aa69b3 100644 --- a/cpu/arm_cortexa8/omap3/board.c +++ b/cpu/arm_cortexa8/omap3/board.c @@ -328,7 +328,7 @@ usage: U_BOOT_CMD( nandecc, 2, 1, do_switch_ecc, - "nandecc - switch OMAP3 NAND ECC calculation algorithm\n", + "switch OMAP3 NAND ECC calculation algorithm", "[hw/sw] - Switch between NAND hardware (hw) or software (sw) ecc algorithm" ); ================ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] README: Add an example of adding a new board.
On Tue, 17 Nov 2009, Wolfgang Denk wrote: > Dear "Robert P. J. Day", > > In message you wrote: > > > > Show the simple end result of adding an example board (BeagleBoard). > > > > Signed-off-by: Robert P. J. Day > > This text is still inconsistent and not good enough as an example. > > > based on dirk's earlier email, i'm emphasizing that this > > represents only the *end result* of adding BeagleBoard support to > > U-Boot. anything more involved than that wouldn't really belong in > > the README and would more properly be described in, say, an ARM > > porting guide. > > How about adding an entry in the U-Boot wiki? ok, that's fair. rday p.s. is there a "trivial" patch email address for simple things like typoes, just to keep this main list for more important stuff? Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] is CONFIG_DATAFLASH_MMC_SELECT actually being used anywhere?
never afraid to embarrass myself, is the config option CONFIG_DATAFLASH_MMC_SELECT actually doing anything useful? $ grep -r MMC_SELECT * board/atmel/at91rm9200dk/Makefile:COBJS-$(CONFIG_DATAFLASH_MMC_SELECT) += mux.o board/atmel/at91rm9200ek/Makefile:COBJS-$(CONFIG_DATAFLASH_MMC_SELECT) += mux.o CHANGELOG:at91: rename DATAFLASH_MMC_SELECT to CONFIG_DATAFLASH_MMC_SELECT common/Makefile:COBJS-$(CONFIG_DATAFLASH_MMC_SELECT) += cmd_dataflash_mmc_mux.o include/at45.h:#ifdef CONFIG_DATAFLASH_MMC_SELECT $ i can see the commit that did a rename: commit 90a92a708d5180a20d600ba0fc2352ec76dc3829 Author: Jean-Christophe PLAGNIOL-VILLARD Date: Fri Mar 27 23:26:42 2009 +0100 at91: rename DATAFLASH_MMC_SELECT to CONFIG_DATAFLASH_MMC_SELECT Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD but unless *someone* defines that macro, is it doing anything useful? or am i just confused? rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] why is the compilation of cmd_pcmcia.c hardcoded?
i'm curious as to why common/Makefile hardcodes the compilation of
cmd_pcmcia.c thusly:
COBJS-y += cmd_pcmcia.o
since i'm interested in building for a beagleboard, i have no interest
in PCMCIA support, yet that source file will be compiled for me, even
though the selection macro CONFIG_CMD_PCMCIA does exist and is defined
by a number of other board configurations.
what seems stranger is that, even though that config macro exists,
it isn't used in the Makefile but *is* tested in the source file
itself to determine whether the "pinit" command will be compiled:
=
#if defined(CONFIG_CMD_PCMCIA)
extern int pcmcia_on (void);
extern int pcmcia_off (void);
int do_pinit (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
...
}
U_BOOT_CMD(
pinit, 2, 0, do_pinit,
"PCMCIA sub-system",
"on - power on PCMCIA socket\n"
"pinit off - power off PCMCIA socket"
);
#endif
=
so the "pinit" command *won't* be compiled into my image, but the
remainder of that file will still be compiled. if the rest of that
file truly needs to be built for every board, would it not make more
sense to break the pinit code into a separate file, and have the
Makefile look something like:
ifdef CONFIG_CMD_PCMCIA
COBJS-$(CONFIG_CMD_PCMCIA) += cmd_pcmcia.o
endif
or is there something else happening there that i'm missing?
rday
p.s. based on the obvious naming convention of those files, i would
have imagined a file by the name of cmd_pinit.c.
--
============
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Condense some lines in common/Makefile for readability.
Collect object files corresponding to the same CONFIG variable on the same line for better readability. Signed-off-by: Robert P. J. Day --- clearly no *functional* difference but it follows the standard set out in the rest of the file. compile tested for a beagle, for what it's worth. diff --git a/common/Makefile b/common/Makefile index 3781738..c471f38 100644 --- a/common/Makefile +++ b/common/Makefile @@ -50,15 +50,12 @@ COBJS-y += cmd_nvedit.o # environment COBJS-y += env_common.o COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o +COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o env_eeprom.o COBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o +COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o env_flash.o +COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o env_nvram.o COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Condense some lines in common/Makefile for readability.
Collect object files corresponding to the same CONFIG variable on the same line for better readability. Signed-off-by: Robert P. J. Day --- clearly no *functional* difference but it follows the standard set out in the rest of the file. compile tested for a beagle, for what it's worth. and the slight change to this version is that a duplicate and redundant check for ENV_IS_IN_EEPROM further down the file was also removed. diff --git a/common/Makefile b/common/Makefile index 3781738..b3d66aa 100644 --- a/common/Makefile +++ b/common/Makefile @@ -50,15 +50,12 @@ COBJS-y += cmd_nvedit.o # environment COBJS-y += env_common.o COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o +COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o env_eeprom.o COBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o +COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o env_flash.o +COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o env_nvram.o COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o @@ -84,7 +81,6 @@ COBJS-$(CONFIG_CMD_DIAG) += cmd_diag.o endif COBJS-$(CONFIG_CMD_DISPLAY) += cmd_display.o COBJS-$(CONFIG_CMD_DTT) += cmd_dtt.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += cmd_eeprom.o COBJS-$(CONFIG_CMD_EEPROM) += cmd_eeprom.o COBJS-$(CONFIG_CMD_ELF) += cmd_elf.o COBJS-$(CONFIG_CMD_EXT2) += cmd_ext2.o Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] difference between V_PROMPT and CONFIG_SYS_PROMPT?
another beginner-level question, i'm sure, but what's the distinction between V_PROMPT and CONFIG_SYS_PROMPT for customizing the u-boot prompt? based on the output from a straightforward grep, it appears that every example of customizing the prompt has the form: #define V_PROMPT"OMAP3_EVM # " ... snip ... #define CONFIG_SYS_PROMPT V_PROMPT as in, V_PROMPT is set, for no other reason than to subsequently set CONFIG_SYS_PROMPT a few lines later, at which point V_PROMPT never seems to be used again. is this just a historical holdover? any reason why CONFIG_SYS_PROMPT can't be set directly and V_PROMPT ignored/removed? rday -- ============ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Remove entirely superfluous preprocessor tests from cmd_*.c files.
A small number of common/cmd_*.c files contain preprocessor tests that are apparently superfluous since those same tests are used in the Makefile to control the compilation of those files. Those tests are clearly redundant as long as they surround the entirety of the source in those files. Signed-off-by: Robert P. J. Day --- based on simple visual inspection, i can't see how those tests could make any difference so they might as well be tossed. diff --git a/common/cmd_cache.c b/common/cmd_cache.c index 0dfa336..1202258 100644 --- a/common/cmd_cache.c +++ b/common/cmd_cache.c @@ -27,8 +27,6 @@ #include #include -#if defined(CONFIG_CMD_CACHE) - static int on_off (const char *); int do_icache ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) @@ -108,5 +106,3 @@ U_BOOT_CMD( "[on, off]\n" "- enable or disable data (writethrough) cache" ); - -#endif diff --git a/common/cmd_license.c b/common/cmd_license.c index 141215b..c6f272a 100644 --- a/common/cmd_license.c +++ b/common/cmd_license.c @@ -23,8 +23,6 @@ #include -#if defined(CONFIG_CMD_LICENSE) - /* COPYING is currently 15951 bytes in size */ #define LICENSE_MAX20480 @@ -56,5 +54,3 @@ U_BOOT_CMD(license, 1, 1, do_license, "print GPL license text", "" ); - -#endif /* CONFIG_CMD_LICENSE */ diff --git a/common/cmd_mgdisk.c b/common/cmd_mgdisk.c index aadc335..3ba62f6 100644 --- a/common/cmd_mgdisk.c +++ b/common/cmd_mgdisk.c @@ -24,8 +24,6 @@ #include #include -#if defined (CONFIG_CMD_MG_DISK) - #include int do_mg_disk_cmd (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) @@ -72,5 +70,3 @@ U_BOOT_CMD( "- sector read : mgd readsec [sector] [to] [counts]\n" "- sector write : mgd writesec [from] [sector] [counts]" ); - -#endif ============ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Remove entirely superfluous preprocessor tests from cmd_*.c files.
On Thu, 19 Nov 2009, Peter Tyser wrote: > > > -#if defined(CONFIG_CMD_LICENSE) > > - > > /* COPYING is currently 15951 bytes in size */ > > #define LICENSE_MAX20480 > > > > @@ -56,5 +54,3 @@ U_BOOT_CMD(license, 1, 1, do_license, > > "print GPL license text", > > "" > > ); > > - > > -#endif /* CONFIG_CMD_LICENSE */ > > Hi Robert, > Thanks for the cleanup. The above change was recently submitted, but > hasn't been applied yet. Search for "cmd_license: Remove unneeded > #ifdef CONFIG_CMD_LICENSE". Could you remove the above chunk from your > patch and resubmit so as to prevent a conflict when Wolfgang applies > both patches? okey dokey, coming right up. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Remove entirely superfluous preprocessor tests from some cmd_*.c files.
A small number of common/cmd_*.c files contain preprocessor tests that are apparently superfluous since those same tests are used in the Makefile to control the compilation of those files. Those tests are clearly redundant as long as they surround the entirety of the source in those files. Signed-off-by: Robert P. J. Day --- revision of earlier patch, dropping change to cmd_license.c since that's already been submitted. there *are* at least a couple more files like this but they'll require slightly different tweaking so i'm doing those separately. diff --git a/common/cmd_cache.c b/common/cmd_cache.c index 0dfa336..1202258 100644 --- a/common/cmd_cache.c +++ b/common/cmd_cache.c @@ -27,8 +27,6 @@ #include #include -#if defined(CONFIG_CMD_CACHE) - static int on_off (const char *); int do_icache ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) @@ -108,5 +106,3 @@ U_BOOT_CMD( "[on, off]\n" "- enable or disable data (writethrough) cache" ); - -#endif diff --git a/common/cmd_mgdisk.c b/common/cmd_mgdisk.c index aadc335..3ba62f6 100644 --- a/common/cmd_mgdisk.c +++ b/common/cmd_mgdisk.c @@ -24,8 +24,6 @@ #include #include -#if defined (CONFIG_CMD_MG_DISK) - #include int do_mg_disk_cmd (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) @@ -72,5 +70,3 @@ U_BOOT_CMD( "- sector read : mgd readsec [sector] [to] [counts]\n" "- sector write : mgd writesec [from] [sector] [counts]" ); - -#endif ================ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Move preprocessor test for cmd_nand.c to Makefile
Move the CONFIG_CMD_NAND preprocessor test out of common/cmd_nand.c and into the Makefile for consistency with other commands. Signed-off-by: Robert P. J. Day --- AFAICT, this doesn't affect any functionality, right? diff --git a/common/Makefile b/common/Makefile index 3781738..b8c596c 100644 --- a/common/Makefile +++ b/common/Makefile @@ -116,7 +116,7 @@ COBJS-$(CONFIG_CMD_MISC) += cmd_misc.o COBJS-$(CONFIG_CMD_MMC) += cmd_mmc.o COBJS-$(CONFIG_MP) += cmd_mp.o COBJS-$(CONFIG_CMD_MTDPARTS) += cmd_mtdparts.o -COBJS-y += cmd_nand.o +COBJS-$(CONFIG_CMD_NAND) += cmd_nand.o COBJS-$(CONFIG_CMD_NET) += cmd_net.o COBJS-$(CONFIG_CMD_ONENAND) += cmd_onenand.o COBJS-$(CONFIG_CMD_OTP) += cmd_otp.o diff --git a/common/cmd_nand.c b/common/cmd_nand.c index 158a55f..1b17159 100644 --- a/common/cmd_nand.c +++ b/common/cmd_nand.c @@ -19,8 +19,6 @@ #include #include -#if defined(CONFIG_CMD_NAND) - #include #include #include @@ -686,4 +684,3 @@ U_BOOT_CMD(nboot, 4, 1, do_nandboot, "boot from NAND device", "[partition] | [[[loadAddr] dev] offset]" ); -#endif ============ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Move the preprocessor test for building flash.c to the Makefile.
Move the preprocessor test of CONFIG_SYS_NO_FLASH out of flash.c and back to the Makefile, for readability. Signed-off-by: Robert P. J. Day --- this one is a little uglier since it adds an "#ifndef" check to the Makefile, but i still consider this to be more readable since it's potentially misleading to have a hard-coded build of a file in the Makefile, only to have to go that file to notice that a subsequent preprocessor check takes the file out of play. except in weird circumstances, tests like that should be in the Makefile. i don't think there's a lot of this left. diff --git a/common/Makefile b/common/Makefile index 3781738..69629f5 100644 --- a/common/Makefile +++ b/common/Makefile @@ -152,7 +152,9 @@ COBJS-$(CONFIG_VFD) += cmd_vfd.o COBJS-$(CONFIG_DDR_SPD) += ddr_spd.o COBJS-$(CONFIG_HWCONFIG) += hwconfig.o COBJS-$(CONFIG_CONSOLE_MUX) += iomux.o +#ifndef CONFIG_SYS_NO_FLASH COBJS-y += flash.o +#endif COBJS-$(CONFIG_CMD_KGDB) += kgdb.o COBJS-$(CONFIG_KALLSYMS) += kallsyms.o COBJS-$(CONFIG_LCD) += lcd.o diff --git a/common/flash.c b/common/flash.c index eb4b2f5..f5da566 100644 --- a/common/flash.c +++ b/common/flash.c @@ -26,8 +26,6 @@ #include #include -#if !defined(CONFIG_SYS_NO_FLASH) - extern flash_info_t flash_info[]; /* info for FLASH chips */ /*--- @@ -222,7 +220,3 @@ void flash_perror (int err) break; } } - -/*--- - */ -#endif /* !CONFIG_SYS_NO_FLASH */ ============ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move the preprocessor test for building flash.c to the Makefile.
On Thu, 19 Nov 2009, Mike Frysinger wrote: > On Thursday 19 November 2009 12:38:42 Robert P. J. Day wrote: > > --- a/common/Makefile > > +++ b/common/Makefile > > @@ -152,7 +152,9 @@ COBJS-$(CONFIG_VFD) += cmd_vfd.o > > COBJS-$(CONFIG_DDR_SPD) += ddr_spd.o > > COBJS-$(CONFIG_HWCONFIG) += hwconfig.o > > COBJS-$(CONFIG_CONSOLE_MUX) += iomux.o > > +#ifndef CONFIG_SYS_NO_FLASH > > COBJS-y += flash.o > > +#endif > > COBJS-$(CONFIG_CMD_KGDB) += kgdb.o > > COBJS-$(CONFIG_KALLSYMS) += kallsyms.o > > COBJS-$(CONFIG_LCD) += lcd.o > > me thinks you did not test this and/or you dont know how Makefile's work > and/or you forgot to remove debug comments. > > regardless, obvious NACK > -mike oh, crap, that's what i get for getting lazy and not paying attention. sorry. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] BeagleBoard: Add a comment explaining the use of "OMAP34XX" macros.
Make it clear to a reader that the user of OMAP34XX macros in the (OMAP 3530-based) beagle config file is just fine. Signed-off-by: Robert P. J. Day --- i'll let dirk be the judge as to whether this is worth adding, or if he'd prefer a different phrasing. diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 19a5ec9..9a03587 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -30,6 +30,9 @@ /* * High Level Configuration Options + * + * Note that, although the BeagleBoard incorporates an OMAP 3530, + * it's currently still valid to use OMAP34XX preprocessor values. */ #define CONFIG_ARMCORTEXA8 1 /* This is an ARM V7 CPU core */ #define CONFIG_OMAP1 /* in a TI OMAP core */ ============ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Remove superfluous use of V_PROMPT macros in config files.
Remove the use of the V_PROMPT macro in a number of config files, whose only use seems to be to subsequently set the CONFIG_SYS_PROMPT macro, after which it's never used again. Signed-off-by: Robert P. J. Day --- as far as i can tell, there's no compelling reason to hang onto V_PROMPT when CONFIG_SYS_PROMPT is what's being used in the end. this patch removes all of that. diff --git a/include/configs/apollon.h b/include/configs/apollon.h index 575f60e..891b3ab 100644 --- a/include/configs/apollon.h +++ b/include/configs/apollon.h @@ -183,10 +183,8 @@ /* * Miscellaneous configurable options */ -#defineV_PROMPT"Apollon # " - #defineCONFIG_SYS_LONGHELP /* undef to save memory */ -#defineCONFIG_SYS_PROMPT V_PROMPT +#defineCONFIG_SYS_PROMPT "Apollon # " #defineCONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ /* Print Buffer Size */ #defineCONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE+sizeof(CONFIG_SYS_PROMPT)+16) diff --git a/include/configs/omap2420h4.h b/include/configs/omap2420h4.h index 9c18842..9c6b6e5 100644 --- a/include/configs/omap2420h4.h +++ b/include/configs/omap2420h4.h @@ -163,14 +163,12 @@ /* * Miscellaneous configurable options */ +#define CONFIG_SYS_LONGHELP /* undef to save memory */ #ifdef CONFIG_APTIX -#define V_PROMPT "OMAP2420 Aptix # " +# define CONFIG_SYS_PROMPT "OMAP2420 Aptix # " #else -#define V_PROMPT "OMAP242x H4 # " +# define CONFIG_SYS_PROMPT "OMAP242x H4 # " #endif - -#define CONFIG_SYS_LONGHELP /* undef to save memory */ -#define CONFIG_SYS_PROMPT V_PROMPT #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE+sizeof(CONFIG_SYS_PROMPT)+16) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 19a5ec9..7fad93b 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -213,12 +213,10 @@ /* * Miscellaneous configurable options */ -#define V_PROMPT "OMAP3 beagleboard.org # " - #define CONFIG_SYS_LONGHELP/* undef to save memory */ #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ #define CONFIG_SYS_PROMPT_HUSH_PS2 "> " -#define CONFIG_SYS_PROMPT V_PROMPT +#define CONFIG_SYS_PROMPT "OMAP3 beagleboard.org # " #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index a5514ae..c181852 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -194,12 +194,10 @@ /* * Miscellaneous configurable options */ -#define V_PROMPT "OMAP3_EVM # " - #define CONFIG_SYS_LONGHELP/* undef to save memory */ #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ #define CONFIG_SYS_PROMPT_HUSH_PS2 "> " -#define CONFIG_SYS_PROMPT V_PROMPT +#define CONFIG_SYS_PROMPT "OMAP3_EVM # " #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index ffb515d..745d418 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -199,12 +199,10 @@ /* * Miscellaneous configurable options */ -#define V_PROMPT "Overo # " - #define CONFIG_SYS_LONGHELP/* undef to save memory */ #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ #define CONFIG_SYS_PROMPT_HUSH_PS2 "> " -#define CONFIG_SYS_PROMPT V_PROMPT +#define CONFIG_SYS_PROMPT "Overo # " #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ diff --git a/include/configs/omap3_pandora.h b/include/configs/omap3_pandora.h index 6f21af3..d2786c0 100644 --- a/include/configs/omap3_pandora.h +++ b/include/configs/omap3_pandora.h @@ -191,12 +191,10 @@ /* * Miscellaneous configurable options */ -#define V_PROMPT "Pandora # " - #define CONFIG_SYS_LONGHELP/* undef to save memory */ #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ #define CONFIG_SYS_PROMPT_HUSH_PS2 "> " -#define CONFIG_SYS_PROMPT V_PROMPT +#define CONFIG_SYS_PROMPT &quo
Re: [U-Boot] [PATCH] BeagleBoard: Add a comment explaining the use of "OMAP34XX" macros.
On Fri, 20 Nov 2009, M?ns Rullg?rd wrote: > "Robert P. J. Day" writes: > > > Make it clear to a reader that the user of OMAP34XX macros in the > > (OMAP 3530-based) beagle config file is just fine. > > > > Signed-off-by: Robert P. J. Day > > > > --- > > > > i'll let dirk be the judge as to whether this is worth adding, or if > > he'd prefer a different phrasing. > > > > diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h > > index 19a5ec9..9a03587 100644 > > --- a/include/configs/omap3_beagle.h > > +++ b/include/configs/omap3_beagle.h > > @@ -30,6 +30,9 @@ > > > > /* > > * High Level Configuration Options > > + * > > + * Note that, although the BeagleBoard incorporates an OMAP 3530, > > + * it's currently still valid to use OMAP34XX preprocessor values. > > */ > > #define CONFIG_ARMCORTEXA8 1 /* This is an ARM V7 CPU core */ > > #define CONFIG_OMAP1 /* in a TI OMAP core */ > > Since 34xx and 35xx are in fact exactly the same silicon, saying it is > "currently" valid seems a bit odd. This sort of implies a planned > change. ok, i can rephrase that. i was working off of a post by dirk a couple days ago where he seemed to be suggesting that the door was open for some divergence down the road, but maybe i just misread. will fix shortly. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] BeagleBoard: Add a comment explaining the use of "OMAP34XX" macros.
Make it clear to the reader that, since OMAP 34XX and 35XX are the same silicon, the BeagleBoard can use the OMAP34XX macros. Signed-off-by: Robert P. J. Day --- diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 19a5ec9..59b7edc 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -30,6 +30,9 @@ /* * High Level Configuration Options + * + * Note that since OMAP 34XX and 35XX are the same silicon, the + * OMAP 3530-based BeagleBoard can use the OMAP34XX macros. */ #define CONFIG_ARMCORTEXA8 1 /* This is an ARM V7 CPU core */ #define CONFIG_OMAP1 /* in a TI OMAP core */ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] BeagleBoard: Add a comment explaining the use of "OMAP34XX" macros.
On Thu, 19 Nov 2009, Nishanth Menon wrote: > I agree - I do not think there are any such plans. NAK to the patch. > Regards, > Nishanth Menon fair enough. but i think a two-line comment is still useful for people new to ARM who know the beagle is a 3530 and wonder why all the macros use 34XX. rday -- ==== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] confused ... how do some CONFIG settings "implicitly" set others?
reading http://www.denx.de/wiki/view/DULG/UBootSplashScreen, and i see: "To enable splash screen support, you have to add a "#define CONFIG_SPLASH_SCREEN" to your board configuration file. This will also implicitly enable U-Boot Bitmap Support." "implicitly"? how does that work? from what i can see in define2mk.sed, the transformation is straightforward and there are no dependencies or selects as in the kernel Kconfig structure. how does setting splash screen implicitly set bitmap support? what am i missing? rday -- ================ Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] BeagleBoard: Add a comment explaining the use of "OMAP34XX" macros.
On Fri, 20 Nov 2009, Tom wrote: > Robert P. J. Day wrote: > > Make it clear to the reader that, since OMAP 34XX and 35XX are the > > same silicon, the BeagleBoard can use the OMAP34XX macros. > > > > Signed-off-by: Robert P. J. Day > > > > --- > > > > diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h > > index 19a5ec9..59b7edc 100644 > > --- a/include/configs/omap3_beagle.h > > +++ b/include/configs/omap3_beagle.h > > @@ -30,6 +30,9 @@ > > > > /* > > * High Level Configuration Options > > + * > > + * Note that since OMAP 34XX and 35XX are the same silicon, the > > + * OMAP 3530-based BeagleBoard can use the OMAP34XX macros. > > I think this comment would be appropriate in the omap3 readme. > > > Perhaps the omap3 specific defines could be explained in > greater detail there. > certainly, there's nothing amiss about a longer explanation in the README file. but the rationale for the above was just a couple lines to prevent any confusion on the part of anyone who wanted to peruse the beagle config file, nothing more. it wasn't meant to be a big deal. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] possible typo in beagle identification?
at the risk of embarrassing myself yet again, am i misreading the macro that defines and tests for a beagle board? $ grep -rw CONFIG.*OMAP3.*BEAGLE * include/configs/omap3_beagle.h:#define CONFIG_OMAP3_BEAGLE 1 /* working with BEAGLE */ include/asm-arm/mach-types.h:#ifdef CONFIG_MACH_OMAP3_BEAGLE $ in short, the config file defines CONFIG_OMAP3_BEAGLE, while the mach-types.h file *tests* for CONFIG_MACH_OMAP3_BEAGLE. how exactly does that work? the more i read, the confuseder i get. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
