[U-Boot] Regarding the config.mk in U-boot TOP directory
Hi Wolfgang, I have been facing an issue while building u-boot for AT91SAM9263ek board. The environment I am using is CYGWIN and toolchain is the Code sourcery toolchain. The make configuration step works fine while make CROSS_COMPILE step throws the following error: make CROSS_COMPILE=arm-none-linux-gnueabi- Generating include/autoconf.mk include/common.h:37: fatal error: config.h: No such file or directory compilation terminated. Generating include/autoconf.mk.dep include/common.h:37: fatal error: config.h: No such file or directory compilation terminated. make: *** [include/autoconf.mk.dep] Error 1 While going through the files in u-boot I made the following observations: The config.mk available in the TOPDIR of the u-boot folder has the following variable definition: gccincdir := $(shell $(CC) -print-file-name=include) CPPFLAGS += -I$(TOPDIR)/include CPPFLAGS += -fno-builtin -ffreestanding -nostdinc \ -isystem $(gccincdir) -pipe $(PLATFORM_CPPFLAGS) Where $(TOPDIR)/include = /u-boot-2010.09-rc2/include (AND) $(gccincdir) = is the cross compiler's include library, which in my case is, c:/cygwin/home/e458110/linuxproj/tools/bin/../lib/gcc/arm-none-linux-gnu eabi/4.4.1/include From what I can understand from this, the -I flag makes the u-boot /INCLUDE directory to be the first in list to search for header files while preprocessing and -isystem flag asks the compiler to consider the cross compiler's as the system directory or search for system headers. Now I went make to common.h file which is throwing the error given above and observed that config.h is defined in angle brackets: i.e. #include config.h So what I feel is happening here is that the compiler only searches its own include directory for headers since the files are in brackets. When I copy all the files in the uboot /include directory to the compiler's include the build process starts while fails at some point since some autogenerated header files are created in the u-boot/include by default and needs to be moved to the compiler's include each time proceed. I could go about changing the #include config.h to #include config.h but this is going to be very tedious and time consuming as the entire u-boot code needs to be changed for this. I tried various combinations of gcc flags for the variable CPPFLAGS, all failed for reasons which I was able to trace back. Has this condition been observed before and is there any work around for it? Also, please correct me if my understanding is wrong. I am at crucial point in my project would be delighted to have support at the earliest. Regards, Shyama ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Regarding the config.mk in U-boot TOP directory
Hi Wolfgang, I have been facing an issue while building u-boot for AT91SAM9263ek board. The environment I am using is CYGWIN and toolchain is the Code sourcery toolchain. The make configuration step works fine while make CROSS_COMPILE step throws the following error: make CROSS_COMPILE=arm-none-linux-gnueabi- Generating include/autoconf.mk include/common.h:37: fatal error: config.h: No such file or directory compilation terminated. Generating include/autoconf.mk.dep include/common.h:37: fatal error: config.h: No such file or directory compilation terminated. make: *** [include/autoconf.mk.dep] Error 1 While going through the files in u-boot I made the following observations: The config.mk available in the TOPDIR of the u-boot folder has the following variable definition: gccincdir := $(shell $(CC) -print-file-name=include) CPPFLAGS += -I$(TOPDIR)/include CPPFLAGS += -fno-builtin -ffreestanding -nostdinc \ -isystem $(gccincdir) -pipe $(PLATFORM_CPPFLAGS) Where $(TOPDIR)/include = /u-boot-2010.09-rc2/include (AND) $(gccincdir) = is the cross compiler's include library, which in my case is, c:/cygwin/home/e458110/linuxproj/tools/bin/../lib/gcc/arm-none-linux-gnu eabi/4.4.1/include From what I can understand from this, the -I flag makes the u-boot /INCLUDE directory to be the first in list to search for header files while preprocessing and -isystem flag asks the compiler to consider the cross compiler's as the system directory or search for system headers. Now I went make to common.h file which is throwing the error given above and observed that config.h is defined in angle brackets: i.e. #include config.h So what I feel is happening here is that the compiler only searches its own include directory for headers since the files are in brackets. When I copy all the files in the uboot /include directory to the compiler's include the build process starts while fails at some point since some autogenerated header files are created in the u-boot/include by default and needs to be moved to the compiler's include each time proceed. I could go about changing the #include config.h to #include config.h but this is going to be very tedious and time consuming as the entire u-boot code needs to be changed for this. I tried various combinations of gcc flags for the variable CPPFLAGS, all failed for reasons which I was able to trace back. Has this condition been observed before and is there any work around for it? Also, please correct me if my understanding is wrong. I am at crucial point in my project would be delighted to have support at the earliest. Regards, Shyama ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.
On 30.12.2010 00:10, Alessandro Rubini wrote:
Dirk Behme:
Just for the record:
The trick is to ensure that the __arch_putx() containing the volatile
is not the last statement in the GCC statement-expression. So, using
something like
#define writeb(v,c) ({ __iowmb(); __arch_putb(v,c); v;})
(note the additional 'v;') should result in correct code, too.
Yes, that's good. Also 0 may work, and may be more readable, (or not,
according to who reads it).
Yes, indeed,
#define writeb(v,c) ({ __iowmb(); __arch_putb(v,c); 0;})
seems to work, too :)
Thanks
Dirk
The patches sent by Wolfgang and Alexander using
#define writeb(v,c) do { __iowmb(); __arch_putb(v,c); } while (0)
do the same with a slightly different syntax, so these patches are
fine, too.
It's not just different syntax, it's different semantics.
The ({...}) trick turns statements into expressions, while the do
{...} while(0) does not. I'd better not forbid statements like
while (reg = readb(addr), reg != VALUE) { }
or
if (readb(addr) == VALUE) { ... }
or
swtich (readb(addr)) { ... }
While I agree they may in general not be clean, I can forsee
meaningful uses. Moreover, I'd better allow expression-looking macros
to really behave like expressions -- otherwise error messages are quite
hard to understand for the unaquainted.
IMHO, the only reason to use do {} while(0) over statemente
expressions is being portable but in u-boot we are gcc-specific
anyways.
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] We Offer Private, Commercial and Personal Loans with Minimal annual Interest of 3% to any part of the world.
Our loans within the range of $20,000 to $200,000,000 USD. Interested Persons should contact me via E-mail:___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] MX5:MX53: add initial support for MX53EVK board
On 12/29/2010 01:38 PM, Jason Liu wrote: Add initial support for MX53EVK board support. FEC, SD/MMC, UART, I2C, have been support. Signed-off-by: Jason Liu r64...@freescale.com Hi Jason, Changes for v3: - put uart and fec iomux setting to board_early_init_f so that uart can print out the early information such as uboot banner and cpuinfo etc. - put mxc_gpio patch into this commit according to Stefno comments, This is not what I meant. I told to put the mxc_gpio patch into this patchset (as you have now done, [PATCH v3 4/8] mxc_gpio: add support for MX53 processor is in this patchset), but not to duplicate the patch inside this commit. In fact, I cannot apply your patches, as they are changing the same file. diff --git a/MAINTAINERS b/MAINTAINERS index 0590ad9..698d401 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -555,6 +555,10 @@ Stefano Babic sba...@denx.de mx51evk i.MX51 vision2 i.MX51 +Jason Liu r64...@freescale.com + + MX53evk i.MX53 + Enric Balletbo i Serra eballe...@iseebcn.com Please maintain the list *alfabetically* sorted. --- a/drivers/gpio/mxc_gpio.c +++ b/drivers/gpio/mxc_gpio.c @@ -24,7 +24,7 @@ #ifdef CONFIG_MX31 #include asm/arch/mx31-regs.h #endif -#ifdef CONFIG_MX51 Drop these changes from this patch, as we have them in the [PATCH v3 4/8]. +/*** + * Command definition + ***/ Multiline comment, please fix globally in this file. 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] OMAP3: EVM: Linker errors across tool chain versions
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Dirk Behme Sent: Friday, December 17, 2010 4:10 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] OMAP3: EVM: Linker errors across tool chain versions [snip]...[snip] GNU ld (Sourcery G++ Lite 2010.09-50) 2.20.51.20100809 -rwxr-xr-x 1 dirk users 981801 16. Dez 10:41 u-boot I would really like to nail this down to a specific tool / version. Does this help? Any comments on this? If we would come to a conclusion, soon, I'd like to get a fix integrated for v2010.12. [sp] I had to be away from work for most of this month to attend a personal emergency. Haven't yet followed on this/ related threads to check if the issue has really been taken care of. Will spend next few days to get current on it... ~sanjeev Thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/8] MX5: Add initial support for MX53 processor
On 12/29/2010 01:38 PM, Jason Liu wrote: Add initial support for Freescale MX53 processor, - Add the iomux support and the pin definition, - Add the regs definition, clean up some unused def from mx51, - Add the low level init support, make use the freq input of setup_pll macro Hi Jason, diff --git a/arch/arm/include/asm/arch-mx5/asm-offsets.h b/arch/arm/include/asm/arch-mx5/asm-offsets.h index afd2728..2258f2f 100644 --- a/arch/arm/include/asm/arch-mx5/asm-offsets.h +++ b/arch/arm/include/asm/arch-mx5/asm-offsets.h @@ -37,7 +37,12 @@ #define CLKCTL_CCGR40x78 #define CLKCTL_CCGR50x7C #define CLKCTL_CCGR60x80 +#if defined(CONFIG_MX53) +#define CLKCTL_CCGR70x84 #define CLKCTL_CMEOR0x84 +#elif defined(CONFIG_MX51) +#define CLKCTL_CMEOR0x84 +#endif It seems to me that CLKCTL_CMEOR should be dropped in the CONFIG_MX53 case, as its offset is reserved for CLKCTL_CCGR7. -/*! * Number of GPIO port as defined in the IC Spec */ #define GPIO_PORT_NUM4 I see now that GPIO_PORT_NUM seems superfluous, and it is not used in any part of code. Please drop it :-) 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 v3 7/8] imximage: Add MX53 boot image support
On 12/29/2010 01:49 PM, Jason Liu wrote:
This patch add the MX53 boot image support.
This patch has been tested on Freescale MX53EVK board
and MX51EVK board.
Signed-off-by: Jason Liu r64...@freescale.com
Hi Jason,
diff --git a/board/freescale/mx51evk/imximage.cfg
b/board/freescale/mx51evk/imximage.cfg
index a875e8f..11825fb 100644
--- a/board/freescale/mx51evk/imximage.cfg
+++ b/board/freescale/mx51evk/imximage.cfg
@@ -25,6 +25,10 @@
#
# The syntax is taken as close as possible with the kwbimage
+# Imximage version
+
+IMXIMAGE_VERSION 1
The name is not consistent with the other commands, as they do not use
the IMXIMAGE_ prefix (we do not have such as IMXIMAGE_BOOT_FROM). Please
replace with VERSION.
Not change the mx51evk file. The code should take VERSION=1 as default,
and we do not need to change the actual boards.
diff --git a/board/ttcontrol/vision2/imximage_hynix.cfg
b/board/ttcontrol/vision2/imximage_hynix.cfg
index ed531db..cdc533d 100644
--- a/board/ttcontrol/vision2/imximage_hynix.cfg
+++ b/board/ttcontrol/vision2/imximage_hynix.cfg
@@ -28,6 +28,10 @@
#
# The syntax is taken as close as possible with the kwbimage
+# Imximage version
+
+IMXIMAGE_VERSION 2
...and this is wrong, as vision is a MX51 board.
diff --git a/doc/README.imximage b/doc/README.imximage
index 3378f7e..48ac466 100644
--- a/doc/README.imximage
+++ b/doc/README.imximage
@@ -57,6 +57,11 @@ Configuration command line syntax:
2. Following are the valid command strings and associated data strings:-
Command string data string
-- ---
+ IMXIMAGE_VERSION1/2
+ 1 is for mx25/mx35/mx51 compatible,
+ 2 is for mx53 compatible,
+ others is invalid and error is generated.
As the VERSION selects the type of the header, I do not think it could
be set in any place of the file, or the code must be aware of it. Please
add a note in the documentation and raise an error in code if the
VERSION command is read after any other suitable commands.
What happens for example if VERSION is set at the end of imximage.cfg file ?
diff --git a/tools/imximage.c b/tools/imximage.c
index 39f89c2..2bbc4a6 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -36,6 +36,7 @@
* Supported commands for configuration file
*/
static table_entry_t imximage_cmds[] = {
+ {CMD_IMXIMAGE_VERSION, IMXIMAGE_VERSION, imximage version, },
Change IMXIMAGE_VERSION simply to VERSION
+static void err_imximage_version(int version)
+{
+ fprintf(stderr,
+ Error: Unsuported imximage version:%d\n, version);
^--typo, unsupported
+static void set_dcd_value_v1(struct imx_header *imxhdr, char *name, int
lineno,
+ int fld, uint32_t value, uint32_t off)
+{
+ dcd_v1_t *dcd_v1 = imxhdr-header.hdr_v1.dcd_table;
+
+ switch (fld) {
+ case CFG_REG_SIZE:
+ /* Byte, halfword, word */
+ if ((value != 1) (value != 2) (value != 4)) {
+ fprintf(stderr, Error: %s[%d] -
+ Invalid register size (%d)\n,
+ name, lineno, value);
+ exit(EXIT_FAILURE);
+ }
+ dcd_v1-addr_data[off].type = value;
+ break;
+ case CFG_REG_ADDRESS:
+ dcd_v1-addr_data[off].addr = value;
+ break;
+ case CFG_REG_VALUE:
+ dcd_v1-addr_data[off].value = value;
+ break;
+ default:
+ break;
+
+ }
+}
+
+static void set_dcd_value_v2(struct imx_header *imxhdr, char *name, int
lineno,
+ int fld, uint32_t value, uint32_t off)
+{
+ dcd_v2_t *dcd_v2 = imxhdr-header.hdr_v2.dcd_table;
+
+ switch (fld) {
+ case CFG_REG_ADDRESS:
+ dcd_v2-addr_data[off].addr = cpu_to_be32(value);
+ break;
+ case CFG_REG_VALUE:
+ dcd_v2-addr_data[off].value = cpu_to_be32(value);
+ break;
+ default:
+ break;
+
+ }
+}
+
+static void set_dcd_value(struct imx_header *imxhdr, char *name, int lineno,
+ int fld, uint32_t value, uint32_t off)
+{
+ switch (imxhdr-imximage_version) {
+ case IMXIMAGE_V1:
+ set_dcd_value_v1(imxhdr, name, lineno, fld, value, off);
+ break;
+ case IMXIMAGE_V2:
+ set_dcd_value_v2(imxhdr, name, lineno, fld, value, off);
+ break;
+ default:
+ err_imximage_version(imxhdr-imximage_version);
+ break;
+ }
+}
You inserted several help functions (set_dcd_value, print_...,..) and
all of them implement a switch case to reindirect to the specific
function. What about to drop them and to use function
[U-Boot] Regarding the config.mk in U-boot TOP directory
Hi Wolfgang, I have been facing an issue while building u-boot for AT91SAM9263ek board. The environment I am using is CYGWIN and toolchain is the Code sourcery toolchain. The make configuration step works fine while make CROSS_COMPILE step throws the following error: make CROSS_COMPILE=arm-none-linux-gnueabi- Generating include/autoconf.mk include/common.h:37: fatal error: config.h: No such file or directory compilation terminated. Generating include/autoconf.mk.dep include/common.h:37: fatal error: config.h: No such file or directory compilation terminated. make: *** [include/autoconf.mk.dep] Error 1 While going through the files in u-boot I made the following observations: The config.mk available in the TOPDIR of the u-boot folder has the following variable definition: gccincdir := $(shell $(CC) -print-file-name=include) CPPFLAGS += -I$(TOPDIR)/include CPPFLAGS += -fno-builtin -ffreestanding -nostdinc \ -isystem $(gccincdir) -pipe $(PLATFORM_CPPFLAGS) Where $(TOPDIR)/include = /u-boot-2010.09-rc2/include $(gccincdir) = is the cross compiler's include library, which in my case is, c:/cygwin/home/e458110/linuxproj/tools/bin/../lib/gcc/arm-none-linux-gnu eabi/4.4.1/include From what I can understand from this, the -I flag makes the u-boot /INCLUDE directory to be the first in list to search for header files while preprocessing and -isystem flag asks the compiler to consider the cross compiler's as the system directory or search for system headers. Now I went make to common.h file which is throwing the error given above and observed that config.h is defined in angle brackets: i.e. #include config.h So what I feel is happening here is that the compiler only searches its own include directory for headers since the files are in brackets. When I copy all the files in the uboot /include directory to the compiler's include the build process starts while fails at some point since some autogenerated header files are created in the u-boot/include by default and needs to be moved to the compiler's include each time proceed. I could go about changing the #include config.h to #include config.h but this is going to be very tedious and time consuming as the entire u-boot code needs to be changed for this. I tried various combinations of gcc flags for the variable CPPFLAGS, all failed for reasons which I was able to trace back. Has this condition been observed before and is there any work around for it? Also, please correct me if my understanding is wrong. I am at crucial point in my project would be delighted to have support at the earliest. Regards, Shyama ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] pci: Add find_hose_by_cfg_addr() helper function
On Dec 17, 2010, at 5:30 PM, Kumar Gala wrote:
Being able to get back a pci_controller struct back by searching for it
means we can do things like dynamically allocate them or not have to
expose the static structures to all users.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
drivers/pci/pci.c | 11 +++
include/pci.h |1 +
2 files changed, 12 insertions(+), 0 deletions(-)
Any comments or concerns on this? Some of my 8xxx PCI cleanup depends on the
two patches.
- k
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 702ac67..74ef4ec 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -165,6 +165,17 @@ struct pci_controller *pci_bus_to_hose (int bus)
return NULL;
}
+struct pci_controller *find_hose_by_cfg_addr(void *cfg_addr)
+{
+ struct pci_controller *hose;
+
+ for (hose = hose_head; hose; hose = hose-next)
+ if (hose-cfg_addr == cfg_addr)
+ return hose;
+
+ return NULL;
+}
+
int pci_last_busno(void)
{
struct pci_controller *hose = hose_head;
diff --git a/include/pci.h b/include/pci.h
index c456006..e80b6bd 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -511,6 +511,7 @@ extern int pci_hose_write_config_word_via_dword(struct
pci_controller *hose,
extern void *pci_map_bar(pci_dev_t pdev, int bar, int flags);
extern void pci_register_hose(struct pci_controller* hose);
extern struct pci_controller* pci_bus_to_hose(int bus);
+extern struct pci_controller *find_hose_by_cfg_addr(void *cfg_addr);
extern int pci_hose_scan(struct pci_controller *hose);
extern int pci_hose_scan_bus(struct pci_controller *hose, int bus);
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
Albert, Please pull u-boot-ti/master Regards, Sandeep The following changes since commit b722e646f9a6e2ebcae4845afc596b4dad4f7bcb: Sandeep Paulraj (1): DaVinci DM6467: Enhance board Support are available in the git repository at: git://git.denx.de/u-boot-ti.git master Sandeep Paulraj (3): DaVinci DM6467: Fix Build Error DaVinci Sonata: Fix Build Error DaVinci: Remove incorrect CONFIG option arch/arm/cpu/arm926ejs/davinci/cpu.c | 14 -- include/configs/davinci_sonata.h |1 + 2 files changed, 13 insertions(+), 2 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/8] fsl_pmic: add I2C interface support
On 12/29/2010 01:38 PM, Jason Liu wrote:
This patch add I2C interface for fsl_pmic driver support
Signed-off-by: Jason Liu r64...@freescale.com
---
Changes for v2:
- Address the comments from Stefano,
- factor out the param_check in pmic_reg for both spi/i2c
---
drivers/misc/fsl_pmic.c | 52 ++
1 files changed, 47 insertions(+), 5 deletions(-)
Hi Jason,
+
+ if (init_done == 0) {
+ i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+ init_done = 1;
+ }
As I can see, i2c_init is called during initialization in
arch/arm/lib/board.c. Why do we need to call it again ?
+ if (write) {
+ buf[0] = (val 16) 0xff;
+ buf[1] = (val 8) 0xff;
+ buf[2] = (val) 0xff;
+ if (i2c_write(CONFIG_SYS_FSL_PMIC_I2C_ADDR, reg, 1, buf, 3))
+ return -1;
+ } else {
+ if (i2c_read(CONFIG_SYS_FSL_PMIC_I2C_ADDR, reg, 1, buf, 3)) {
+ return -1;
+ ret_val = buf[0] 16 | buf[1] 8 | buf[2];
+ }
I am wondering if it works. The line with ret_val is never reached. Do
you tested it ?
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
[U-Boot] [PATCH] OMAP: Remove omapfb.debug=y from Beagle and Overo env settings
The kernel DSS2 code is mature now, and keeping this setting hurts performance
Signed-off-by: Steve Sakoman st...@sakoman.com
---
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 56363f7..d0ef313 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -203,7 +203,6 @@
mpurate=${mpurate} \
vram=${vram} \
omapfb.mode=dvi:${dvimode} \
- omapfb.debug=y \
omapdss.def_disp=${defaultdisplay} \
root=${mmcroot} \
rootfstype=${mmcrootfstype}\0 \
@@ -211,7 +210,6 @@
mpurate=${mpurate} \
vram=${vram} \
omapfb.mode=dvi:${dvimode} \
- omapfb.debug=y \
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 3b53796..74b2ff0 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -169,7 +169,6 @@
mpurate=${mpurate} \
vram=${vram} \
omapfb.mode=dvi:${dvimode} \
- omapfb.debug=y \
omapdss.def_disp=${defaultdisplay} \
root=${mmcroot} \
rootfstype=${mmcrootfstype}\0 \
@@ -177,7 +176,6 @@
mpurate=${mpurate} \
vram=${vram} \
omapfb.mode=dvi:${dvimode} \
- omapfb.debug=y \
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] Blackfin: bfin_sdh: add support for multiblock operations
From: Sonic Zhang sonic.zh...@analog.com Don't forget to count full data size for the multiblock operation request. Signed-off-by: Sonic Zhang sonic.zh...@analog.com Signed-off-by: Mike Frysinger vap...@gentoo.org --- drivers/mmc/bfin_sdh.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/bfin_sdh.c b/drivers/mmc/bfin_sdh.c index f9da6a3..31b6459 100644 --- a/drivers/mmc/bfin_sdh.c +++ b/drivers/mmc/bfin_sdh.c @@ -114,11 +114,12 @@ static int sdh_setup_data(struct mmc *mmc, struct mmc_data *data) u16 data_ctl = 0; u16 dma_cfg = 0; int ret = 0; + unsigned long data_size = data-blocksize * data-blocks; /* Don't support write yet. */ if (data-flags MMC_DATA_WRITE) return UNUSABLE_ERR; - data_ctl |= ((ffs(data-blocksize) - 1) 4); + data_ctl |= ((ffs(data_size) - 1) 4); data_ctl |= DTX_DIR; bfin_write_SDH_DATA_CTL(data_ctl); dma_cfg = WDSIZE_32 | RESTART | WNR | DMAEN; @@ -126,13 +127,13 @@ static int sdh_setup_data(struct mmc *mmc, struct mmc_data *data) bfin_write_SDH_DATA_TIMER(-1); blackfin_dcache_flush_invalidate_range(data-dest, - data-dest + data-blocksize); + data-dest + data_size); /* configure DMA */ bfin_write_DMA_START_ADDR(data-dest); - bfin_write_DMA_X_COUNT(data-blocksize / 4); + bfin_write_DMA_X_COUNT(data_size / 4); bfin_write_DMA_X_MODIFY(4); bfin_write_DMA_CONFIG(dma_cfg); - bfin_write_SDH_DATA_LGTH(data-blocksize); + bfin_write_SDH_DATA_LGTH(data_size); /* kick off transfer */ bfin_write_SDH_DATA_CTL(bfin_read_SDH_DATA_CTL() | DTX_DMA_E | DTX_E); -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] Blackfin: bfin_sdh: set all timer bits before transfer
From: Cliff Cai cliff@analog.com The timer register is 32bits, not 16bit, so 0x won't fill it. Write out -1 to make sure to fill the whole thing. Signed-off-by: Cliff Cai cliff@analog.com Signed-off-by: Mike Frysinger vap...@gentoo.org --- drivers/mmc/bfin_sdh.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/bfin_sdh.c b/drivers/mmc/bfin_sdh.c index 5670939..f9da6a3 100644 --- a/drivers/mmc/bfin_sdh.c +++ b/drivers/mmc/bfin_sdh.c @@ -123,7 +123,7 @@ static int sdh_setup_data(struct mmc *mmc, struct mmc_data *data) bfin_write_SDH_DATA_CTL(data_ctl); dma_cfg = WDSIZE_32 | RESTART | WNR | DMAEN; - bfin_write_SDH_DATA_TIMER(0x); + bfin_write_SDH_DATA_TIMER(-1); blackfin_dcache_flush_invalidate_range(data-dest, data-dest + data-blocksize); -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_jffs2: Fix get_part_sector_size_nor() overflow bug
When a flash partition was positioned at the very top of a 32-bit memory
map (eg located at 0xf800 with a size of 0x800)
get_part_sector_size_nor() would incorrectly calculate the partition's
ending address to 0x0 due to overflow. When the overflow occurred
get_part_sector_size_nor() would falsely return a sector size of 0.
A sector size of 0 results in subsequent jffs2 operations failing.
To workaround the overflow subtract 1 from calculated address of
the partition endpoint.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
common/cmd_jffs2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_jffs2.c b/common/cmd_jffs2.c
index 0e7a6b0..27296dd 100644
--- a/common/cmd_jffs2.c
+++ b/common/cmd_jffs2.c
@@ -281,7 +281,7 @@ static inline u32 get_part_sector_size_nor(struct mtdids
*id, struct part_info *
flash = flash_info[id-num];
start_phys = flash-start[0] + part-offset;
- end_phys = start_phys + part-size;
+ end_phys = start_phys + part-size - 1;
for (i = 0; i flash-sector_count; i++) {
if (flash-start[i] = end_phys)
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] MX5:MX53: add initial support for MX53EVK board
Hi, Stefano, 2010/12/30 Stefano Babic sba...@denx.de: On 12/29/2010 01:38 PM, Jason Liu wrote: Add initial support for MX53EVK board support. FEC, SD/MMC, UART, I2C, have been support. Signed-off-by: Jason Liu r64...@freescale.com Hi Jason, Changes for v3: - put uart and fec iomux setting to board_early_init_f so that uart can print out the early information such as uboot banner and cpuinfo etc. - put mxc_gpio patch into this commit according to Stefno comments, This is not what I meant. I told to put the mxc_gpio patch into this patchset (as you have now done, [PATCH v3 4/8] mxc_gpio: add support for MX53 processor is in this patchset), but not to duplicate the patch inside this commit. In fact, I cannot apply your patches, as they are changing the same file. My bad. I will change it by removing it. diff --git a/MAINTAINERS b/MAINTAINERS index 0590ad9..698d401 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -555,6 +555,10 @@ Stefano Babic sba...@denx.de mx51evk i.MX51 vision2 i.MX51 +Jason Liu r64...@freescale.com + + MX53evk i.MX53 + Enric Balletbo i Serra eballe...@iseebcn.com Please maintain the list *alfabetically* sorted. OK, --- a/drivers/gpio/mxc_gpio.c +++ b/drivers/gpio/mxc_gpio.c @@ -24,7 +24,7 @@ #ifdef CONFIG_MX31 #include asm/arch/mx31-regs.h #endif -#ifdef CONFIG_MX51 Drop these changes from this patch, as we have them in the [PATCH v3 4/8]. Yes, I will do it. +/*** + * Command definition + ***/ Multiline comment, please fix globally in this file. OK, I will fix it globally. 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/8] MX5: Add initial support for MX53 processor
Hi, Stefano, 2010/12/30 Stefano Babic sba...@denx.de: On 12/29/2010 01:38 PM, Jason Liu wrote: Add initial support for Freescale MX53 processor, - Add the iomux support and the pin definition, - Add the regs definition, clean up some unused def from mx51, - Add the low level init support, make use the freq input of setup_pll macro Hi Jason, diff --git a/arch/arm/include/asm/arch-mx5/asm-offsets.h b/arch/arm/include/asm/arch-mx5/asm-offsets.h index afd2728..2258f2f 100644 --- a/arch/arm/include/asm/arch-mx5/asm-offsets.h +++ b/arch/arm/include/asm/arch-mx5/asm-offsets.h @@ -37,7 +37,12 @@ #define CLKCTL_CCGR4 0x78 #define CLKCTL_CCGR5 0x7C #define CLKCTL_CCGR6 0x80 +#if defined(CONFIG_MX53) +#define CLKCTL_CCGR7 0x84 #define CLKCTL_CMEOR 0x84 +#elif defined(CONFIG_MX51) +#define CLKCTL_CMEOR 0x84 +#endif It seems to me that CLKCTL_CMEOR should be dropped in the CONFIG_MX53 case, as its offset is reserved for CLKCTL_CCGR7. I will fix the CLKCTL_CMEOR offset in MX53. Thanks for the careful review. -/*! * Number of GPIO port as defined in the IC Spec */ #define GPIO_PORT_NUM 4 I see now that GPIO_PORT_NUM seems superfluous, and it is not used in any part of code. Please drop it :-) OK, 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/8] imximage: Add MX53 boot image support
Hi, Stefano,
2010/12/30 Stefano Babic sba...@denx.de:
On 12/29/2010 01:49 PM, Jason Liu wrote:
This patch add the MX53 boot image support.
This patch has been tested on Freescale MX53EVK board
and MX51EVK board.
Signed-off-by: Jason Liu r64...@freescale.com
Hi Jason,
diff --git a/board/freescale/mx51evk/imximage.cfg
b/board/freescale/mx51evk/imximage.cfg
index a875e8f..11825fb 100644
--- a/board/freescale/mx51evk/imximage.cfg
+++ b/board/freescale/mx51evk/imximage.cfg
@@ -25,6 +25,10 @@
#
# The syntax is taken as close as possible with the kwbimage
+# Imximage version
+
+IMXIMAGE_VERSION 1
The name is not consistent with the other commands, as they do not use
the IMXIMAGE_ prefix (we do not have such as IMXIMAGE_BOOT_FROM). Please
replace with VERSION.
OK, make sense.
Not change the mx51evk file. The code should take VERSION=1 as default,
and we do not need to change the actual boards.
Do you mean that if can't find the VERSION command in the cfg file, it
will be treated
as V1, right?
diff --git a/board/ttcontrol/vision2/imximage_hynix.cfg
b/board/ttcontrol/vision2/imximage_hynix.cfg
index ed531db..cdc533d 100644
--- a/board/ttcontrol/vision2/imximage_hynix.cfg
+++ b/board/ttcontrol/vision2/imximage_hynix.cfg
@@ -28,6 +28,10 @@
#
# The syntax is taken as close as possible with the kwbimage
+# Imximage version
+
+IMXIMAGE_VERSION 2
...and this is wrong, as vision is a MX51 board.
My bad. Sorry for typo.
diff --git a/doc/README.imximage b/doc/README.imximage
index 3378f7e..48ac466 100644
--- a/doc/README.imximage
+++ b/doc/README.imximage
@@ -57,6 +57,11 @@ Configuration command line syntax:
2. Following are the valid command strings and associated data strings:-
Command string data string
-- ---
+ IMXIMAGE_VERSION 1/2
+ 1 is for mx25/mx35/mx51 compatible,
+ 2 is for mx53 compatible,
+ others is invalid and error is generated.
As the VERSION selects the type of the header, I do not think it could
be set in any place of the file, or the code must be aware of it. Please
add a note in the documentation and raise an error in code if the
VERSION command is read after any other suitable commands.
What happens for example if VERSION is set at the end of imximage.cfg file ?
Yes, I will add this note to tell that VERSION need be set before
other suitable commands.
diff --git a/tools/imximage.c b/tools/imximage.c
index 39f89c2..2bbc4a6 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -36,6 +36,7 @@
* Supported commands for configuration file
*/
static table_entry_t imximage_cmds[] = {
+ {CMD_IMXIMAGE_VERSION, IMXIMAGE_VERSION, imximage version, },
Change IMXIMAGE_VERSION simply to VERSION
+static void err_imximage_version(int version)
+{
+ fprintf(stderr,
+ Error: Unsuported imximage version:%d\n, version);
^--typo, unsupported
Will fix it.
+static void set_dcd_value_v1(struct imx_header *imxhdr, char *name, int
lineno,
+ int fld, uint32_t value, uint32_t off)
+{
+ dcd_v1_t *dcd_v1 = imxhdr-header.hdr_v1.dcd_table;
+
+ switch (fld) {
+ case CFG_REG_SIZE:
+ /* Byte, halfword, word */
+ if ((value != 1) (value != 2) (value != 4)) {
+ fprintf(stderr, Error: %s[%d] -
+ Invalid register size (%d)\n,
+ name, lineno, value);
+ exit(EXIT_FAILURE);
+ }
+ dcd_v1-addr_data[off].type = value;
+ break;
+ case CFG_REG_ADDRESS:
+ dcd_v1-addr_data[off].addr = value;
+ break;
+ case CFG_REG_VALUE:
+ dcd_v1-addr_data[off].value = value;
+ break;
+ default:
+ break;
+
+ }
+}
+
+static void set_dcd_value_v2(struct imx_header *imxhdr, char *name, int
lineno,
+ int fld, uint32_t value, uint32_t off)
+{
+ dcd_v2_t *dcd_v2 = imxhdr-header.hdr_v2.dcd_table;
+
+ switch (fld) {
+ case CFG_REG_ADDRESS:
+ dcd_v2-addr_data[off].addr = cpu_to_be32(value);
+ break;
+ case CFG_REG_VALUE:
+ dcd_v2-addr_data[off].value = cpu_to_be32(value);
+ break;
+ default:
+ break;
+
+ }
+}
+
+static void set_dcd_value(struct imx_header *imxhdr, char *name, int lineno,
+ int fld, uint32_t value, uint32_t off)
+{
+ switch (imxhdr-imximage_version) {
+ case IMXIMAGE_V1:
+ set_dcd_value_v1(imxhdr, name, lineno, fld, value, off);
+ break;
+ case IMXIMAGE_V2:
+ set_dcd_value_v2(imxhdr, name, lineno, fld, value, off);
+
[U-Boot] Which Version of Cross-Compiler should i choose?
Hello,everybody,i am new to uboot. now i choose v2010.09-rc2 Uboot for porting. I used to compiling uboot1.1.2 by arm-elf-20050511 and works well.Now i do not know which version of arm cross-compiler to choose? Any suggestions are appreciated ! Thanks all . By MrGates ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/8] fsl_pmic: add I2C interface support
Hi, Stefano,
2010/12/31 Stefano Babic sba...@denx.de:
On 12/29/2010 01:38 PM, Jason Liu wrote:
This patch add I2C interface for fsl_pmic driver support
Signed-off-by: Jason Liu r64...@freescale.com
---
Changes for v2:
- Address the comments from Stefano,
- factor out the param_check in pmic_reg for both spi/i2c
---
drivers/misc/fsl_pmic.c | 52
++
1 files changed, 47 insertions(+), 5 deletions(-)
Hi Jason,
+
+ if (init_done == 0) {
+ i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+ init_done = 1;
+ }
As I can see, i2c_init is called during initialization in
arch/arm/lib/board.c. Why do we need to call it again ?
Yes, I think, I can remove it.
+ if (write) {
+ buf[0] = (val 16) 0xff;
+ buf[1] = (val 8) 0xff;
+ buf[2] = (val) 0xff;
+ if (i2c_write(CONFIG_SYS_FSL_PMIC_I2C_ADDR, reg, 1, buf, 3))
+ return -1;
+ } else {
+ if (i2c_read(CONFIG_SYS_FSL_PMIC_I2C_ADDR, reg, 1, buf, 3)) {
+ return -1;
+ ret_val = buf[0] 16 | buf[1] 8 | buf[2];
+ }
I am wondering if it works. The line with ret_val is never reached. Do
you tested it ?
I have tested before. This patch of code is definitely wrong. I will fix it.
Thanks for review.
Happy New Year!
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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding the config.mk in U-boot TOP directory
On Thursday, December 30, 2010 6:51 PM, Asokan, Shyama Trikkadeeri wrote: Hi Wolfgang, I have been facing an issue while building u-boot for AT91SAM9263ek board. The environment I am using is CYGWIN and toolchain is the Code sourcery toolchain. The make configuration step works fine while make CROSS_COMPILE step throws the following error: make CROSS_COMPILE=arm-none-linux-gnueabi- Generating include/autoconf.mk include/common.h:37: fatal error: config.h: No such file or directory compilation terminated. Generating include/autoconf.mk.dep include/common.h:37: fatal error: config.h: No such file or directory compilation terminated. make: *** [include/autoconf.mk.dep] Error 1 While going through the files in u-boot I made the following observations: [...] I had similar issues some time back but the build environment was not Cygwin. I was working on adding support for a board on one GIT branch and after building an image (without a distclean) shifted to another branch which didn't have the board support added. Compiling u-boot for a different board on the second branch threw up errors like you mentioned. Even distclean didn't help. This was probably due to the auto-generated files depending on a board config which wasn't in the branch I was working on. I was able to finally get things working by manually deleting include/config.h, include/config.mk, include/autoconf.mk and include/autoconf.mk.dep A couple of more instances where I got the errors was when during the course of development directory structure/config filename had to be changed but remnants of a build with old directory structure/config file were present. Again manually deleting the files mentioned above got things working. Deleting the files manually may not be correct way of fixing this issue but I thought it might help if you are stuck. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding the config.mk in U-boot TOP directory
Thanks Vaibhav! I will check this out. Regards, Shyama. -Original Message- From: Bedia, Vaibhav [mailto:vaibhav.be...@ti.com] Sent: Friday, December 31, 2010 9:43 AM To: Asokan, Shyama Trikkadeeri; U-Boot@lists.denx.de Subject: RE: [U-Boot] Regarding the config.mk in U-boot TOP directory On Thursday, December 30, 2010 6:51 PM, Asokan, Shyama Trikkadeeri wrote: Hi Wolfgang, I have been facing an issue while building u-boot for AT91SAM9263ek board. The environment I am using is CYGWIN and toolchain is the Code sourcery toolchain. The make configuration step works fine while make CROSS_COMPILE step throws the following error: make CROSS_COMPILE=arm-none-linux-gnueabi- Generating include/autoconf.mk include/common.h:37: fatal error: config.h: No such file or directory compilation terminated. Generating include/autoconf.mk.dep include/common.h:37: fatal error: config.h: No such file or directory compilation terminated. make: *** [include/autoconf.mk.dep] Error 1 While going through the files in u-boot I made the following observations: [...] I had similar issues some time back but the build environment was not Cygwin. I was working on adding support for a board on one GIT branch and after building an image (without a distclean) shifted to another branch which didn't have the board support added. Compiling u-boot for a different board on the second branch threw up errors like you mentioned. Even distclean didn't help. This was probably due to the auto-generated files depending on a board config which wasn't in the branch I was working on. I was able to finally get things working by manually deleting include/config.h, include/config.mk, include/autoconf.mk and include/autoconf.mk.dep A couple of more instances where I got the errors was when during the course of development directory structure/config filename had to be changed but remnants of a build with old directory structure/config file were present. Again manually deleting the files mentioned above got things working. Deleting the files manually may not be correct way of fixing this issue but I thought it might help if you are stuck. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/8] imximage: Add MX53 boot image support
Hi, Stefano,
2010/12/31 Jason Liu liu.h.ja...@gmail.com:
Hi, Stefano,
2010/12/30 Stefano Babic sba...@denx.de:
On 12/29/2010 01:49 PM, Jason Liu wrote:
This patch add the MX53 boot image support.
@@ -82,44 +213,91 @@ static int imximage_check_image_types(uint8_t type)
static int imximage_verify_header(unsigned char *ptr, int image_size,
struct mkimage_params *params)
{
-
struct imx_header *imx_hdr = (struct imx_header *) ptr;
- flash_header_t *hdr = imx_hdr-fhdr;
+ flash_header_v1_t *fhdr = imx_hdr-header.hdr_v1.fhdr;
+
+ if (imx_hdr-imximage_version != IMXIMAGE_V1)
+ return 0;
I think this is not correct. mkimage can be called with -l option to
check the correctness of the produced image without an imximage.cfg
file, and from your code it seems to me that actual images are not
recognized anymore. In fact, you recognize the header from a version
field that you add in the header, but it is not actually provided.
You should find the version of the header checking its structure, for
example recognizing APP_CODE_BARKER and DCD_BARKER for V1, and for
example DCD_HEADER_TAG for V2.
Please note that print_header and verify_header are part of the mkimage
API (in imximage_params table), and they are called by mkimage
independently without parsing any configuration file.
+static void imximage_print_header(const void *ptr)
+{
+ struct imx_header *imx_hdr = (struct imx_header *) ptr;
+
+ switch (imx_hdr-imximage_version) {
As I said, this does not work with actual images. The tool should be
able to recognize the version directly from its structure (we have
enough magic numbers, or better, barkers, to do it), and not storing the
version into the header.
OK, make sense. I get your mean. I will do the change.
But, I did think again about your comments. If we store the version
into the header which
will make the version check more easier, the side-effect is that we
store some boot
ROM useless information into the header, but which should not bring some issues.
mkimage -l can work with the actual images if the version info stored
into the head.
Here is the log I get:
r64...@r64343-desktop:~/work_space/u-boot-upstream/u-boot$
./tools/mkimage -l u-boot.imx
Image Type: Freescale IMX Boot Image
Image Ver:1 (i.MX25/35/51 compatible)
Data Size:170936 Bytes = 166.93 kB = 0.16 MB
Load Address: 977ff7fc
Entry Point: 9780
What's you comments?
Thanks for the review.
Happy New Year!
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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common/dlmalloc: support reinit bin for fast reset
There are several way to reset the u-boot.
Some platform will use watchdog timeout to reset the system.
Some platfrom will jump to 0x0 to reload the u-boot.
Some platform will jump to CONFIG_SYS_TEXT_BASE to do fast reset.
This patch fixed the problem of static varible didn't cleared on
the platforms which CONFIG_SKIP_LOWLEVEL_INIT is enabled and do
software reset by simply jump to the address CONFIG_SYS_TEXT_BASE.
This patch also introduce a new define named CONFIG_FAST_RESET for
developer to distinguish this method from other reset methods.
Signed-off-by: Macpaul Lin macp...@andestech.com
---
README| 10 ++
common/dlmalloc.c | 24
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 1acf9a3..ec00294 100644
--- a/README
+++ b/README
@@ -2846,6 +2846,16 @@ Low Level (hardware related) configuration options:
other boot loader or by a debugger which performs
these initializations itself.
+- CONFIG_FAST_RESET
+ If both CONFIG_SKIP_LOWLEVEL_INIT and this varible is defined,
+ the system could use do fast software reset by simply reinit
+ dlmalloc module then jump to the starting address
+ CONFIG_SYS_TEXT_BASE.
+
+ To use this feature, the extern function reinit_malloc_pool()
+ in dlmalloc.c should be called inside
+ reset_cpu(CONFIG_SYS_TEXT_BASE).
+
- CONFIG_PRELOADER
Modifies the behaviour of start.S when compiling a loader
that is executed before the actual U-Boot. E.g. when
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index e9bab09..97849a5 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -3233,6 +3233,30 @@ int mALLOPt(param_number, value) int param_number; int
value;
}
}
+#if defined(CONFIG_FAST_RESET) || defined(CONFIG_SKIP_LOWLEVEL_INIT)
+void reinit_bin()
+{
+ int i = 0;
+
+ av_[0] = 0;
+ av_[1] = 0;
+
+ for (i = 0; i NAV ; i++) {
+ av_[i*2+2] = bin_at(i);
+ av_[i*2+2+1] = bin_at(i);
+ }
+}
+
+extern void reinit_malloc_pool()
+{
+ /* fast reset sbrk_base */
+ sbrk_base = (char *)(-1);
+
+ /* re-initial bin */
+ reinit_bin();
+}
+#endif
+
/*
History:
--
1.7.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dlmalloc: sbrk_base error after cpu reset.
HI all, 2010/12/24 Macpaul Lin macp...@gmail.com: Dear Wolfgang, 2010/12/23 Wolfgang Denk w...@denx.de: Dear Macpaul Lin, In message macp...@gmail.com you wrote: The problem is that, after the command reset under u-boot console. The cpu will do flush I/D cache , disable interrupt , redo mem_malloc_init(). Then redo the init process. I'm not sure I understand what you mean. This shouds as if the reset command in U-Boot woul perform just apartial re-initialization of the software, but not a real hardware reset of the board? Yes, the reset in this problem is meant to the software reset command which could be manually executed from console. If the reset command in u-boot just do apartial re-initialization, then I think the problem could not to allocate memory might be some static variable wasn't cleared after the reset process. This problem (couldn't do malloc after reset) has been solved with patch [PATCH] common/dlmalloc: support reinit bin for fast reset for platforms enabled CONFIG_SKIP_LOWLEVEL_INIT and do reset_cpu(CONFIG_SYS_TEXT_BASE). -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/dlmalloc: support reinit bin for fast reset
On Friday, December 31, 2010 02:13:48 Macpaul Lin wrote: There are several way to reset the u-boot. Some platform will use watchdog timeout to reset the system. Some platfrom will jump to 0x0 to reload the u-boot. Some platform will jump to CONFIG_SYS_TEXT_BASE to do fast reset. This patch fixed the problem of static varible didn't cleared on the platforms which CONFIG_SKIP_LOWLEVEL_INIT is enabled and do software reset by simply jump to the address CONFIG_SYS_TEXT_BASE. i have no idea what CONFIG_SKIP_LOWLEVEL_INIT is, so i cant really comment on what you're trying to do +void reinit_bin() needs to be (void) +extern void reinit_malloc_pool() here too, and putting extern on the actual func def makes no sense -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
