[U-Boot] [PATCH] [PoC] basic kbuild output support
I know at first blush this isn't going to be supported, but it's just
a PoC that things are (mostly) possible without much effort.
Signed-off-by: Mike Frysinger
---
Makefile | 54 ++---
common/kgdb.c| 52 +--
config.mk| 30 ++
examples/api/Makefile| 11 +---
examples/standalone/Makefile |9 --
tools/Makefile | 48 +
6 files changed, 121 insertions(+), 83 deletions(-)
diff --git a/Makefile b/Makefile
index 43a9145..407bf22 100644
--- a/Makefile
+++ b/Makefile
@@ -53,18 +53,12 @@ SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
export HOSTARCH HOSTOS SHELL
+MAKEFLAGS += --no-print-directory
+
# Deal with colliding definitions from tcsh etc.
VENDOR=
#
-# Allow for silent builds
-ifeq (,$(findstring s,$(MAKEFLAGS)))
-XECHO = echo
-else
-XECHO = :
-endif
-
-#
#
# U-boot build supports producing a object files to the separate external
# directory. Two use cases are supported:
@@ -327,25 +321,31 @@ ALL += $(obj)u-boot.srec $(obj)u-boot.bin
$(obj)System.map $(U_BOOT_NAND) $(U_BO
all: $(ALL)
$(obj)u-boot.hex: $(obj)u-boot
- $(OBJCOPY) ${OBJCFLAGS} -O ihex $< $@
+ @$(XECHO) " OBJCOPY $@"
+ $(Q)$(OBJCOPY) ${OBJCFLAGS} -O ihex $< $@
$(obj)u-boot.srec: $(obj)u-boot
- $(OBJCOPY) -O srec $< $@
+ @$(XECHO) " OBJCOPY $@"
+ $(Q)$(OBJCOPY) -O srec $< $@
$(obj)u-boot.bin: $(obj)u-boot
- $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
+ @$(XECHO) " OBJCOPY $@"
+ $(Q)$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(BOARD_SIZE_CHECK)
$(obj)u-boot.ldr: $(obj)u-boot
- $(CREATE_LDR_ENV)
- $(LDR) -T $(CONFIG_BFIN_CPU) -c $@ $< $(LDR_FLAGS)
+ @$(XECHO) " LDR $@"
+ $(Q)$(CREATE_LDR_ENV)
+ $(Q)$(LDR) -T $(CONFIG_BFIN_CPU) -c $@ $< $(LDR_FLAGS)
$(BOARD_SIZE_CHECK)
$(obj)u-boot.ldr.hex: $(obj)u-boot.ldr
- $(OBJCOPY) ${OBJCFLAGS} -O ihex $< $@ -I binary
+ @$(XECHO) " OBJCOPY $@"
+ $(Q)$(OBJCOPY) ${OBJCFLAGS} -O ihex $< $@ -I binary
$(obj)u-boot.ldr.srec: $(obj)u-boot.ldr
- $(OBJCOPY) ${OBJCFLAGS} -O srec $< $@ -I binary
+ @$(XECHO) " OBJCOPY $@"
+ $(Q)$(OBJCOPY) ${OBJCFLAGS} -O srec $< $@ -I binary
$(obj)u-boot.img: $(obj)u-boot.bin
$(obj)tools/mkimage -A $(ARCH) -T firmware -C none \
@@ -376,29 +376,32 @@ GEN_UBOOT = \
-Map u-boot.map -o u-boot
$(obj)u-boot: depend \
$(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT)
$(obj)u-boot.lds
- $(GEN_UBOOT)
+ @$(XECHO) " LD $@"
+ $(Q)$(GEN_UBOOT)
ifeq ($(CONFIG_KALLSYMS),y)
- smap=`$(call SYSTEM_MAP,u-boot) | \
+ @$(XECHO) " SYMMAP $@"
+ $(Q)smap=`$(call SYSTEM_MAP,u-boot) | \
awk '$$2 ~ /[tTwW]/ {printf $$1 $$3 "000"}'` ; \
$(CC) $(CFLAGS) -DSYSTEM_MAP="\"$${smap}\"" \
-c common/system_map.c -o $(obj)common/system_map.o
- $(GEN_UBOOT) $(obj)common/system_map.o
+ @$(XECHO) " LD $@"
+ $(Q)$(GEN_UBOOT) $(obj)common/system_map.o
endif
$(OBJS): depend
- $(MAKE) -C $(CPUDIR) $(if $(REMOTE_BUILD),$@,$(notdir $@))
+ $(Q)$(MAKE) -C $(CPUDIR) $(if $(REMOTE_BUILD),$@,$(notdir $@))
$(LIBS): depend $(SUBDIRS)
- $(MAKE) -C $(dir $(subst $(obj),,$@))
+ $(Q)$(MAKE) -C $(dir $(subst $(obj),,$@))
$(LIBBOARD): depend $(LIBS)
- $(MAKE) -C $(dir $(subst $(obj),,$@))
+ $(Q)$(MAKE) -C $(dir $(subst $(obj),,$@))
$(SUBDIRS):depend
- $(MAKE) -C $@ all
+ $(Q)$(MAKE) -C $@ all
$(LDSCRIPT): depend
- $(MAKE) -C $(dir $@) $(notdir $@)
+ $(Q)$(MAKE) -C $(dir $@) $(notdir $@)
# The linker script lacks proper dependency information atm, so force it
# to be regenerated on every link. This shouldn't be to big of an issue
@@ -407,7 +410,8 @@ $(LDSCRIPT):depend
# board config file ...
.PHONY: $(obj)u-boot.lds
$(obj)u-boot.lds: $(LDSCRIPT)
- $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^
>$@
+ @$(XECHO) " CPP $@"
+ $(Q)$(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P -
<$^ >$@
$(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(MAKE) -C nand
[U-Boot] [PATCH] simplify clobber behavior with out-of-tree builds
The targets/prerequisites are the same here; the rules only differ in the recipes. So move the if logic protection to the recipe part so we can keep the rest the same. Signed-off-by: Mike Frysinger --- Makefile |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index a368f56..43a9145 100644 --- a/Makefile +++ b/Makefile @@ -1158,12 +1158,9 @@ clobber: clean @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name "*" -type l -print | xargs rm -f @[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name "*" -type l -print | xargs rm -f -ifeq ($(OBJTREE),$(SRCTREE)) -mrproper \ -distclean: clobber unconfig -else mrproper \ distclean: clobber unconfig +ifneq ($(OBJTREE),$(SRCTREE)) rm -rf $(obj)* endif -- 1.7.5.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: convert to partial linking
Looks like this was missed during the conversion to partial linking. Signed-off-by: Mike Frysinger --- Makefile |2 +- drivers/usb/eth/Makefile |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index bb1958a..a368f56 100644 --- a/Makefile +++ b/Makefile @@ -236,7 +236,7 @@ endif LIBS += drivers/rtc/librtc.o LIBS += drivers/serial/libserial.o LIBS += drivers/twserial/libtws.o -LIBS += drivers/usb/eth/libusb_eth.a +LIBS += drivers/usb/eth/libusb_eth.o LIBS += drivers/usb/gadget/libusb_gadget.o LIBS += drivers/usb/host/libusb_host.o LIBS += drivers/usb/musb/libusb_musb.o diff --git a/drivers/usb/eth/Makefile b/drivers/usb/eth/Makefile index 6a5f25a..a8e9eff 100644 --- a/drivers/usb/eth/Makefile +++ b/drivers/usb/eth/Makefile @@ -21,7 +21,7 @@ include $(TOPDIR)/config.mk -LIB:= $(obj)libusb_eth.a +LIB:= $(obj)libusb_eth.o # new USB host ethernet layer dependencies COBJS-$(CONFIG_USB_HOST_ETHER) += usb_ether.o @@ -36,7 +36,7 @@ OBJS := $(addprefix $(obj),$(COBJS)) all: $(LIB) $(LIB):$(obj).depend $(OBJS) - $(AR) $(ARFLAGS) $@ $(OBJS) + $(call cmd_link_o_target, $(OBJS)) # -- 1.7.5.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] nios2: move generic config to boards.cfg
I can't build test this, but just looking at the config files written and it seems OK ... Signed-off-by: Mike Frysinger --- MAKEALL|4 +--- Makefile | 14 -- boards.cfg |1 + 3 files changed, 2 insertions(+), 17 deletions(-) diff --git a/MAKEALL b/MAKEALL index 13cd05a..8800394 100755 --- a/MAKEALL +++ b/MAKEALL @@ -562,9 +562,7 @@ LIST_x86="$(boards_by_arch i386)" ## Nios-II Systems # -LIST_nios2="$(boards_by_arch nios2) - nios2-generic \ -" +LIST_nios2="$(boards_by_arch nios2)" # ## MicroBlaze Systems diff --git a/Makefile b/Makefile index 6f17e3b..bb1958a 100644 --- a/Makefile +++ b/Makefile @@ -1099,20 +1099,6 @@ smdk6400_config : unconfig @$(MKCONFIG) smdk6400 arm arm1176 smdk6400 samsung s3c64xx @echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk -# -# Nios -# - -# -## Nios-II -# - -# nios2 generic boards -NIOS2_GENERIC = nios2-generic - -$(NIOS2_GENERIC:%=%_config) : unconfig - @$(MKCONFIG) $@ nios2 nios2 nios2-generic altera - # # diff --git a/boards.cfg b/boards.cfg index 2568e45..2e8c983 100644 --- a/boards.cfg +++ b/boards.cfg @@ -247,6 +247,7 @@ vct_platinumavc mipsmipsvct microna vct_platinumavc_smallmipsmipsvct micronas - vct:VCT_PLATINUMAVC,VCT_SMALL_IMAGE vct_platinumavc_onenand mipsmipsvct micronas - vct:VCT_PLATINUMAVC,VCT_ONENAND vct_platinumavc_onenand_small mips mipsvct micronas - vct:VCT_PLATINUMAVC,VCT_ONENAND,VCT_SMALL_IMAGE +nios2-genericnios2 nios2 nios2-generic altera PCI5441 nios2 nios2 pci5441 psyent PK1C20 nios2 nios2 pk1c20 psyent EVB64260 powerpc 74xx_7xxevb64260- - EVB64260 -- 1.7.5.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reg. CFI flash_init and hardware write protected devices
On Fri, Jun 24, 2011 at 10:26 PM, Wolfgang Denk wrote:
> Dear Frank,
>
> In message you wrote:
>>
>> > Difficult to speculate - I don't know your hardware (eventually you
>> > have two 16 bit flash chips in parallel to build a 32 bit bus, and
>> > have to double the chip's erase block size?), and I don;t know how you
>> > created the JFFS2 file system.
> ...
>> factory default version). 16 bits databus and each sector is 64k
>> words, ie. 128k bytes. I created the jffs2 images using ELDKs
>> mkfs.jffs2. Thanks for providing me this tool :)
>
> You need to provide the correct parameters to mkfs.jffs2...
>
Of course, but I don't see how changing from CFI to raw memory
accesses on target change the way the jffs2 image should be created.
What didn't I understand?
I'm currently using:
mkfs.jss2 -U -b -d /${input} -e 0x2 -o ${output}
>> No, not sure. I've got two reasons for staying with JFFS2. 1) We
>> normally don't write to flash except when upgrading, so flash
>> performance/duration isn't very critical 2) I discovered UBIFS after I
>
> Hm... JFFS2 is probaly not a good choice anyway. On NOR, where you
> don't have to deal with bad blocks, you might use ext2 or cramfs or
> ... - all of them are more efficient than JFFS2 then.
>
Oh. Thanks for letting me know. I knew cramfs would be more efficient,
but surprised that ext2 would be too. Thought ext2 was "heavier".
>> had JFFS2 working and haven't seen the real need for it yet.
>
> Mount time?
>
Maybe 1-2 seconds. Haven't measured it yet. Maybe boot-time could've
been improved yes.
>> Did you mean I should adapt the general CFI driver to support our
>> configuration, or... Based on what you say below I'm not sure what you
>> actually mean.
>
> You have two different use cases that require (if we don't want to use
> a proprietary driver) two different, mutually exclusive drivers. I
> would load the driver I need as module, and unload it if I need the
> other one. This is pretty simple in principle, but a bit ore of a
> challange in your case as you use this as a root file system
> (including to load the modules from).
>
When thinking a bit more about this, I realize we don't need to
support writing to the current filesystem in use. I've partitioned our
device into three region, where each "region" consists of four
partitions (dtb, kernel, rootfs and "home"). When upgrading we write a
complete "region image" into another flash region, which is not part
of the region we're running. So maybe we could have both mtd-ram and
cfi-flash running at the same time, since we don't actually need CFI
for the flash we're currently booting from.
I currently use mtd-utils' flash_erase to erase, and 'dd if=/dev/mtdX'
to write. The mtds is created based on info in the dts.. Regarding
DTS: Is it possible to have different partitions within the same
physical flash using different drivers? Like this:
flash@0,0 {
compatible = "amd,s29gl512n", "cfi-flash",
reg = <0x0 0x0 0x400>;
partition@...
}
... into something like this:
flash@0,0 {
compatible = "amd,s29gl512n", "cfi-flash",
reg = <0x0, 0x0 0x200>;
partition@..
}
flash@0,200 {
compatible = "amd,s29gl512n", "mtd-ram",
reg = <0x200, 0x0, 0x200>;
partition@
}
In other words, partition a flash to use different drivers when
accessing different partitions? I think that could solve the problems.
>> Me too. Small chances. So we have two options I guess: 1) Ditch
>> hardware write protection and use CFI as it is supposed to be used, or
>> 2) write a custom out-of-tree driver. What would you go for?
>
> If this is an option: 1)
>
Good to know your opinion on this.
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Do not simplify the design of a program if a way can be found to make
> it complex and wonderful.
>
Hehe. Who wrote that?
Best regards,
Frank
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] unify version_string
On Fri, Jun 24, 2011 at 16:07, Wolfgang Denk wrote: > Mike Frysinger wrote: >> > U-Boot image starts with the magic number, followed immediately by >> > the version string. That means, you can trivially identify any binary >> > image, be it as file on the host or on the target, or programmed into >> > flash, but just dumping the first bytes of it, for example: >> >> cant you do this with a linker script update ? > > Insert strings in the middle of code? you arent inserting it into the middle of code, you're inserting it at the head of the link. should be pretty easy to do. atm, you're relying on the start.S file always producing code as laid out in the file, and the linker picking up start.o first. > I don't see the real problem. I mean, we can provide the definition > of the string in some common header file, and then just use it where > needed. cmd_version.c could still have a common version_string definition and mark it weak. then any arches doing whatever crazy thing they want can override it with a non-weak symbol. -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/6] Add generic, reusable menu code
Dear "Jason Hobbs", In message <20110624202511.GA18667@jhobbs-laptop> you wrote: > On Thu, Jun 23, 2011 at 10:03:12PM +0200, Wolfgang Denk wrote: > > Dear "Jason Hobbs", > > Is this all new code, or was it copied from some other project? If > > so, reference would be needed. > > All new code. > > > Then, we need documentation how this is going to be used. Please add a > > README with documentation of the interfaces and usage examples. > > Ok - I'll add this. > > > Also, I would like to know why you didn't adapt for example the menu > > code from barebox - which specific advantages do you see in the code > > you have chosen? > > I looked over barebox's menu code after you pointed it out, and > it does have more functionality and a fancier interface than this > implementation. Unfortunately, it appears that there aren't any menus > defined to use it in the barebox codebase to provide a real example for > it. > > The primary advantage of the implementation I've provided over the > barebox implementation is simplicity. ... Thanks for the detailed explanation. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can't evaluate a man by logic alone. -- McCoy, "I, Mudd", stardate 4513.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] common: make abortboot available for menu use
Dear Wolfgang, On Fri, Jun 24, 2011 at 07:18:55AM +0200, Wolfgang Denk wrote: > > +#ifdef CONFIG_MENU > > This being a new CONFIG_ variable, it must be documented in the > README. But as is this makes little sense, so I suggest you change > the order of your patches and add the abortboot support to the menu > system in a second step, after adding (and documenting) the menu > stuff. I knew it wasn't right, but I didn't know what else to do. I'll follow your suggestion in the next version of this patch series. Thanks, Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] common: make abortboot available for menu use
Mike,
On Thu, Jun 23, 2011 at 06:59:40PM -0400, Mike Frysinger wrote:
> more ifdef trickery here than necessary:
> #ifndef CONFIG_MENU
> static inline
> #endif
> int abortboot(int bootdelay)
> {
Thanks - I'll change this in the next version of the patch.
Jason
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reg. CFI flash_init and hardware write protected devices
Dear Frank, In message you wrote: > > > Difficult to speculate - I don't know your hardware (eventually you > > have two 16 bit flash chips in parallel to build a 32 bit bus, and > > have to double the chip's erase block size?), and I don;t know how you > > created the JFFS2 file system. ... > factory default version). 16 bits databus and each sector is 64k > words, ie. 128k bytes. I created the jffs2 images using ELDKs > mkfs.jffs2. Thanks for providing me this tool :) You need to provide the correct parameters to mkfs.jffs2... > No, not sure. I've got two reasons for staying with JFFS2. 1) We > normally don't write to flash except when upgrading, so flash > performance/duration isn't very critical 2) I discovered UBIFS after I Hm... JFFS2 is probaly not a good choice anyway. On NOR, where you don't have to deal with bad blocks, you might use ext2 or cramfs or ... - all of them are more efficient than JFFS2 then. > had JFFS2 working and haven't seen the real need for it yet. Mount time? > Did you mean I should adapt the general CFI driver to support our > configuration, or... Based on what you say below I'm not sure what you > actually mean. You have two different use cases that require (if we don't want to use a proprietary driver) two different, mutually exclusive drivers. I would load the driver I need as module, and unload it if I need the other one. This is pretty simple in principle, but a bit ore of a challange in your case as you use this as a root file system (including to load the modules from). > Me too. Small chances. So we have two options I guess: 1) Ditch > hardware write protection and use CFI as it is supposed to be used, or > 2) write a custom out-of-tree driver. What would you go for? If this is an option: 1) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Do not simplify the design of a program if a way can be found to make it complex and wonderful. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/6] Add generic, reusable menu code
On Thu, Jun 23, 2011 at 10:03:12PM +0200, Wolfgang Denk wrote: > Dear "Jason Hobbs", > Is this all new code, or was it copied from some other project? If > so, reference would be needed. All new code. > Then, we need documentation how this is going to be used. Please add a > README with documentation of the interfaces and usage examples. Ok - I'll add this. > Also, I would like to know why you didn't adapt for example the menu > code from barebox - which specific advantages do you see in the code > you have chosen? I looked over barebox's menu code after you pointed it out, and it does have more functionality and a fancier interface than this implementation. Unfortunately, it appears that there aren't any menus defined to use it in the barebox codebase to provide a real example for it. The primary advantage of the implementation I've provided over the barebox implementation is simplicity. >From a user interface perspective, there are no ANSI terminal codes used, and selection of a choice is just typing out the name of the desired choice. It should work on any terminal, and would be easy to use with expect type automation tools. This simple prompt is also the default behavior for pxelinux, so should be familiar to end users. >From an implementation perspective, the code does exactly what's needed for pxecfg without adding extra features that would require some invention of functionality to prevent introduction of untested and dead code. It could work equally well for other jobs that just require a user to make a choice between some options presented on the screen, and if anything else is needed in the future, it should be extensible to accommodate. The simplicity makes the code size small - ~1k when built for my platform, vs ~2.5k for barebox's menu code. An example complexity from barebox's menu code we don't use here is each menu entry having its own display, destroy, and "call when selected action" method. Instead, we implement display the same way for all menus, destroy the same way for all entries in a menu, and the selected entry is merely returned to the caller for it to handle. The implementation also hides the details of the menu's internal structure from consumers of the interface - the menu and menu_item struct's are not externally defined, forcing all interaction to go through the function interfaces. Interface consumers provide a name and an opaque pointer to a data structure of the user's choice for each item, and the rest is shielded from the consumer's view. This should help prevent coding errors and make maintenance of the internals easier by preventing consumers from relying the implementation rather than the interface. Thanks, Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] unify version_string
Dear =?iso-8859-1?Q?Andreas_Bie=DFmann?=, In message <7a8565de-76b0-43a8-9bcd-167b2d117...@googlemail.com> you wrote: > > We need a blob containing just the version_string, another blob > containing the ppc magic number and some linker tweaks to get them both > placed before the start.S stuff. > Then we need also some make-level distinction to have the version_string > blob in some common library > for all other architectures. A lot of effort just to insert a simple string. This doesn't make sense to me. Leave the code as is, and just move the definition of the string to a common place. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Work 8 hours, sleep 8 hours; but not the same 8 hours. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] unify version_string
Dear Mike Frysinger, In message you wrote: > > > On PowerPC systems, the core is carefully consructed such that the s/core/code/, s/consructed/constructed/ > > U-Boot image starts with the magic number, followed immediately by > > the version string. That means, you can trivially identify any binary > > image, be it as file on the host or on the target, or programmed into > > flash, but just dumping the first bytes of it, for example: > > cant you do this with a linker script update ? Insert strings in the middle of code? Sonds more complicated that what it's worth. I don't see the real problem. I mean, we can provide the definition of the string in some common header file, and then just use it where needed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Nothing ever becomes real until it is experienced. - John Keats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH/RFC v3] unify version_string
This patch deletes the arch specific definitions of version_string in
favour of a single one in cmd_version module (which is always compiled
in).
Signed-off-by: Andreas Bießmann
CC: Mike Frysinger
CC: Peter Pan
---
This is an RFC as discussed in
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/101695
Dear Peter Pan,
I think it would be best to base your changes to remove
timestamp on this patch (or some modified version of it)
regards
Andreas Bießmann
changes since v1:
- remove (some) places of 'extern ... version_string' definition in favour of
include version.h
- use format-patch && send-email since some complained about base64 formated
mail content
changes since v2:
- add linker script solution for mpc512x powerpc devices
(never compiled)
arch/arm/lib/board.c|8 --
arch/avr32/lib/board.c |4 ---
arch/blackfin/lib/board.c |3 --
arch/m68k/cpu/mcf5227x/start.S | 10
arch/m68k/cpu/mcf523x/start.S | 10
arch/m68k/cpu/mcf52x2/start.S | 10
arch/m68k/cpu/mcf532x/start.S |9 ---
arch/m68k/cpu/mcf5445x/start.S | 10
arch/m68k/cpu/mcf547x_8x/start.S| 10
arch/microblaze/lib/board.c |3 --
arch/mips/lib/board.c |4 ---
arch/nios2/cpu/start.S | 13 ---
arch/powerpc/cpu/74xx_7xx/start.S | 10
arch/powerpc/cpu/mpc512x/Makefile |3 +-
arch/powerpc/cpu/mpc512x/magic_number.S |8 ++
arch/powerpc/cpu/mpc512x/start.S| 15
arch/powerpc/cpu/mpc512x/u-boot.lds |4 ++-
arch/powerpc/cpu/mpc5xx/start.S | 10
arch/powerpc/cpu/mpc5xxx/start.S| 15
arch/powerpc/cpu/mpc8220/start.S| 15
arch/powerpc/cpu/mpc824x/start.S| 10
arch/powerpc/cpu/mpc8260/start.S| 19
arch/powerpc/cpu/mpc83xx/start.S| 11 -
arch/powerpc/cpu/mpc85xx/start.S| 10
arch/powerpc/cpu/mpc86xx/start.S| 10
arch/powerpc/cpu/mpc8xx/start.S | 10
arch/powerpc/cpu/mpc8xx/video.c |1 -
arch/powerpc/cpu/ppc4xx/start.S | 10
arch/sh/lib/board.c |3 --
arch/sparc/cpu/leon2/start.S| 11 -
arch/sparc/cpu/leon3/start.S|9 ---
arch/x86/lib/board.c|4 ---
common/Makefile |9 +++
common/cmd_version.c|2 -
common/main.c |3 +-
common/version_string.c | 37 +++
drivers/video/cfb_console.c |2 +-
include/version.h |2 +
lib/display_options.c |3 +-
39 files changed, 64 insertions(+), 276 deletions(-)
create mode 100644 arch/powerpc/cpu/mpc512x/magic_number.S
create mode 100644 common/version_string.c
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 169dfeb..2401a04 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -42,7 +42,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -70,13 +69,6 @@ extern int AT91F_DataflashInit(void);
extern void dataflash_print_info(void);
#endif
-#ifndef CONFIG_IDENT_STRING
-#define CONFIG_IDENT_STRING ""
-#endif
-
-const char version_string[] =
- U_BOOT_VERSION" (" U_BOOT_DATE " - " U_BOOT_TIME ")"CONFIG_IDENT_STRING;
-
#ifdef CONFIG_DRIVER_RTL8019
extern void rtl8019_get_enetaddr (uchar * addr);
#endif
diff --git a/arch/avr32/lib/board.c b/arch/avr32/lib/board.c
index 5edef8f..e69f8d1 100644
--- a/arch/avr32/lib/board.c
+++ b/arch/avr32/lib/board.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
@@ -41,9 +40,6 @@
DECLARE_GLOBAL_DATA_PTR;
-const char version_string[] =
- U_BOOT_VERSION " ("U_BOOT_DATE" - "U_BOOT_TIME") " CONFIG_IDENT_STRING;
-
unsigned long monitor_flash_len;
/* Weak aliases for optional board functions */
diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c
index 362b8c4..7c33893 100644
--- a/arch/blackfin/lib/board.c
+++ b/arch/blackfin/lib/board.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
@@ -39,8 +38,6 @@ int post_flag;
DECLARE_GLOBAL_DATA_PTR;
-const char version_string[] = U_BOOT_VERSION " ("U_BOOT_DATE" -
"U_BOOT_TIME")";
-
__attribute__((always_inline))
static inline void serial_early_puts(const char *s)
{
diff --git a/arch/m68k/cpu/mcf5227x/start.S b/arch/m68k/cpu/mcf5227x/start.S
index d09d492..5740f94 100644
--- a/arch/m68k/cpu/mcf5227x/start.S
+++ b/arch/m68k/cpu/mcf5227x/start.S
@@ -23,7 +23,6 @@
#include
#include
-#include
#include "version.h"
#include
@@ -503,12 +502,3 @@ _int_
Re: [U-Boot] Reg. CFI flash_init and hardware write protected devices
On Fri, Jun 24, 2011 at 4:26 PM, Wolfgang Denk wrote: > Dear =?ISO-8859-1?Q?Frank_Svendsb=F8e?=, > > In message you wrote: >> >> Hi Wolfgang, I did as you recommended and replaced cfi-flash with >> mtd-ram in the device tree. I also defined CONFIG_MTD_PHYSMAP_OF, >> CONFIG_MTD_MTDRAM, CONFIG_MTDRAM_TOTAL_SIZE according to our >> specifications. The default erase-size was 128k, which is what we have >> too, so I didn't touch that. Now when I boot the kernel recognizes all >> the partitions I've defined in the dts. But, when mounting a >> jffs2-filesystem, it ends with a jffs2_scan_eraseblock(): Magic >> bitmask 0x1985 not found... >> >> Do you have any other tips? > > Difficult to speculate - I don't know your hardware (eventually you > have two 16 bit flash chips in parallel to build a 32 bit bus, and > have to double the chip's erase block size?), and I don;t know how you > created the JFFS2 file system. > Yes I know, and I don't expect you to find the answer based on so little data. FYI: We have two flash chips yes, but not to build a 32-bit bus, we have two for redundancy issues (one is storing a factory default version). 16 bits databus and each sector is 64k words, ie. 128k bytes. I created the jffs2 images using ELDKs mkfs.jffs2. Thanks for providing me this tool :) > Are you sure you want to use JFFS2? UBIFS is considered to be a > better choice these days... > No, not sure. I've got two reasons for staying with JFFS2. 1) We normally don't write to flash except when upgrading, so flash performance/duration isn't very critical 2) I discovered UBIFS after I had JFFS2 working and haven't seen the real need for it yet. >> When working with this, I realised that if I could get it to work we'd >> still might have a problem. You see, we need write access for one of >> the flashes when upgrading software. We can't treat this as a simple >> ROM. So do we need CFI working in order to set the device into >> write-mode, erase flash sectors, etc.? Or do mtd-ram handle flash >> write operations too? > > mtd-ram provides a pure memory interface, i. e. you cannot use this to > erase or program any blocks in a CFI flash device. To do so, you need > the CFI driver. > Right. mtd-ram is thus a dead-end solution for our purpose. We need to be able to write in some specific cases. >> In theory, I guess I could unmount the root fs, unload the mtd module, >> insert the cfi-flash module, mount the filesystem, then write, etc.. > > Yes, or you could start with the CFI driver in the first place. > That's what I did before you started interrupting me about mtd-ram... No, just kidding :-) Did you mean I should adapt the general CFI driver to support our configuration, or... Based on what you say below I'm not sure what you actually mean. >> But isn't that harder than write a custom map driver? > > I consider your chances to get such a customdriver into mainline to be > epsilon. And you don't really want to use any out of tree drivers. > Me too. Small chances. So we have two options I guess: 1) Ditch hardware write protection and use CFI as it is supposed to be used, or 2) write a custom out-of-tree driver. What would you go for? I'll consider if and how to get things into mainline once we have things working as we want. If my port isn't accepted I will at least learn why. Maybe the next will :) Best regards, Frank ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] unify version_string
Dear Mike Freysinger,
Am 24.06.2011 um 19:43 schrieb Mike Frysinger:
> On Fri, Jun 24, 2011 at 08:18, Wolfgang Denk wrote:
>>> --- a/arch/powerpc/cpu/74xx_7xx/start.S
>>> +++ b/arch/powerpc/cpu/74xx_7xx/start.S
>> ...
>>> .text
>>> .long 0x27051956 /* U-Boot Magic Number */
>>> - .globl version_string
>>> -version_string:
>>> - .ascii U_BOOT_VERSION
>>> - .ascii " (", U_BOOT_DATE, " - ", U_BOOT_TIME, ")"
>>> - .ascii CONFIG_IDENT_STRING, "\0"
>>
>> On PowerPC systems, the core is carefully consructed such that the
>> U-Boot image starts with the magic number, followed immediately by
>> the version string. That means, you can trivially identify any binary
>> image, be it as file on the host or on the target, or programmed into
>> flash, but just dumping the first bytes of it, for example:
>
> cant you do this with a linker script update ?
that would be great. But I need help for that cause I do not have a ppc
toolchain nor a ppc target to test it.
Some thoughts about a link time solution:
We need a blob containing just the version_string, another blob
containing the ppc magic number and some linker tweaks to get them both placed
before the start.S stuff.
Then we need also some make-level distinction to have the version_string blob
in some common library
for all other architectures.
regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: omap2: apollon: fix broken build
Define CONFIG_SYS_SDRAM_BASE to physical SDRAM address and CONFIG_SYS_INIT_SP_ADDR to physical SRAM address Signed-off-by: Igor Grinberg Cc: Kyungmin Park --- include/configs/apollon.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/configs/apollon.h b/include/configs/apollon.h index 3364ec0..1f959fc 100644 --- a/include/configs/apollon.h +++ b/include/configs/apollon.h @@ -266,4 +266,8 @@ "-(ubifs)" #endif +#define PHYS_SRAM 0x4020F800 +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDRPHYS_SRAM + #endif /* __CONFIG_H */ -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add assert() for debug assertions
On Fri, Jun 24, 2011 at 14:13, Simon Glass wrote: > On Thu, Jun 23, 2011 at 10:33 PM, Wolfgang Denk wrote: >> Finally, should the assert() not result in some termination or hang of >> U-Boot, like assert(3) is doing? > > I'm happy either way so long as it prints a message. A hang is better > than a reboot for those with ICE units, etc. My intention was that it > would simply print the message and try to continue (since we can't > really 'terminate' U-Boot, and it continues with DEBUG not defined). use panic() instead of printf() and then the hang-vs-reset issue is made into a board-config issue (CONFIG_PANIC_HANG) -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add assert() for debug assertions
Hi Wolfgang,
On Thu, Jun 23, 2011 at 10:33 PM, Wolfgang Denk wrote:
> Dear Simon Glass,
...
>> +#define assert(x) \
>> + ({ if (!(x) && _DEBUG) \
>> + printf("Assertion failure '%s' %s line %d\n", \
>> + #x, __FILE__, __LINE__); })
>
> Can we please use the same message format as used by assert(3) ?
> Afaict they use "%s%s%s:%u: %s%sAssertion `%s' failed.".
Yes, will do.
>
> Also, to save on memory footprint (frequent repetition of the common
> string "Assertion failed") we should probably provide a separate
> function for this (cf. /usr/include/assert.h).
Good idea will do.
>
> Finally, should the assert() not result in some termination or hang of
> U-Boot, like assert(3) is doing?
I'm happy either way so long as it prints a message. A hang is better
than a reboot for those with ICE units, etc. My intention was that it
would simply print the message and try to continue (since we can't
really 'terminate' U-Boot, and it continues with DEBUG not defined).
But I am happy either way, so let me know if you would like it to hang.
Regards,
Simon
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> "What the scientists have in their briefcases is terrifying."
> - Nikita Khrushchev
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
On Fri, Jun 17, 2011 at 9:27 AM, Tom Warren wrote: > Signed-off-by: Tom Warren > --- > Changes in V2: > - use 'gpio_pin' enum in gpio.h (Simon Glass review request) > - change 'GPIO_PORT8' to 'GPIO_FULLPORT' (Simon Glass request) > - change 'offset' to 'pin' globally > Changes in V3: > - use common cmd_gpio; remove redundant cmd processing code > - add gpio_request, gpio_free and gpio_toggle > - alias 'gpio_status' to 'gpio_info' for use in cmd_gpio > Changes in V4: > - update code as per Mike Frysinger's review comments > - rewrite gpio_info, aka gpio_status > Changes in V5: > - NUL-terminate the name string in gpio_request > > arch/arm/include/asm/arch-tegra2/gpio.h | 250 > +-- > arch/arm/include/asm/gpio.h | 38 + > drivers/gpio/Makefile | 1 + > drivers/gpio/tegra2_gpio.c | 255 > +++ > 4 files changed, 534 insertions(+), 10 deletions(-) > create mode 100644 arch/arm/include/asm/gpio.h > create mode 100644 drivers/gpio/tegra2_gpio.c > Has this patch been accepted? or is there anymore feedback? Mike gave it an 'otherwise, looks fine' prior to the ASCIIZ fix in V5. Thanks, Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: versatile: fix board support
Hi Stefano, On Fri, Jun 24, 2011 at 06:53:31PM +0200, stefano babic wrote: > Probably we need some feedback from ML to know if we have to save the > vexpress board or we have simply to drop it, because nobody seems to > have interest on it. The versatile is the well known example to run > the bootloader under qemu, I do not know if we have to extend the > patch to include other boards. I use U-boot in QEMU versatile express regularly. It's my primary place for testing the pxe/pxecfg/menu patches I've submitted recently. I have real versatile expresses available, but they're typically busy, so it's a useful way to try new changes without taking up a real system. I have a copy of ca9x4_ct_vxp.h I copy in from outside the tree for building with - it strips out all the flash options, undef's CONFIG_CMD_IMLS, and def's CONFIG_SYS_NO_FLASH, CONFIG_ENV_IS_NOWHERE. So, I would welcome a cleaner way to get the same thing done. Thanks, Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] unify version_string
On Fri, Jun 24, 2011 at 08:18, Wolfgang Denk wrote:
>> --- a/arch/powerpc/cpu/74xx_7xx/start.S
>> +++ b/arch/powerpc/cpu/74xx_7xx/start.S
> ...
>> .text
>> .long 0x27051956 /* U-Boot Magic Number */
>> - .globl version_string
>> -version_string:
>> - .ascii U_BOOT_VERSION
>> - .ascii " (", U_BOOT_DATE, " - ", U_BOOT_TIME, ")"
>> - .ascii CONFIG_IDENT_STRING, "\0"
>
> On PowerPC systems, the core is carefully consructed such that the
> U-Boot image starts with the magic number, followed immediately by
> the version string. That means, you can trivially identify any binary
> image, be it as file on the host or on the target, or programmed into
> flash, but just dumping the first bytes of it, for example:
cant you do this with a linker script update ?
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: versatile: fix board support
Am 24/06/2011 17:37, schrieb Loïc Minier: > On Fri, Jun 24, 2011, Stefano Babic wrote: >> Versatile board is used as example to run u-boot under qemu. >> The patch fixes relocation for all versatile boards and adds >> a versatileqemu target to be used under qemu. > > Thanks a lot! You're welcome. > >> Patch tested only under qemu, not on real boards. >> Tested with QEMU emulator version 0.14.50. > > I've built u-boot tip with your patch with: > make CROSS_COMPILE=arm-linux-gnueabi- O=$PWD/obj-versatileqemu \ > versatileqemu_config > make CROSS_COMPILE=arm-linux-gnueabi- O=$PWD/obj-versatileqemu -j3 > using the Ubuntu (Linaro-based, 4.6.0-14ubuntu1cross1.52) armel > cross-compiler but couldn't get this to start with my incantations of: > qemu-system-arm -M versatilepb -kernel obj-versatileqemu/u-boot \ > -m 128 -serial stdio > and other combinations I've tried I do not know if depends on the compiler (search in the mailing list against problem with gcc 4.5+). I tested with ELDK-4.2, that means gcc 4.2.2. I use the same qemu as you, as I tested on Ubuntu-natty: qemu-system-arm --version QEMU emulator version 0.14.50 (Debian 0.14.50-2011.03-1-0ubuntu2), Copyright (c) 2003-2008 Fabrice Bellard And I start the image with: qemu-system-arm -M versatilepb -m 128M -kernel u-boot.bin -serial stdio -net nic,vlan=0,model=smc91c111 Warning: vlan 0 is not connected to host network U-Boot 2011.06-rc3-1-gd723904 (Jun 24 2011 - 18:26:27) DRAM: 128 MiB Using default environment In:serial Out: serial Err: serial Net: SMC9-0 Note: because now the RAM is detected, the correct RAM size is displayed by U-Boot under qemu. In fact, starting with only 16MB I get: $ qemu-system-arm -M versatilepb -m 16M -kernel u-boot.bin -serial stdio -net nic,vlan=0,model=smc91c111 Warning: vlan 0 is not connected to host network U-Boot 2011.06-rc3-1-gd723904 (Jun 24 2011 - 18:26:27) DRAM: 16 MiB Using default environment In:serial Out: serial Err: serial Net: SMC9-0 VersatilePB # > > However, inspired by your changes I added these changes: > --- a/boards.cfg > +++ b/boards.cfg > @@ -138,6 +138,7 @@ omap5912osk arm arm926ejs - >ti > edminiv2 arm arm926ejs - > LaCie orion5x > dkb arm arm926ejs - > Marvellpantheon > ca9x4_ct_vxp arm armv7 vexpress > armltd > +qemuvexpressa9 arm armv7 vexpress > armltd - ca9x4_ct_vxp:ARCH_QEMU_VEXPRESS Probably we need some feedback from ML to know if we have to save the vexpress board or we have simply to drop it, because nobody seems to have interest on it. The versatile is the well known example to run the bootloader under qemu, I do not know if we have to extend the patch to include other boards. For the same reason, I have not dropped in my patch board/armltd/integrator/split_by_variant.sh. This file is obsolete for versatile, and should be removed if the integrator boards will be removed in the next release. > I wonder whether it would make sense to use the same ifdef for > versatile and vexpress boards (QEMU_NO_FLASH?) Extending the patch to vexpress, I agree using the same #ifdef. No need to add a special CONFIG_ for each board we want to run under qemu. > Could you share your recipe for getting the versatileqemu config to > start? I'm using Ubuntu's qemu (Linaro-based, > 0.14.50-2011.06-0-0ubuntu1). See at the beginning. It seems I am testing on the same distro as you, and if it does not work, there should be something related to the different toolchains we are using. I have tested also with gcc 4.4.1, no problem found. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: versatile: fix board support
On Fri, Jun 24, 2011, Stefano Babic wrote:
> Versatile board is used as example to run u-boot under qemu.
> The patch fixes relocation for all versatile boards and adds
> a versatileqemu target to be used under qemu.
Thanks a lot!
> Patch tested only under qemu, not on real boards.
> Tested with QEMU emulator version 0.14.50.
I've built u-boot tip with your patch with:
make CROSS_COMPILE=arm-linux-gnueabi- O=$PWD/obj-versatileqemu \
versatileqemu_config
make CROSS_COMPILE=arm-linux-gnueabi- O=$PWD/obj-versatileqemu -j3
using the Ubuntu (Linaro-based, 4.6.0-14ubuntu1cross1.52) armel
cross-compiler but couldn't get this to start with my incantations of:
qemu-system-arm -M versatilepb -kernel obj-versatileqemu/u-boot \
-m 128 -serial stdio
and other combinations I've tried
However, inspired by your changes I added these changes:
--- a/boards.cfg
+++ b/boards.cfg
@@ -138,6 +138,7 @@ omap5912osk arm arm926ejs -
ti
edminiv2 arm arm926ejs - LaCie
orion5x
dkb arm arm926ejs -
Marvellpantheon
ca9x4_ct_vxp arm armv7 vexpressarmltd
+qemuvexpressa9 arm armv7 vexpress
armltd - ca9x4_ct_vxp:ARCH_QEMU_VEXPRESS
efikamx arm armv7 efikamx -
mx5mx51evk:IMX_CONFIG=board/efikamx/imximage.cfg
mx51evk arm armv7 mx51evk
freescale mx5
mx51evk:IMX_CONFIG=board/freescale/mx51evk/imximage.cfg
mx53evk arm armv7 mx53evk
freescale mx5
mx53evk:IMX_CONFIG=board/freescale/mx53evk/imximage.cfg
--- a/include/configs/ca9x4_ct_vxp.h
+++ b/include/configs/ca9x4_ct_vxp.h
@@ -148,6 +148,12 @@
"cp ${initrdaddr} ${initrd} ${maxinitrd}; " \
"bootm ${kerneladdr} ${initrd}\0"
+#ifdef CONFIG_ARCH_QEMU_VEXPRESS
+#define CONFIG_ENV_SIZE8192
+#define CONFIG_SYS_NO_FLASH
+#define CONFIG_ENV_IS_NOWHERE
+#define CONFIG_SYS_MONITOR_LEN 0x8
+#else
/* FLASH and environment organization */
#define PHYS_FLASH_SIZE0x0400 /* 64MB */
#define CONFIG_SYS_FLASH_CFI 1
@@ -187,6 +193,7 @@
#define CONFIG_SYS_FLASH_EMPTY_INFO/* flinfo indicates empty blocks */
#define CONFIG_SYS_FLASH_BANKS_LIST{ CONFIG_SYS_FLASH_BASE0, \
CONFIG_SYS_FLASH_BASE1 }
+#endif
/* Monitor Command Prompt */
#define CONFIG_SYS_CBSIZE 512 /* Console I/O Buffer Size */
and built with:
make CROSS_COMPILE=arm-linux-gnueabi- O=$PWD/obj-qemuvexpressa9 \
qemuvexpressa9_config
make CROSS_COMPILE=arm-linux-gnueabi- O=$PWD/obj-qemuvexpressa9 -j3 \
$PWD/obj-qemuvexpressa9/u-boot
and this started fine with:
qemu-system-arm -M vexpress-a9 -kernel obj-qemuvexpressa9/u-boot \
-m 1024 -serial stdio
I wonder whether it would make sense to use the same ifdef for
versatile and vexpress boards (QEMU_NO_FLASH?) and prefix the board
names with qemu; e.g. qemu_versatile_foo?
Could you share your recipe for getting the versatileqemu config to
start? I'm using Ubuntu's qemu (Linaro-based,
0.14.50-2011.06-0-0ubuntu1).
--
Loïc Minier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND_SPL Endianess problem?
Hi list, answer to myself: no endianness problem... I hunted a phantom. Actualley it was openOCD which somehow prevented the jump to SDRAM Works fine now. Regards Simon 2011/6/24 Simon Schwarz : > Hi list, > > still working on NAND for my SPL... > > The system is working - I can read from the device. But the endianess > seems to be big endian and not little as I would expect. > > If I program e.g. 13 00 00 EA I read EA 00 00 13 from NAND. Sure I > could write a conversion function but IMHO there has to be another > problem. I use the standard nand_read_buf16 function from nand_base.c. > > Is there something I miss? It just doesn't make sense to me that the > same driver would write/read in different endianness any ideas? > > Regards > Simon > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reg. CFI flash_init and hardware write protected devices
Dear =?ISO-8859-1?Q?Frank_Svendsb=F8e?=, In message you wrote: > > Hi Wolfgang, I did as you recommended and replaced cfi-flash with > mtd-ram in the device tree. I also defined CONFIG_MTD_PHYSMAP_OF, > CONFIG_MTD_MTDRAM, CONFIG_MTDRAM_TOTAL_SIZE according to our > specifications. The default erase-size was 128k, which is what we have > too, so I didn't touch that. Now when I boot the kernel recognizes all > the partitions I've defined in the dts. But, when mounting a > jffs2-filesystem, it ends with a jffs2_scan_eraseblock(): Magic > bitmask 0x1985 not found... > > Do you have any other tips? Difficult to speculate - I don't know your hardware (eventually you have two 16 bit flash chips in parallel to build a 32 bit bus, and have to double the chip's erase block size?), and I don;t know how you created the JFFS2 file system. Are you sure you want to use JFFS2? UBIFS is considered to be a better choice these days... > When working with this, I realised that if I could get it to work we'd > still might have a problem. You see, we need write access for one of > the flashes when upgrading software. We can't treat this as a simple > ROM. So do we need CFI working in order to set the device into > write-mode, erase flash sectors, etc.? Or do mtd-ram handle flash > write operations too? mtd-ram provides a pure memory interface, i. e. you cannot use this to erase or program any blocks in a CFI flash device. To do so, you need the CFI driver. > In theory, I guess I could unmount the root fs, unload the mtd module, > insert the cfi-flash module, mount the filesystem, then write, etc.. Yes, or you could start with the CFI driver in the first place. > But isn't that harder than write a custom map driver? I consider your chances to get such a customdriver into mainline to be epsilon. And you don't really want to use any out of tree drivers. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you're out of tree, you don't exist. - David Woodhouse in <1304620350.2398.29.ca...@i7.infradead.org> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Run U-boot from Flash!
Dear manojatl, In message <31920053.p...@talk.nabble.com> you wrote: > > We are in the process of porting linux to our custom board. We are using > u-boot-1.1.6 as bootloader. We are able to successfully port u-boot in RAM First, U-Boot 1.1.6 is more than 5 years old and only of interest to paleontologists - like a dinosaur. I tmakes absolutely no sense putting any efforts n such old code. Please do yourself (and us) a favour and use current code (i. e. v2011-06-rc3 or later). > to our custom board. But we want to run the u-boot from flash. We understand > that u-boot is capable of relocating the code from flash to ram. But we > didn't find any idea for changing the address of '_start', which is always > loaded with TEXT_BASE address. Then just change the setting of TEXT_BASE as needed. Note that it would have been helpful if you had mentioned which architecture / CPU / board you are talking about. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you're out of tree, you don't exist. - David Woodhouse in <1304620350.2398.29.ca...@i7.infradead.org> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Run U-boot from Flash!
On 06/24/2011 03:53 PM, manojatl wrote: > > Hi, > Hi, > We are in the process of porting linux to our custom board. We are using > u-boot-1.1.6 as bootloader. Before you waste your time: make a pleasure to yourself and update to the last U-Boot code, better from GIT repository (git.denx.de). Your version is so old that it is quite difficult to find someone remembering details about it. > We are able to successfully port u-boot in RAM > to our custom board. But we want to run the u-boot from flash. We understand > that u-boot is capable of relocating the code from flash to ram. You have not indicated which architecture you have (ARM,PPC, ...), and from which board you are basing your porting. > Expecting a postive response. Start using last code and check again if you have relevant issues. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reg. CFI flash_init and hardware write protected devices
>> Ok. So you recommend I stop "hacking" the CFI probing and instead >> write a custom flash map driver? > > No. Never write new drivers when you can use existing ones :-) > > Describe the flash memory as "mtd-ram" (instead of "cfi-flash") in > the device tree and select the physmap driver in your kernel config. > Hi Wolfgang, I did as you recommended and replaced cfi-flash with mtd-ram in the device tree. I also defined CONFIG_MTD_PHYSMAP_OF, CONFIG_MTD_MTDRAM, CONFIG_MTDRAM_TOTAL_SIZE according to our specifications. The default erase-size was 128k, which is what we have too, so I didn't touch that. Now when I boot the kernel recognizes all the partitions I've defined in the dts. But, when mounting a jffs2-filesystem, it ends with a jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found... Do you have any other tips? When working with this, I realised that if I could get it to work we'd still might have a problem. You see, we need write access for one of the flashes when upgrading software. We can't treat this as a simple ROM. So do we need CFI working in order to set the device into write-mode, erase flash sectors, etc.? Or do mtd-ram handle flash write operations too? In theory, I guess I could unmount the root fs, unload the mtd module, insert the cfi-flash module, mount the filesystem, then write, etc.. But isn't that harder than write a custom map driver? Best regards, Frank ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Run U-boot from Flash!
Hi, We are in the process of porting linux to our custom board. We are using u-boot-1.1.6 as bootloader. We are able to successfully port u-boot in RAM to our custom board. But we want to run the u-boot from flash. We understand that u-boot is capable of relocating the code from flash to ram. But we didn't find any idea for changing the address of '_start', which is always loaded with TEXT_BASE address. Expecting a postive response. Thanks Manu -- View this message in context: http://old.nabble.com/Run-U-boot-from-Flash%21-tp31920053p31920053.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC v2] unify version_string
Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=, In message <1308918857-7402-1-git-send-email-andreas.de...@googlemail.com> you wrote: > This patch deletes the arch specific definitions of version_string in > favour of a single one in cmd_version module (which is always compiled > in). ... > changes since v1: > - remove (some) places of 'extern ... version_string' definition in favour of >include version.h > - use format-patch && send-email since some complained about base64 formated >mail content Still NAK, because the PowerPC identification gets still broken. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Overdrawn? But I still have checks left! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: versatile: fix board support
Versatile board is used as example to run u-boot under qemu.
The patch fixes relocation for all versatile boards and adds
a versatileqemu target to be used under qemu.
Patch tested only under qemu, not on real boards.
Tested with QEMU emulator version 0.14.50.
Signed-off-by: Stefano Babic
CC: Alessandro Rubini
CC: Loïc Minier
---
Because the versatile board is still broken, the patch tries
to fix board support to be used with qemu. The versatile board
is the board commonly described in the examples to run u-boot under qemu.
The patch tries to fix the comments to former Alessandro Rubini's patch:
http://www.mail-archive.com/u-boot@lists.denx.de/msg51136.html
Makefile |9 -
board/armltd/versatile/config.mk |5 -
board/armltd/versatile/versatile.c | 10 +-
boards.cfg |3 +++
include/configs/versatile.h| 21 -
5 files changed, 32 insertions(+), 16 deletions(-)
delete mode 100644 board/armltd/versatile/config.mk
diff --git a/Makefile b/Makefile
index d14955f..2a85f91 100644
--- a/Makefile
+++ b/Makefile
@@ -975,15 +975,6 @@ edb9315a_config: unconfig
@$(MKCONFIG) -n $@ -t $(@:_config=) edb93xx arm arm920t edb93xx - ep93xx
#
-# ARM supplied Versatile development boards
-#
-
-versatile_config \
-versatileab_config \
-versatilepb_config : unconfig
- @board/armltd/versatile/split_by_variant.sh $@
-
-#
## XScale Systems
#
diff --git a/board/armltd/versatile/config.mk b/board/armltd/versatile/config.mk
deleted file mode 100644
index 8b57af1..000
--- a/board/armltd/versatile/config.mk
+++ /dev/null
@@ -1,5 +0,0 @@
-#
-# image should be loaded at 0x0100
-#
-
-CONFIG_SYS_TEXT_BASE = 0x0100
diff --git a/board/armltd/versatile/versatile.c
b/board/armltd/versatile/versatile.c
index 6e836dd..ee8cb5e 100644
--- a/board/armltd/versatile/versatile.c
+++ b/board/armltd/versatile/versatile.c
@@ -51,7 +51,7 @@ void show_boot_progress(int progress)
* Miscellaneous platform dependent initialisations
*/
-int board_init (void)
+int board_early_init_f (void)
{
/*
* set clock frequency:
@@ -62,6 +62,11 @@ int board_init (void)
((VERSATILE_TIMCLK << VERSATILE_TIMER1_EnSel) | (VERSATILE_TIMCLK <<
VERSATILE_TIMER2_EnSel) |
(VERSATILE_TIMCLK << VERSATILE_TIMER3_EnSel) | (VERSATILE_TIMCLK <<
VERSATILE_TIMER4_EnSel));
+ return 0;
+}
+
+int board_init (void)
+{
/* arch number of Versatile Board */
gd->bd->bi_arch_number = MACH_TYPE_VERSATILE_PB;
@@ -88,6 +93,9 @@ int misc_init_r (void)
**/
int dram_init (void)
{
+ /* dram_init must store complete ramsize in gd->ram_size */
+ gd->ram_size = get_ram_size((volatile void *)CONFIG_SYS_SDRAM_BASE,
+ PHYS_SDRAM_1_SIZE);
return 0;
}
diff --git a/boards.cfg b/boards.cfg
index ac20c81..9397345 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -71,6 +71,9 @@ smdk2410 arm arm920t -
samsung
netstar arm arm925t
voicebluearm arm925t
omap1510inn arm arm925t - ti
+versatileqemuarm arm926ejs versatile
armltd versatile versatile:ARCH_VERSATILE_QEMU
+versatilepb arm arm926ejs versatile
armltd versatile versatile:ARCH_VERSATILE_PB
+versatileab arm arm926ejs versatile
armltd versatile versatile:ARCH_VERSATILE_AB
aspenite arm arm926ejs -
Marvellarmada100
afeb9260 arm arm926ejs - -
at91
at91cap9adk arm arm926ejs - atmel
at91
diff --git a/include/configs/versatile.h b/include/configs/versatile.h
index db68965..32cee82 100644
--- a/include/configs/versatile.h
+++ b/include/configs/versatile.h
@@ -74,6 +74,7 @@
/*
* Size of malloc() pool
*/
+#define CONFIG_ENV_SIZE8192
#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 128 * 1024)
/*
@@ -168,9 +169,26 @@
#define PHYS_SDRAM_1_SIZE 0x0800 /* 128 MB */
#define PHYS_FLASH_SIZE0x0400 /* 64MB */
+#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
+#define CONFIG_SYS_INIT_RAM_ADDR 0x0080
+#define CONFIG_SYS_INIT_RAM_SIZE 0x000F
+#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - \
+
[U-Boot] [PATCH/RFC v2] unify version_string
This patch deletes the arch specific definitions of version_string in
favour of a single one in cmd_version module (which is always compiled
in).
Signed-off-by: Andreas Bießmann
CC: Mike Frysinger
CC: Peter Pan
---
This is an RFC as discussed in
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/101695
Dear Peter Pan,
I think it would be best to base your changes to remove
timestamp on this patch (or some modified version of it)
regards
Andreas Bießmann
changes since v1:
- remove (some) places of 'extern ... version_string' definition in favour of
include version.h
- use format-patch && send-email since some complained about base64 formated
mail content
arch/arm/lib/board.c |8
arch/avr32/lib/board.c|4
arch/blackfin/lib/board.c |3 ---
arch/m68k/cpu/mcf5227x/start.S| 10 --
arch/m68k/cpu/mcf523x/start.S | 10 --
arch/m68k/cpu/mcf52x2/start.S | 10 --
arch/m68k/cpu/mcf532x/start.S |9 -
arch/m68k/cpu/mcf5445x/start.S| 10 --
arch/m68k/cpu/mcf547x_8x/start.S | 10 --
arch/microblaze/lib/board.c |3 ---
arch/mips/lib/board.c |4
arch/nios2/cpu/start.S| 13 -
arch/powerpc/cpu/74xx_7xx/start.S | 10 --
arch/powerpc/cpu/mpc512x/start.S | 10 --
arch/powerpc/cpu/mpc5xx/start.S | 10 --
arch/powerpc/cpu/mpc5xxx/start.S | 15 ---
arch/powerpc/cpu/mpc8220/start.S | 15 ---
arch/powerpc/cpu/mpc824x/start.S | 10 --
arch/powerpc/cpu/mpc8260/start.S | 19 ---
arch/powerpc/cpu/mpc83xx/start.S | 11 ---
arch/powerpc/cpu/mpc85xx/start.S | 10 --
arch/powerpc/cpu/mpc86xx/start.S | 10 --
arch/powerpc/cpu/mpc8xx/start.S | 10 --
arch/powerpc/cpu/mpc8xx/video.c |1 -
arch/powerpc/cpu/ppc4xx/start.S | 10 --
arch/sh/lib/board.c |3 ---
arch/sparc/cpu/leon2/start.S | 11 ---
arch/sparc/cpu/leon3/start.S |9 -
arch/x86/lib/board.c |4
common/cmd_version.c |8 +++-
common/main.c |3 +--
drivers/video/cfb_console.c |2 +-
include/version.h |2 ++
lib/display_options.c |3 +--
34 files changed, 12 insertions(+), 268 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 169dfeb..2401a04 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -42,7 +42,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -70,13 +69,6 @@ extern int AT91F_DataflashInit(void);
extern void dataflash_print_info(void);
#endif
-#ifndef CONFIG_IDENT_STRING
-#define CONFIG_IDENT_STRING ""
-#endif
-
-const char version_string[] =
- U_BOOT_VERSION" (" U_BOOT_DATE " - " U_BOOT_TIME ")"CONFIG_IDENT_STRING;
-
#ifdef CONFIG_DRIVER_RTL8019
extern void rtl8019_get_enetaddr (uchar * addr);
#endif
diff --git a/arch/avr32/lib/board.c b/arch/avr32/lib/board.c
index 5edef8f..e69f8d1 100644
--- a/arch/avr32/lib/board.c
+++ b/arch/avr32/lib/board.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
@@ -41,9 +40,6 @@
DECLARE_GLOBAL_DATA_PTR;
-const char version_string[] =
- U_BOOT_VERSION " ("U_BOOT_DATE" - "U_BOOT_TIME") " CONFIG_IDENT_STRING;
-
unsigned long monitor_flash_len;
/* Weak aliases for optional board functions */
diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c
index 362b8c4..7c33893 100644
--- a/arch/blackfin/lib/board.c
+++ b/arch/blackfin/lib/board.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
@@ -39,8 +38,6 @@ int post_flag;
DECLARE_GLOBAL_DATA_PTR;
-const char version_string[] = U_BOOT_VERSION " ("U_BOOT_DATE" -
"U_BOOT_TIME")";
-
__attribute__((always_inline))
static inline void serial_early_puts(const char *s)
{
diff --git a/arch/m68k/cpu/mcf5227x/start.S b/arch/m68k/cpu/mcf5227x/start.S
index d09d492..5740f94 100644
--- a/arch/m68k/cpu/mcf5227x/start.S
+++ b/arch/m68k/cpu/mcf5227x/start.S
@@ -23,7 +23,6 @@
#include
#include
-#include
#include "version.h"
#include
@@ -503,12 +502,3 @@ _int_handler:
bsr int_handler
addql #4,%sp
RESTORE_ALL
-
-/*--*/
-
- .globl version_string
-version_string:
- .ascii U_BOOT_VERSION
- .ascii " (", U_BOOT_DATE, " - ", U_BOOT_TIME, ")"
- .ascii CONFIG_IDENT_STRING, "\0"
- .align 4
diff --git a/arch/m68k/cpu/mcf523x/start.S b/arch/m68k/cpu/mcf523x/start.S
index a726b59..1df0082 100644
--- a/arch/m68k/cpu/mcf523x/start.S
+++ b/arch/m68k/cpu/mcf523x/start.S
@@ -23,7 +23,6 @@
#include
#include
-#include
#include "version.h"
#include
@@ -265,12 +264,
Re: [U-Boot] [PATCH/RFC] unify version_string
Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=,
In message <1308905261-3780-1-git-send-email-andreas.de...@googlemail.com> you
wrote:
> This patch deletes the arch specific definitions of version_string in
> favour of a single one in cmd_version module (which is always compiled
> in).
>
> Signed-off-by: Andreas BieÃmann
> CC: Mike Frysinger
> CC: Peter Pan
> ---
> This is an RFC as discussed in
> http://mid.gmane.org/201106162022.09802.vap...@gentoo.org
Sorry, but NAK. The idea is good, but the implementation is serioulsy
flawed.
...
> diff --git a/arch/powerpc/cpu/74xx_7xx/start.S
> b/arch/powerpc/cpu/74xx_7xx/start.S
> index f6011fc..5fea39d 100644
> --- a/arch/powerpc/cpu/74xx_7xx/start.S
> +++ b/arch/powerpc/cpu/74xx_7xx/start.S
...
> .text
> .long 0x27051956 /* U-Boot Magic Number */
> - .globl version_string
> -version_string:
> - .ascii U_BOOT_VERSION
> - .ascii " (", U_BOOT_DATE, " - ", U_BOOT_TIME, ")"
> - .ascii CONFIG_IDENT_STRING, "\0"
On PowerPC systems, the core is carefully consructed such that the
U-Boot image starts with the magic number, followed immediately by
the version string. That means, you can trivially identify any binary
image, be it as file on the host or on the target, or programmed into
flash, but just dumping the first bytes of it, for example:
On the host:
-> xd /tftpboot/tqm8560/u-boot.bin | head -5
0 27051956 552d426f 6f742032 3031302e |' VU-Boot 2010.|
10 31322d30 30313439 2d673662 31656632 |12-00149-g6b1ef2|
20 612d6469 72747920 284d6179 20303420 |a-dirty (May 04 |
30 32303131 202d2032 333a3439 3a343929 |2011 - 23:49:49)|
40 ||
On the target:
=> md FFFC 14
fffc: 27051956 552d426f 6f742032 3031302e'..VU-Boot 2010.
fffc0010: 31322d30 30313439 2d673662 3165663212-00149-g6b1ef2
fffc0020: 612d6469 72747920 284d6179 20303420a-dirty (May 04
fffc0030: 32303131 202d2032 333a3439 3a3439292011 - 23:49:49)
fffc0040:
I consider this a very useful property and am not willing to give it
up.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
This message was made from 100% recycled electrons.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] NAND_SPL Endianess problem?
Hi list, still working on NAND for my SPL... The system is working - I can read from the device. But the endianess seems to be big endian and not little as I would expect. If I program e.g. 13 00 00 EA I read EA 00 00 13 from NAND. Sure I could write a conversion function but IMHO there has to be another problem. I use the standard nand_read_buf16 function from nand_base.c. Is there something I miss? It just doesn't make sense to me that the same driver would write/read in different endianness any ideas? Regards Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Not able access External peripherals in PPC440EP
Dear Denk, Thanks for your suggestion. Now i have migrated to uboot v2011.06-rc2 and the booting sequece is working fine. But the problem still i am facing is not able access the external periherals like NVRAM and ADC, DAC etc. What minimum initializations to be done for that. Thanks in advance Regards, Suresh On 6/20/11, Wolfgang Denk wrote: > Dear suresh kumar, > > In message you wrote: >> >>I am using a PPC 440EP processor based custom designed board which is >> based on AMCC's Yosemite as reference design. >> I have ported u-boot-1.1.6 onto it. It is working fine but not able to > > U-Boot 1.1.6 is more than 5 years old, i. e. it predates the stone > age. We don;t support this any more. > > Please update to current code (v2011.06-rc2 or later). > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > It's hard to make a program foolproof because fools are so ingenious. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH/RFC] unify version_string
This patch deletes the arch specific definitions of version_string in
favour of a single one in cmd_version module (which is always compiled
in).
Signed-off-by: Andreas Bießmann
CC: Mike Frysinger
CC: Peter Pan
---
This is an RFC as discussed in
http://mid.gmane.org/201106162022.09802.vap...@gentoo.org
Dear Peter Pan,
I think it would be best to base your changes to remove
timestamp on this patch (or some modified version of it)
regards
Andreas Bießmann
arch/arm/lib/board.c |8
arch/avr32/lib/board.c|4
arch/blackfin/lib/board.c |3 ---
arch/m68k/cpu/mcf5227x/start.S| 10 --
arch/m68k/cpu/mcf523x/start.S | 10 --
arch/m68k/cpu/mcf52x2/start.S | 10 --
arch/m68k/cpu/mcf532x/start.S |9 -
arch/m68k/cpu/mcf5445x/start.S| 10 --
arch/m68k/cpu/mcf547x_8x/start.S | 10 --
arch/microblaze/lib/board.c |3 ---
arch/mips/lib/board.c |4
arch/nios2/cpu/start.S| 13 -
arch/powerpc/cpu/74xx_7xx/start.S | 10 --
arch/powerpc/cpu/mpc512x/start.S | 10 --
arch/powerpc/cpu/mpc5xx/start.S | 10 --
arch/powerpc/cpu/mpc5xxx/start.S | 15 ---
arch/powerpc/cpu/mpc8220/start.S | 15 ---
arch/powerpc/cpu/mpc824x/start.S | 10 --
arch/powerpc/cpu/mpc8260/start.S | 19 ---
arch/powerpc/cpu/mpc83xx/start.S | 11 ---
arch/powerpc/cpu/mpc85xx/start.S | 10 --
arch/powerpc/cpu/mpc86xx/start.S | 10 --
arch/powerpc/cpu/mpc8xx/start.S | 10 --
arch/powerpc/cpu/mpc8xx/video.c |1 -
arch/powerpc/cpu/ppc4xx/start.S | 10 --
arch/sh/lib/board.c |3 ---
arch/sparc/cpu/leon2/start.S | 11 ---
arch/sparc/cpu/leon3/start.S |9 -
arch/x86/lib/board.c |4
common/cmd_version.c |8 +++-
include/version.h |2 ++
31 files changed, 9 insertions(+), 263 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 169dfeb..2401a04 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -42,7 +42,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -70,13 +69,6 @@ extern int AT91F_DataflashInit(void);
extern void dataflash_print_info(void);
#endif
-#ifndef CONFIG_IDENT_STRING
-#define CONFIG_IDENT_STRING ""
-#endif
-
-const char version_string[] =
- U_BOOT_VERSION" (" U_BOOT_DATE " - " U_BOOT_TIME ")"CONFIG_IDENT_STRING;
-
#ifdef CONFIG_DRIVER_RTL8019
extern void rtl8019_get_enetaddr (uchar * addr);
#endif
diff --git a/arch/avr32/lib/board.c b/arch/avr32/lib/board.c
index 5edef8f..e69f8d1 100644
--- a/arch/avr32/lib/board.c
+++ b/arch/avr32/lib/board.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
@@ -41,9 +40,6 @@
DECLARE_GLOBAL_DATA_PTR;
-const char version_string[] =
- U_BOOT_VERSION " ("U_BOOT_DATE" - "U_BOOT_TIME") " CONFIG_IDENT_STRING;
-
unsigned long monitor_flash_len;
/* Weak aliases for optional board functions */
diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c
index 362b8c4..7c33893 100644
--- a/arch/blackfin/lib/board.c
+++ b/arch/blackfin/lib/board.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
@@ -39,8 +38,6 @@ int post_flag;
DECLARE_GLOBAL_DATA_PTR;
-const char version_string[] = U_BOOT_VERSION " ("U_BOOT_DATE" -
"U_BOOT_TIME")";
-
__attribute__((always_inline))
static inline void serial_early_puts(const char *s)
{
diff --git a/arch/m68k/cpu/mcf5227x/start.S b/arch/m68k/cpu/mcf5227x/start.S
index d09d492..5740f94 100644
--- a/arch/m68k/cpu/mcf5227x/start.S
+++ b/arch/m68k/cpu/mcf5227x/start.S
@@ -23,7 +23,6 @@
#include
#include
-#include
#include "version.h"
#include
@@ -503,12 +502,3 @@ _int_handler:
bsr int_handler
addql #4,%sp
RESTORE_ALL
-
-/*--*/
-
- .globl version_string
-version_string:
- .ascii U_BOOT_VERSION
- .ascii " (", U_BOOT_DATE, " - ", U_BOOT_TIME, ")"
- .ascii CONFIG_IDENT_STRING, "\0"
- .align 4
diff --git a/arch/m68k/cpu/mcf523x/start.S b/arch/m68k/cpu/mcf523x/start.S
index a726b59..1df0082 100644
--- a/arch/m68k/cpu/mcf523x/start.S
+++ b/arch/m68k/cpu/mcf523x/start.S
@@ -23,7 +23,6 @@
#include
#include
-#include
#include "version.h"
#include
@@ -265,12 +264,3 @@ _int_handler:
bsr int_handler
addql #4,%sp
RESTORE_ALL
-
-/*--*/
-
- .globl version_string
-version_string:
- .ascii U_BOOT_VERSION
- .ascii " (", U_BOOT_DATE, " - ", U_BOOT_TIME, ")"
- .ascii CONFIG_IDENT_STRING, "\0"
-
Re: [U-Boot] [PATCH v2] powerpc/85xx: Add basic support for P1023RDS board
any feedback for this patch? Thanks. Roy > -Original Message- > From: Zang Roy-R61911 > Sent: Thursday, June 09, 2011 11:31 AM > To: u-boot@lists.denx.de > Cc: Zang Roy-R61911; Wang Haiying-R54964; Lan Chunhe-B25806; Xu Lei-B33228; > sun york-R58495; Kumar Gala > Subject: [PATCH v2] powerpc/85xx: Add basic support for P1023RDS board > > The P1023RDS board is the reference board for the P1023 SoC. > > Add support for booting it from NOR or NAND, with fixed 2G of DDR, PCIe, > UART, I2C, etc. > > Signed-off-by: Roy Zang > Signed-off-by: Haiying Wang > Signed-off-by: Chunhe Lan > Signed-off-by: Lei Xu > Signed-off-by: York Sun > Signed-off-by: Kumar Gala > --- > based on "Prepare v2011.06-rc2" > v2 vs. v1: some code style clean up > > MAINTAINERS |1 + > board/freescale/p1023rds/Makefile | 38 ++ > board/freescale/p1023rds/bcsr.h | 53 +++ > board/freescale/p1023rds/law.c| 35 ++ > board/freescale/p1023rds/p1023rds.c | 162 +++ > board/freescale/p1023rds/tlb.c| 118 ++ > boards.cfg|2 + > doc/README.p1023rds | 102 + > include/configs/P1023RDS.h| 562 > + > nand_spl/board/freescale/p1023rds/Makefile| 133 ++ > nand_spl/board/freescale/p1023rds/nand_boot.c | 99 + > 11 files changed, 1305 insertions(+), 0 deletions(-) > create mode 100644 board/freescale/p1023rds/Makefile > create mode 100644 board/freescale/p1023rds/bcsr.h > create mode 100644 board/freescale/p1023rds/law.c > create mode 100644 board/freescale/p1023rds/p1023rds.c > create mode 100644 board/freescale/p1023rds/tlb.c > create mode 100644 doc/README.p1023rds > create mode 100644 include/configs/P1023RDS.h > create mode 100644 nand_spl/board/freescale/p1023rds/Makefile > create mode 100644 nand_spl/board/freescale/p1023rds/nand_boot.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index c462ae2..af31552 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -511,6 +511,7 @@ Ilya Yanok > Roy Zang > > mpc7448hpc2 MPC7448 > + P1023RDSP1023 > > John Zhan > > diff --git a/board/freescale/p1023rds/Makefile > b/board/freescale/p1023rds/Makefile > new file mode 100644 > index 000..bf87580 > --- /dev/null > +++ b/board/freescale/p1023rds/Makefile > @@ -0,0 +1,38 @@ > +# > +# Copyright 2010-2011 Freescale Semiconductor, Inc. > +# > +# This program is free software; you can redistribute it and/or modify it > +# under the terms of the GNU General Public License as published by the Free > +# Software Foundation; either version 2 of the License, or (at your option) > +# any later version. > +# > + > +include $(TOPDIR)/config.mk > + > +LIB = $(obj)lib$(BOARD).o > + > +COBJS-y += $(BOARD).o > +COBJS-y += law.o > +COBJS-y += tlb.o > + > +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) > +OBJS := $(addprefix $(obj),$(COBJS-y)) > +SOBJS:= $(addprefix $(obj),$(SOBJS)) > + > +$(LIB): $(obj).depend $(OBJS) $(SOBJS) > + $(AR) $(ARFLAGS) $@ $(OBJS) > + > +clean: > + rm -f $(OBJS) $(SOBJS) > + > +distclean: clean > + rm -f $(LIB) core *.bak .depend > + > +# > + > +# defines $(obj).depend target > +include $(SRCTREE)/rules.mk > + > +sinclude $(obj).depend > + > +# > diff --git a/board/freescale/p1023rds/bcsr.h b/board/freescale/p1023rds/bcsr.h > new file mode 100644 > index 000..0995aa4 > --- /dev/null > +++ b/board/freescale/p1023rds/bcsr.h > @@ -0,0 +1,53 @@ > +/* > + * Copyright (C) 2011 Freescale Semiconductor, Inc. > + * > + * Authors: Chunhe Lan > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License as published by the Free > + * Software Foundation; either version 2 of the License, or (at your option) > + * any later version. > + * > + */ > + > +#ifndef __BCSR_H_ > +#define __BCSR_H_ > + > +#include > + > +/* > + * BCSR Bit definitions > + * BCSR 15 * > + 0 device insertion oriention > + 1 stack processor present > + 2 power supply shut down/normal operation > + 3 I2C bus0 drive enable > + 4 reserved > + 5:7 I2C bus0 select > + 5 - I2C_BUS_0_SS0 > + 6 - I2C_BUS_0_SS1 > + 7 - I2C_BUS_0_SS2 > +*/ > + > +/* BCSR register base address is 0xFX20 */ > +#define BCSR_BASE_REG_OFFSET 0x20 > +#define BCSR_ACCESS_REG_ADDR (CONFIG_SYS_BCSR_BASE + BCSR_BASE_REG_OFFSET) > + > +#define BCSR15_DEV_INS_ORI 0x80 > +#define BCSR15_STACK_PRO_PRE 0x40 > +#define BCSR15_POWER_SUPPLY 0x20 > +#define BCSR15_I2C_BUS0_EN 0x10 > +#define BCSR15_I2C_BUS0_SEG0 0x00 > +#de
