[U-Boot] [PATCH v2] fsl_pci_init_port end-point initialization is broken
commit 70ed869e broke fsl pcie end-point initialization.
Returning 0 is not correct. The function must return the first free
bus number for the next controller.
fsl_pci_init() must still be called and a bus allocated even if the
controller is an end-point.
Signed-off-by: Ed Swarthout
Acked-by: Vivek Mahajan
Signed-off-by: Kumar Gala
---
Guys, I want to revert commit 70ed869e and replace it with this. There is
no reason to pass in pci_ep we can determine that internally. I will also
change the board code to use fsl_is_pci_agent and kill off
is_fsl_pci_agent (post november u-boot release).
Can one of you test this out.
- k
drivers/pci/fsl_pci_init.c | 18 +-
include/asm-ppc/fsl_pci.h |1 +
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index 87944bf..170cc25 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2007 Freescale Semiconductor, Inc.
+ * Copyright 2007-2009 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
@@ -42,6 +42,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define FSL_PCI_PBFR 0x44
#define FSL_PCIE_CAP_ID0x4c
#define FSL_PCIE_CFG_RDY 0x4b0
+#define FSL_PROG_IF_AGENT 0x1
void pciauto_prescan_setup_bridge(struct pci_controller *hose,
pci_dev_t dev, int sub_bus);
@@ -412,6 +413,16 @@ void fsl_pci_init(struct pci_controller *hose, u32
cfg_addr, u32 cfg_data)
}
}
+int fsl_is_pci_agent(struct pci_controller *hose)
+{
+ u8 prog_if;
+ pci_dev_t dev = PCI_BDF(hose->first_busno, 0, 0);
+
+ pci_hose_read_config_byte(hose, dev, PCI_CLASS_PROG, &prog_if);
+
+ return (prog_if == FSL_PROG_IF_AGENT);
+}
+
int fsl_pci_init_port(struct fsl_pci_info *pci_info,
struct pci_controller *hose, int busno)
{
@@ -450,6 +461,11 @@ int fsl_pci_init_port(struct fsl_pci_info *pci_info,
fsl_pci_init(hose, (u32)&pci->cfg_addr, (u32)&pci->cfg_data);
+ if (fsl_is_pci_agent(hose)) {
+ fsl_pci_config_unlock(hose);
+ hose->last_busno = hose->first_busno;
+ }
+
printf("PCIE%x on bus %02x - %02x\n", pci_info->pci_num,
hose->first_busno, hose->last_busno);
diff --git a/include/asm-ppc/fsl_pci.h b/include/asm-ppc/fsl_pci.h
index 2790da7..a5f72f5 100644
--- a/include/asm-ppc/fsl_pci.h
+++ b/include/asm-ppc/fsl_pci.h
@@ -25,6 +25,7 @@
int is_fsl_pci_agent(enum law_trgt_if trgt, u32 host_agent);
int is_fsl_pci_cfg(enum law_trgt_if trgt, u32 io_sel);
+int fsl_is_pci_agent(struct pci_controller *hose);
void fsl_pci_init(struct pci_controller *hose, u32 cfg_addr, u32 cfg_data);
void fsl_pci_config_unlock(struct pci_controller *hose);
void ft_fsl_pci_setup(void *blob, const char *pci_alias,
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc: Update README about the new GOT ptr.
r14 is no longer used as non volatile GOT ptr. Instead the volatile r12 is used so be sure to do GET_GOT in asm code when you need to access global data. Signed-off-by: Joakim Tjernlund --- README |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/README b/README index 744f6bf..bfd9498 100644 --- a/README +++ b/README @@ -3916,7 +3916,9 @@ For PowerPC, the following registers have specific use: R30:GOT pointer R31:frame pointer - (U-Boot also uses R14 as internal GOT pointer.) + (U-Boot also uses R12 as internal GOT pointer. r12 + is a volatile register so r12 needs to be reset when + going back and forth between asm and C) ==> U-Boot will use R2 to hold a pointer to the global data -- 1.6.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] multiple partitions in mtdparts
Am Mittwoch 04 November 2009 01:34:53 schrieb myub...@fastmail.fm:
> Hi,
>
> I am trying to define multiple partitions using mtdparts variable. But I
> can't get it set automatically right.
>
> I defined the set_bootargs as the following:
> set_bootargs=setenv bootargs root=/dev/mtdblock2 rootfs=cramfs,jffs2
> mtdparts=ph
> ysmap-flash.0:256k(u-boot),256k(u-boot-env),7936k(root1),7936k(root2);physmap-fl
> ash.1:16384k(data) console=ttyS0,115200n8
>
> But when I run set_bootargs, I got the following error -
> # run set_bootargs
> Unknown command 'physmap-flash.1:16384k(data)' - try 'help'
> Can someone help me with the correct format on mtdparts? thanks a lot.
>
I don't know the exact format but it looks like the ";" between
(root2);physmap-flash1 causes your error?
Dieter
>
>
> mtdparts=mtdparts=physmap-flash.0:256k(u-boot),256k(u-boot-env),7936k(root1),793
> 6k(root2);physmap-flash.1:16384k(data)
> boot=run set_bootargs;chpart nor0,${boot_device};fsload
> boot/uImage;bootm
> mtdids=nor0=physmap-flash.0,nor1=physmap-flash.1
> partition=nor0,2
> mtddevnum=2
> mtddevname=root1
> set_bootargs=setenv bootargs root=/dev/mtdblock2 rootfs=cramfs,jffs2
> mtdparts=ph
> ysmap-flash.0:256k(u-boot),256k(u-boot-env),7936k(root1),7936k(root2);physmap-fl
> ash.1:16384k(data) console=ttyS0,115200n8
> bootargs=root=/dev/mtdblock2 rootfs=cramfs,jffs2
> mtdparts=physmap-flash.0:256k(u
> -boot),256k(u-boot-env),7936k(root1),7936k(root2)
>
> Environment size: 847/262140 bytes
> # run set_bootargs
> Unknown command 'physmap-flash.1:16384k(data)' - try 'help'
> #
> ___
> 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 ARM] Move s3c24x0 header files to asm-arm/arch-s3c24x0/
Dear Kevin Morfitt, 2009/11/3 kevin.morf...@fearnside-systems.co.uk : > This patch moves the s3c24x0 header files from include/ to > include/asm-arm/arch-s3c24x0/. > > checkpatch.pl showed 2 errors and 3 warnings. The 2 errors were both due > to a non-UTF8 character in David M?ller's name: > > ERROR: Invalid UTF-8, patch and commit message should be encoded in UTF-8 > #489: FILE: include/asm-arm/arch-s3c24x0/s3c2410.h:3: > + * David M?ller ELSOFT AG Switzerland. d.muel...@elsoft.ch > > As David's name correctly contains a non-UTF8 character I haven't fixed > these errors. > > The 3 warnings were all because of the use of 'volatile' in s3c24x0.h: > > WARNING: Use of volatile is usually wrong: see > Documentation/volatile-considered-harmful.txt > #673: FILE: include/asm-arm/arch-s3c24x0/s3c24x0.h:35: > +typedef volatile u8 S3C24X0_REG8; > +typedef volatile u16 S3C24X0_REG16; > +typedef volatile u32 S3C24X0_REG32; > > I'll fix these errors in another patch. > > Tested by running MAKEALL for ARM8 targets and ensuring there were no new > errors or warnings. > > Signed-off-by: Kevin Morfitt > --- > board/mpl/vcma9/vcma9.c | 2 +- > board/mpl/vcma9/vcma9.h | 2 +- > board/samsung/smdk2400/smdk2400.c | 2 +- > board/samsung/smdk2410/smdk2410.c | 2 +- > board/sbc2410x/sbc2410x.c | 2 +- > board/trab/cmd_trab.c | 2 +- > board/trab/rs485.c | 2 +- > board/trab/rs485.h | 2 +- > board/trab/trab.c | 2 +- > board/trab/trab_fkt.c | 2 +- > board/trab/tsc2000.c | 2 +- > board/trab/vfd.c | 2 +- > cpu/arm920t/s3c24x0/interrupts.c | 4 +- > cpu/arm920t/s3c24x0/speed.c | 4 +- > cpu/arm920t/s3c24x0/timer.c | 4 +- > cpu/arm920t/s3c24x0/usb.c | 4 +- > cpu/arm920t/s3c24x0/usb_ohci.c | 4 +- > drivers/i2c/s3c24x0_i2c.c | 4 +- > drivers/mtd/nand/s3c2410_nand.c | 2 +- > drivers/rtc/s3c24x0_rtc.c | 4 +- > drivers/serial/serial_s3c24x0.c | 4 +- > include/asm-arm/arch-s3c24x0/s3c2400.h | 136 +++ > include/asm-arm/arch-s3c24x0/s3c2410.h | 146 +++ > include/asm-arm/arch-s3c24x0/s3c24x0.h | 656 > > include/s3c2400.h | 136 --- > include/s3c2410.h | 146 --- > include/s3c24x0.h | 656 > > 27 files changed, 967 insertions(+), 967 deletions(-) > create mode 100644 include/asm-arm/arch-s3c24x0/s3c2400.h > create mode 100644 include/asm-arm/arch-s3c24x0/s3c2410.h > create mode 100644 include/asm-arm/arch-s3c24x0/s3c24x0.h > delete mode 100644 include/s3c2400.h > delete mode 100644 include/s3c2410.h > delete mode 100644 include/s3c24x0.h > applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot for iMX27 board
On Tue, Nov 3, 2009 at 10:26 PM, Intur Venkatesulu wrote: > Hi, > > > > Please clarify the following regarding u-boot. > > > > Will u-boot imx27 Target board, if yes pl send me this link for down loading > u-boot > > > > Regards, > > Venkatesulu Venkatesulu, There is support for the imx27 in u-boot, at least in the latest git version (http://git.denx.de/?p=u-boot.git;a=summary). Have a look at the imx27lite config. I don't know the current status of all the drivers, but I had a hacked version of it working a few months ago. thanks, Paul ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] v2 Linuxstamp II 9260 support
This adds CONFIG_AT91_ALT_EPINS to avoid using board configs in at91sam9260_devices.c. In adding this config at91sam9260ek.h afeb9260.h were changed, this should probabbly be tested for those 2 boards. --- MAINTAINERS |4 + MAKEALL |1 + Makefile |3 + board/ls9260/Makefile| 56 board/ls9260/config.mk |1 + board/ls9260/led.c | 41 ++ board/ls9260/ls9260.c| 199 +++ board/ls9260/partition.c | 40 ++ cpu/arm926ejs/at91/at91sam9260_devices.c |2 +- include/asm-arm/mach-types.h | 13 ++ include/configs/afeb9260.h |3 + include/configs/at91sam9260ek.h |3 + include/configs/ls9260.h | 219 ++ 13 files changed, 584 insertions(+), 1 deletions(-) create mode 100644 board/ls9260/Makefile create mode 100644 board/ls9260/config.mk create mode 100644 board/ls9260/led.c create mode 100644 board/ls9260/ls9260.c create mode 100644 board/ls9260/partition.c create mode 100644 include/configs/ls9260.h diff --git a/MAINTAINERS b/MAINTAINERS index d70a9d2..2518757 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -718,6 +718,10 @@ Albin Tonnerre tny_a9260 ARM926EJS (AT91SAM9260 SoC) tny_a9g20 ARM926EJS (AT91SAM9G20 SoC) +Paul Thomas + + ls9260 ARM926EJS (AT91SAM9260 SoC) + Greg Ungerer cm4008 ks8695p diff --git a/MAKEALL b/MAKEALL index d63c5c2..5104607 100755 --- a/MAKEALL +++ b/MAKEALL @@ -653,6 +653,7 @@ LIST_at91=" \ SBC35_A9G20 \ TNY_A9260 \ TNY_A9G20 \ + ls9260 \ " # diff --git a/Makefile b/Makefile index bcb3fe9..a697235 100644 --- a/Makefile +++ b/Makefile @@ -2761,6 +2761,9 @@ at91sam9g20ek_config : unconfig fi; @$(MKCONFIG) -a at91sam9260ek arm arm926ejs at91sam9260ek atmel at91 +ls9260_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs ls9260 NULL at91 + at91sam9xeek_nandflash_config \ at91sam9xeek_dataflash_cs0_config \ at91sam9xeek_dataflash_cs1_config \ diff --git a/board/ls9260/Makefile b/board/ls9260/Makefile new file mode 100644 index 000..28e0947 --- /dev/null +++ b/board/ls9260/Makefile @@ -0,0 +1,56 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Stelian Pop +# Lead Tech Design +# +# See file CREDITS for list of people who contributed to this +# project. +# +# 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. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS-y+= ls9260.o +COBJS-y+= led.o +COBJS-$(CONFIG_HAS_DATAFLASH) += partition.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) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/ls9260/config.mk b/board/ls9260/config.mk new file mode 100644 index 000..9ce161e --- /dev/null +++ b/board/ls9260/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0x21f0 diff --git a/board/ls9260/led.c b/board/ls9260/led.c new file mode 100644 index 000..2424d27 --- /dev/null +++ b/board/ls9260/led.c @@ -0,0 +1,41 @@ +/* + * (C) Copyright 2007-2008 + * Stelian Pop + * Lead Tech Design + * + * See file CREDITS for list of people who contributed to this + * project. + * + * 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
[U-Boot] u-boot for iMX27 board
Hi, Please clarify the following regarding u-boot. Will u-boot imx27 Target board, if yes pl send me this link for down loading u-boot Regards, Venkatesulu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc: Move conditional compilation of kgdb.c to Makefile
Signed-off-by: Peter Tyser --- lib_ppc/Makefile |2 +- lib_ppc/kgdb.c |5 - 2 files changed, 1 insertions(+), 6 deletions(-) diff --git a/lib_ppc/Makefile b/lib_ppc/Makefile index 452107c..68b70b0 100644 --- a/lib_ppc/Makefile +++ b/lib_ppc/Makefile @@ -35,7 +35,7 @@ COBJS-y += bootm.o COBJS-y+= cache.o COBJS-y+= extable.o COBJS-y+= interrupts.o -COBJS-y+= kgdb.o +COBJS-$(CONFIG_CMD_KGDB) += kgdb.o COBJS-y+= time.o SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c) diff --git a/lib_ppc/kgdb.c b/lib_ppc/kgdb.c index 78c2f0c..d3eb1f3 100644 --- a/lib_ppc/kgdb.c +++ b/lib_ppc/kgdb.c @@ -1,8 +1,5 @@ #include #include - -#if defined(CONFIG_CMD_KGDB) - #include #include #include @@ -322,5 +319,3 @@ kgdb_breakpoint(int argc, char *argv[]) breakinst: .long 0x7d821008\n\ "); } - -#endif -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] [OneNAND] Flex-OneNAND driver support
Hi Scott,
>> +static loff_t flexonenand_addr(struct onenand_chip *this, int block)
>> +{
>> + loff_t ofs = 0;
>> + int die = 0, boundary;
>> +
>> + if (ONENAND_IS_DDP(this) && block >= this->density_mask) {
>> + block -= this->density_mask;
>> + die = 1;
>> + ofs = this->diesize[0];
>> + }
>> +
>> + boundary = this->boundary[die];
>> + ofs += block << (this->erase_shift - 1);
>> + if (block > (boundary + 1))
>> + ofs += (block - boundary - 1) << (this->erase_shift - 1);
>> + return ofs;
>
> You're missing some (loff_t) casts that are in Linux, here and elsewhere.
>
Accepted and corrected
>> +inline loff_t onenand_addr(struct onenand_chip *this, int block)
>
> This is not a header file; let GCC decide when to inline. Note that this
> function is not specified as inline in Linux.
>
Accepted and corrected
> There are some other fairly significant differences with Linux later in
> the patch -- is this due to missing functionality that u-boot doesn't
> need, or something else?
>
Yes, there are certain functionalities that OneNAND doesn't need in U-Boot.
Sending the updated patches.
Regards,
Amul Kumar Saha
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] [OneNAND] Flex-OneNAND driver support
Hi Scott, > > You seem to have stripped a copyright notice that was added in the Linux > version of patch 1/3. > Updated in the current patch. Regards, Amul Kumar Saha ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] [OneNAND] Flex-OneNAND boundary settings
Add command for changing Flex-OneNAND SLC / MLC boundary.
Also onenand commands work for Flex-OneNAND.
Signed-off-by: Rohit Hagargundgi
Signed-off-by: Amul Kumar Saha
---
common/cmd_onenand.c | 90 +-
include/configs/apollon.h |2 -
2 files changed, 66 insertions(+), 26 deletions(-)
diff --git a/common/cmd_onenand.c b/common/cmd_onenand.c
index 9090940..a34befe 100644
--- a/common/cmd_onenand.c
+++ b/common/cmd_onenand.c
@@ -69,36 +69,49 @@ static int arg_off_size(int argc, char *argv[], ulong *off,
size_t *size)
return 0;
}
+static inline int onenand_blocksize(loff_t ofs)
+{
+ struct onenand_chip *this = mtd->priv;
+ int i;
+
+ if (!FLEXONENAND(this))
+ return mtd->erasesize;
+
+ i = flexonenand_region(mtd, ofs);
+ return mtd->eraseregions[i].erasesize;
+}
+
static int onenand_block_read(loff_t from, size_t len,
size_t *retlen, u_char *buf, int oob)
{
struct onenand_chip *this = mtd->priv;
- int blocks = (int) len >> this->erase_shift;
- int blocksize = (1 << this->erase_shift);
+ int blocks = (int) onenand_block(this, from + len)
+- onenand_block(this, from);
+ int blocksize;
loff_t ofs = from;
struct mtd_oob_ops ops = {
.retlen = 0,
};
int ret;
- if (oob)
- ops.ooblen = blocksize;
- else
- ops.len = blocksize;
-
while (blocks) {
+ blocksize = onenand_blocksize(ofs);
+
ret = mtd->block_isbad(mtd, ofs);
if (ret) {
printk("Bad blocks %d at 0x%x\n",
- (u32)(ofs >> this->erase_shift), (u32)ofs);
+ (u32)onenand_block(this, ofs), (u32)ofs);
ofs += blocksize;
continue;
}
- if (oob)
+ if (oob) {
ops.oobbuf = buf;
- else
+ ops.ooblen = blocksize;
+ } else {
ops.datbuf = buf;
+ ops.len = blocksize;
+ }
ops.retlen = 0;
ret = mtd->read_oob(mtd, ofs, &ops);
@@ -120,8 +133,7 @@ static int onenand_block_write(loff_t to, size_t len,
size_t *retlen, const u_char * buf)
{
struct onenand_chip *this = mtd->priv;
- int blocks = len >> this->erase_shift;
- int blocksize = (1 << this->erase_shift);
+ int blocks, blocksize;
loff_t ofs;
size_t _retlen = 0;
int ret;
@@ -135,11 +147,16 @@ static int onenand_block_write(loff_t to, size_t len,
}
ofs = to;
+ blocks = (int) onenand_block(this, ofs + len)
+ - onenand_block(this, ofs);
+
while (blocks) {
+ blocksize = onenand_blocksize(ofs);
+
ret = mtd->block_isbad(mtd, ofs);
if (ret) {
printk("Bad blocks %d at 0x%x\n",
- (u32)(ofs >> this->erase_shift), (u32)ofs);
+ (u32)onenand_block(this, ofs), (u32)ofs);
skip_ofs += blocksize;
goto next;
}
@@ -169,13 +186,15 @@ static int onenand_block_erase(u32 start, u32 size, int
force)
};
loff_t ofs;
int ret;
- int blocksize = 1 << this->erase_shift;
+ int blocksize;
for (ofs = start; ofs < (start + size); ofs += blocksize) {
+ blocksize = onenand_blocksize(ofs);
+
ret = mtd->block_isbad(mtd, ofs);
if (ret && !force) {
printf("Skip erase bad block %d at 0x%x\n",
- (u32)(ofs >> this->erase_shift), (u32)ofs);
+ (u32)onenand_block(this, ofs), (u32)ofs);
continue;
}
@@ -186,7 +205,7 @@ static int onenand_block_erase(u32 start, u32 size, int
force)
ret = mtd->erase(mtd, &instr);
if (ret) {
printf("erase failed block %d at 0x%x\n",
- (u32)(ofs >> this->erase_shift), (u32)ofs);
+ (u32)onenand_block(this, ofs), (u32)ofs);
continue;
}
}
@@ -223,25 +242,28 @@ static int onenand_block_test(u32 start, u32 size)
return -1;
}
- start_block = start >> this->erase_shift;
- end_block = (start + size) >> this->erase_shift;
+ start_block = onenand_block(this, start);
+ end_block = onenand_block(this, start + size);
/* Protect boot-loader from badblock testing */
if (start_block < 2)
start_block = 2;
- if (end_
Re: [U-Boot] [PATCH 2/3] [OneNAND] ENV Variable support for Flex-OneNAND
Define and use CONFIG_ENV_ADDR_FLEX and CONFIG_ENV_SIZE_FLEX
for storing environment variables.
Signed-off-by: Rohit Hagargundgi
Signed-off-by: Amul Kumar Saha
---
common/env_onenand.c | 10 ++
include/configs/apollon.h |2 ++
2 files changed, 12 insertions(+)
diff --git a/common/env_onenand.c b/common/env_onenand.c
index dcf09de..23d2caa 100644
--- a/common/env_onenand.c
+++ b/common/env_onenand.c
@@ -60,11 +60,14 @@ uchar env_get_char_spec(int index)
void env_relocate_spec(void)
{
struct mtd_info *mtd = &onenand_mtd;
+ struct onenand_chip *this = &onenand_chip;
loff_t env_addr;
int use_default = 0;
size_t retlen;
env_addr = CONFIG_ENV_ADDR;
+ if (FLEXONENAND(this))
+ env_addr = CONFIG_ENV_ADDR_FLEX;
/* Check OneNAND exist */
if (mtd->writesize)
@@ -91,6 +94,7 @@ void env_relocate_spec(void)
int saveenv(void)
{
struct mtd_info *mtd = &onenand_mtd;
+ struct onenand_chip *this = &onenand_chip;
loff_t env_addr = CONFIG_ENV_ADDR;
struct erase_info instr = {
.callback = NULL,
@@ -98,6 +102,12 @@ int saveenv(void)
size_t retlen;
instr.len = CONFIG_ENV_SIZE;
+ if (FLEXONENAND(this)) {
+ env_addr = CONFIG_ENV_ADDR_FLEX;
+ instr.len = CONFIG_ENV_SIZE_FLEX;
+ instr.len <<= onenand_mtd.eraseregions[0].numblocks == 1 ?
+ 1 : 0;
+ }
instr.addr = env_addr;
instr.mtd = mtd;
if (mtd->erase(mtd, &instr)) {
diff --git a/include/configs/apollon.h b/include/configs/apollon.h
index 575f60e..ddac5fb 100644
--- a/include/configs/apollon.h
+++ b/include/configs/apollon.h
@@ -76,6 +76,7 @@
* Size of malloc() pool
*/
#defineCONFIG_ENV_SIZE SZ_128K /* Total Size of Environment Sector */
+#define CONFIG_ENV_SIZE_FLEX SZ_256K
#defineCONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + SZ_1M)
/* bytes reserved for initial data */
#defineCONFIG_SYS_GBL_DATA_SIZE128
@@ -255,6 +256,7 @@
#define CONFIG_SYS_MONITOR_LEN SZ_256K /* U-Boot image size */
#defineCONFIG_ENV_IS_IN_ONENAND1
#define CONFIG_ENV_ADDR0x0002
+#define CONFIG_ENV_ADDR_FLEX 0x0004
#define CONFIG_SYS_64BIT_VSPRINTF /* needed for nand_util.c */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] [OneNAND] Flex-OneNAND driver support
This patch adds support for Flex-OneNAND devices.
Signed-off-by: Rohit Hagargundgi
Signed-off-by: Amul Kumar Saha
---
drivers/mtd/onenand/onenand_base.c | 740 +++-
drivers/mtd/onenand/onenand_bbt.c | 14
drivers/mtd/onenand/onenand_uboot.c |4
include/linux/mtd/onenand.h | 16
include/linux/mtd/onenand_regs.h| 18
include/onenand_uboot.h | 10
6 files changed, 701 insertions(+), 101 deletions(-)
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 368fa6e..16814e7 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -9,6 +9,11 @@
* auto-placement support, read-while load support, various fixes
* Copyright (C) Nokia Corporation, 2007
*
+ * Rohit Hagargundgi ,
+ * Amul Kumar Saha :
+ * Flex-OneNAND support
+ * Copyright (C) Samsung Electronics, 2009
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
@@ -24,7 +29,7 @@
#include
/* It should access 16-bit instead of 8-bit */
-static inline void *memcpy_16(void *dst, const void *src, unsigned int len)
+static void *memcpy_16(void *dst, const void *src, unsigned int len)
{
void *ret = dst;
short *d = dst;
@@ -37,6 +42,27 @@ static inline void *memcpy_16(void *dst, const void *src,
unsigned int len)
}
/**
+ * onenand_oob_128 - oob info for Flex-Onenand with 4KB page
+ * For now, we expose only 64 out of 80 ecc bytes
+ */
+static struct nand_ecclayout onenand_oob_128 = {
+ .eccbytes = 64,
+ .eccpos = {
+ 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
+ 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
+ 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
+ 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
+ 70, 71, 72, 73, 74, 75, 76, 77, 78, 79,
+ 86, 87, 88, 89, 90, 91, 92, 93, 94, 95,
+ 102, 103, 104, 105
+ },
+ .oobfree= {
+ {2, 4}, {18, 4}, {34, 4}, {50, 4},
+ {66, 4}, {82, 4}, {98, 4}, {114, 4}
+ }
+};
+
+/**
* onenand_oob_64 - oob info for large (2KB) page
*/
static struct nand_ecclayout onenand_oob_64 = {
@@ -74,6 +100,14 @@ static const unsigned char ffchars[] = {
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 48 */
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 64 */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 80 */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 96 */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 112 */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 128 */
};
/**
@@ -180,6 +214,85 @@ static int onenand_buffer_address(int dataram1, int
sectors, int count)
}
/**
+ * flexonenand_block - Return block number for flash address
+ * @param this - OneNAND device structure
+ * @param addr - Address for which block number is needed
+ */
+static unsigned int flexonenand_block(struct onenand_chip *this, loff_t addr)
+{
+ unsigned int boundary, blk, die = 0;
+
+ if (ONENAND_IS_DDP(this) && addr >= this->diesize[0]) {
+ die = 1;
+ addr -= this->diesize[0];
+ }
+
+ boundary = this->boundary[die];
+
+ blk = addr >> (this->erase_shift - 1);
+ if (blk > boundary)
+ blk = (blk + boundary + 1) >> 1;
+
+ blk += die ? this->density_mask : 0;
+ return blk;
+}
+
+unsigned int onenand_block(struct onenand_chip *this, loff_t addr)
+{
+ if (!FLEXONENAND(this))
+ return addr >> this->erase_shift;
+ return flexonenand_block(this, addr);
+}
+
+/**
+ * flexonenand_addr - Return address of the block
+ * @this: OneNAND device structure
+ * @block: Block number on Flex-OneNAND
+ *
+ * Return address of the block
+ */
+static loff_t flexonenand_addr(struct onenand_chip *this, int block)
+{
+ loff_t ofs = 0;
+ int die = 0, boundary;
+
+ if (ONENAND_IS_DDP(this) && block >= this->density_mask) {
+ block -= this->density_mask;
+ die = 1;
+ ofs = this->diesize[0];
+ }
+
+ boundary = this->boundary[die];
+ ofs += (loff_t) block << (this->erase_shift - 1);
+ if (block > (boundary + 1))
+ ofs += (loff_t) (block - boundary - 1)
+ << (this->erase_shift - 1);
+ return ofs;
+}
+
+loff_t onenand_addr(struct onenand_chip *this, int block)
+{
+ if
[U-Boot] Joe Johnson has invited you as a colleauge to Work Kingdom
You have been invited to the most advanced business trade portal WorkKingdom Is A New Revolutionary System For Business Professionals World Wide. Benefit From Increased Revenues, Profits From Having Customers, Suppliers Contact You For Networking/trade Possibilities. Its A Totally 100 Percent No Cost Service Find You The Best Prices, From Businesses Around The Globe Increase Exposure, Revenue, Profits Increase Trade Locally And Globally Locate Customers, Suppliers, Vendors Offer World Class Privacy Features Reduce Operating And Overhead Expenses Find Jobs, Colleagues, Industry Leaders Vist our site now and join at zero cost Send us a email with the subject remove removed forever ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Improve read performance of generic mmc.
In drivers/mmc/mmc.c, mmc_bread will do aligned read.
So we don't need to use single block read.
We can use multiblock read to improve the performance.
Signed-off-by: Terry Lv
---
drivers/mmc/mmc.c | 51 ---
1 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index b69ce15..53ca3a1 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -205,27 +205,56 @@ free_buffer:
static ulong mmc_bread(int dev_num, ulong start, lbaint_t blkcnt, void *dst)
{
+ struct mmc_cmd cmd;
+ struct mmc_data data;
int err;
- int i;
+ int stoperr = 0;
struct mmc *mmc = find_mmc_device(dev_num);
+ int blklen;
if (!mmc)
- return 0;
+ return -1;
- /* We always do full block reads from the card */
- err = mmc_set_blocklen(mmc, mmc->read_bl_len);
+ blklen = mmc->read_bl_len;
+
+ err = mmc_set_blocklen(mmc, blklen);
if (err) {
- return 0;
+ printf("set read bl len failed\n\r");
+ return err;
}
- for (i = start; i < start + blkcnt; i++, dst += mmc->read_bl_len) {
- err = mmc_read_block(mmc, dst, i);
+ if (blkcnt > 1)
+ cmd.cmdidx = MMC_CMD_READ_MULTIPLE_BLOCK;
+ else
+ cmd.cmdidx = MMC_CMD_READ_SINGLE_BLOCK;
- if (err) {
- printf("block read failed: %d\n", err);
- return i - start;
- }
+ if (mmc->high_capacity)
+ cmd.cmdarg = start;
+ else
+ cmd.cmdarg = start * blklen;
+
+ cmd.resp_type = MMC_RSP_R1;
+ cmd.flags = 0;
+
+ data.dest = dst;
+ data.blocks = blkcnt;
+ data.blocksize = blklen;
+ data.flags = MMC_DATA_READ;
+
+ err = mmc_send_cmd(mmc, &cmd, &data);
+
+ if (err) {
+ printf("mmc read failed\n\r");
+ return err;
+ }
+
+ if (blkcnt > 1) {
+ cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
+ cmd.cmdarg = 0;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.flags = 0;
+ stoperr = mmc_send_cmd(mmc, &cmd, NULL);
}
return blkcnt;
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Improve read performance of gerenic mmc.
Hi Mike,
Thanks~~
I will send another patch.
Yours
Terry
-Original Message-
From: Mike Frysinger [mailto:vap...@gentoo.org]
Sent: 2009年11月4日 10:56
To: u-boot@lists.denx.de
Cc: Lv Terry-R65388
Subject: Re: [U-Boot] [PATCH] Improve read performance of gerenic mmc.
On Tuesday 03 November 2009 21:36:58 Terry Lv wrote:
> Signed-off-by: Terry Lv
your subject has a spelling typo, and generally you should avoid using complete
sentences in it (i.e. drop the period).
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -88,7 +88,7 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t
> blkcnt, const void*src) err = mmc_set_blocklen(mmc,
> mmc->write_bl_len);
>
> if (err) {
> - printf("set write bl len failed\n\r");
> + puts("set write bl len failed\n\r");
> return err;
> }
>
> @@ -113,7 +113,7 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t
> blkcnt, const void*src) err = mmc_send_cmd(mmc, &cmd, &data);
>
> if (err) {
> - printf("mmc write failed\n\r");
> + puts("mmc write failed\n\r");
> return err;
> }
>
> @@ -164,7 +164,7 @@ int mmc_read(struct mmc *mmc, u64 src, uchar *dst,
> int
> size) buffer = malloc(blklen);
>
> if (!buffer) {
> - printf("Could not allocate buffer for MMC read!\n");
> + puts("Could not allocate buffer for MMC read!\n");
> return -1;
> }
these changes dont look related to your changelog at all
unrelated, but dont know why the code is doing \n\r ... it should only be doing
\n ...
> @@ -205,27 +205,56 @@ free_buffer:
>
> static ulong mmc_bread(int dev_num, ulong start, lbaint_t blkcnt,
> void
> *dst) {
> + struct mmc_cmd cmd;
> + struct mmc_data data;
> int err;
> - int i;
> + int stoperr = 0;
> struct mmc *mmc = find_mmc_device(dev_num);
> + int blklen;
>
> if (!mmc)
> - return 0;
> + return -1;
>
> - /* We always do full block reads from the card */
> - err = mmc_set_blocklen(mmc, mmc->read_bl_len);
> + blklen = mmc->read_bl_len;
> +
> + err = mmc_set_blocklen(mmc, blklen);
>
> if (err) {
> - return 0;
> + puts("set read bl len failed\n\r");
> + return err;
> }
>
> - for (i = start; i < start + blkcnt; i++, dst += mmc->read_bl_len) {
> - err = mmc_read_block(mmc, dst, i);
> + if (blkcnt > 1)
> + cmd.cmdidx = MMC_CMD_READ_MULTIPLE_BLOCK;
> + else
> + cmd.cmdidx = MMC_CMD_READ_SINGLE_BLOCK;
>
> - if (err) {
> - printf("block read failed: %d\n", err);
> - return i - start;
> - }
> + if (mmc->high_capacity)
> + cmd.cmdarg = start;
> + else
> + cmd.cmdarg = start * blklen;
> +
> + cmd.resp_type = MMC_RSP_R1;
> + cmd.flags = 0;
> +
> + data.dest = dst;
> + data.blocks = blkcnt;
> + data.blocksize = blklen;
> + data.flags = MMC_DATA_READ;
> +
> + err = mmc_send_cmd(mmc, &cmd, &data);
> +
> + if (err) {
> + puts("mmc read failed\n\r");
> + return err;
> + }
> +
> + if (blkcnt > 1) {
> + cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
> + cmd.cmdarg = 0;
> + cmd.resp_type = MMC_RSP_R1b;
> + cmd.flags = 0;
> + stoperr = mmc_send_cmd(mmc, &cmd, NULL);
> }
>
> return blkcnt;
i imagine the changes do wat you say, but you really should explain in your
changelog how/why your changes work -mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Improve read performance of gerenic mmc.
On Tuesday 03 November 2009 21:36:58 Terry Lv wrote:
> Signed-off-by: Terry Lv
your subject has a spelling typo, and generally you should avoid using
complete sentences in it (i.e. drop the period).
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -88,7 +88,7 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt,
> const void*src) err = mmc_set_blocklen(mmc, mmc->write_bl_len);
>
> if (err) {
> - printf("set write bl len failed\n\r");
> + puts("set write bl len failed\n\r");
> return err;
> }
>
> @@ -113,7 +113,7 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt,
> const void*src) err = mmc_send_cmd(mmc, &cmd, &data);
>
> if (err) {
> - printf("mmc write failed\n\r");
> + puts("mmc write failed\n\r");
> return err;
> }
>
> @@ -164,7 +164,7 @@ int mmc_read(struct mmc *mmc, u64 src, uchar *dst, int
> size) buffer = malloc(blklen);
>
> if (!buffer) {
> - printf("Could not allocate buffer for MMC read!\n");
> + puts("Could not allocate buffer for MMC read!\n");
> return -1;
> }
these changes dont look related to your changelog at all
unrelated, but dont know why the code is doing \n\r ... it should only be
doing \n ...
> @@ -205,27 +205,56 @@ free_buffer:
>
> static ulong mmc_bread(int dev_num, ulong start, lbaint_t blkcnt, void
> *dst) {
> + struct mmc_cmd cmd;
> + struct mmc_data data;
> int err;
> - int i;
> + int stoperr = 0;
> struct mmc *mmc = find_mmc_device(dev_num);
> + int blklen;
>
> if (!mmc)
> - return 0;
> + return -1;
>
> - /* We always do full block reads from the card */
> - err = mmc_set_blocklen(mmc, mmc->read_bl_len);
> + blklen = mmc->read_bl_len;
> +
> + err = mmc_set_blocklen(mmc, blklen);
>
> if (err) {
> - return 0;
> + puts("set read bl len failed\n\r");
> + return err;
> }
>
> - for (i = start; i < start + blkcnt; i++, dst += mmc->read_bl_len) {
> - err = mmc_read_block(mmc, dst, i);
> + if (blkcnt > 1)
> + cmd.cmdidx = MMC_CMD_READ_MULTIPLE_BLOCK;
> + else
> + cmd.cmdidx = MMC_CMD_READ_SINGLE_BLOCK;
>
> - if (err) {
> - printf("block read failed: %d\n", err);
> - return i - start;
> - }
> + if (mmc->high_capacity)
> + cmd.cmdarg = start;
> + else
> + cmd.cmdarg = start * blklen;
> +
> + cmd.resp_type = MMC_RSP_R1;
> + cmd.flags = 0;
> +
> + data.dest = dst;
> + data.blocks = blkcnt;
> + data.blocksize = blklen;
> + data.flags = MMC_DATA_READ;
> +
> + err = mmc_send_cmd(mmc, &cmd, &data);
> +
> + if (err) {
> + puts("mmc read failed\n\r");
> + return err;
> + }
> +
> + if (blkcnt > 1) {
> + cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
> + cmd.cmdarg = 0;
> + cmd.resp_type = MMC_RSP_R1b;
> + cmd.flags = 0;
> + stoperr = mmc_send_cmd(mmc, &cmd, NULL);
> }
>
> return blkcnt;
i imagine the changes do wat you say, but you really should explain in your
changelog how/why your changes work
-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
[U-Boot] ARM LED weak symbols
As discussed earlier today http://lists.denx.de/pipermail/u-boot/2009-November/063711.html This is the patch to conditionally compile the ARM board LED functions. It was regression tested with MAKEALL arm using the Code Sourcery 2009 compiler and my roll-your-own gcc-4.4.2 Both patches were runtested with the Code Sourcery compiler on Zoom2. Since this is a common patch, I would like to see it tested on other boards (hint). I will wait till tomorrow for comments and then push it to arm/next. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: fix build error with gcc-4.4.2 about inline function declared weak
From: Abdoulaye Walsimou Gaye
This patch fix build error with gcc-4.4.2 about inline function
declared weak, see below:
board.c:96: error: inline function 'coloured_LED_init' cannot be declared weak
board.c:98: error: inline function 'red_LED_on' cannot be declared weak
board.c:100: error: inline function 'red_LED_off' cannot be declared weak
board.c:102: error: inline function 'green_LED_on' cannot be declared weak
board.c:104: error: inline function 'green_LED_off' cannot be declared weak
board.c:106: error: inline function 'yellow_LED_on' cannot be declared weak
board.c:108: error: inline function 'yellow_LED_off' cannot be declared weak
board.c:110: error: inline function 'blue_LED_on' cannot be declared weak
board.c:112: error: inline function 'blue_LED_off' cannot be declared weak
make[1]: *** [board.o] Error 1
Signed-off-by: Abdoulaye Walsimou Gaye
---
lib_arm/board.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/lib_arm/board.c b/lib_arm/board.c
index 28b15da..2665093 100644
--- a/lib_arm/board.c
+++ b/lib_arm/board.c
@@ -94,23 +94,23 @@ extern void rtl8019_get_enetaddr (uchar * addr);
* May be supplied by boards if desired
*/
void inline __coloured_LED_init (void) {}
-void inline coloured_LED_init (void) __attribute__((weak,
alias("__coloured_LED_init")));
+void coloured_LED_init(void)__attribute__((weak,
alias("__coloured_LED_init")));
void inline __red_LED_on (void) {}
-void inline red_LED_on (void) __attribute__((weak, alias("__red_LED_on")));
+void red_LED_on(void) __attribute__((weak, alias("__red_LED_on")));
void inline __red_LED_off(void) {}
-void inline red_LED_off(void) __attribute__((weak,
alias("__red_LED_off")));
+void red_LED_off(void)__attribute__((weak, alias("__red_LED_off")));
void inline __green_LED_on(void) {}
-void inline green_LED_on(void) __attribute__((weak, alias("__green_LED_on")));
+void green_LED_on(void) __attribute__((weak, alias("__green_LED_on")));
void inline __green_LED_off(void) {}
-void inline green_LED_off(void)__attribute__((weak, alias("__green_LED_off")));
+void green_LED_off(void)__attribute__((weak, alias("__green_LED_off")));
void inline __yellow_LED_on(void) {}
-void inline yellow_LED_on(void)__attribute__((weak, alias("__yellow_LED_on")));
+void yellow_LED_on(void)__attribute__((weak, alias("__yellow_LED_on")));
void inline __yellow_LED_off(void) {}
-void inline yellow_LED_off(void)__attribute__((weak,
alias("__yellow_LED_off")));
+void yellow_LED_off(void)__attribute__((weak, alias("__yellow_LED_off")));
void inline __blue_LED_on(void) {}
-void inline blue_LED_on(void)__attribute__((weak, alias("__blue_LED_on")));
+void blue_LED_on(void)__attribute__((weak, alias("__blue_LED_on")));
void inline __blue_LED_off(void) {}
-void inline blue_LED_off(void)__attribute__((weak, alias("__blue_LED_off")));
+void blue_LED_off(void)__attribute__((weak, alias("__blue_LED_off")));
#endif
/
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for Linuxstamp II 9260
On Tuesday 03 November 2009 16:26:17 Paul Thomas wrote: > On Tue, Nov 3, 2009 at 2:21 PM, Mike Frysinger wrote: > > On Tuesday 03 November 2009 16:12:40 Paul Thomas wrote: > >> From: Paul Thomas > > > > looks like you need to fix your git environment & re-submit this patch > > Yeah, I saw it does that in git send-email, but the first prompt "Who > should the emails appear to be from?" is correct, and the email in the > .gitconfig is correct. I don't know where's it's pulling that info > from or why it's different from the prompt. It's very annoying. it's most likely encoded in the patch itself. the git-send-email question only asks about the From: field, not the author aspect. make sure your ~/.gitconfig is correct and has user.name and user.email set, then amend the patch (assuming it's the last changeset in your branch) by doing: git commit --amend --author 'Your Name ' that should reset all the relevant fields -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
[U-Boot] [PATCH 1/2] ARM Conditionally compile board LED functions
The ARM board LED functions are defined as weak.
They add a size overhead if they are not used.
Now they are only defined if CONFIG_STATUS_LED is also defined.
The arm920t and arm926ejs _start function calls these LED functions
bl coloured_LED_init
bl red_LED_on
In general, what happens is they call into the weak
stubs. Only if the cpu/board provides an overriding
function do these calls cause anything meaningful to
happen.
Now this noop case is removed and these LED functions are excuted
only when CONFIG_STATUS_LED is defined
Signed-off-by: Tom Rix
---
cpu/arm920t/start.S |4 ++--
cpu/arm926ejs/start.S |4 ++--
lib_arm/board.c |2 ++
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/cpu/arm920t/start.S b/cpu/arm920t/start.S
index 114427a..e05ebf3 100644
--- a/cpu/arm920t/start.S
+++ b/cpu/arm920t/start.S
@@ -113,10 +113,10 @@ start_code:
bic r0, r0, #0x1f
orr r0, r0, #0xd3
msr cpsr, r0
-
+#ifdef CONFIG_STATUS_LED
bl coloured_LED_init
bl red_LED_on
-
+#endif
#ifdefined(CONFIG_AT91RM9200DK) || defined(CONFIG_AT91RM9200EK)
/*
* relocate exception table
diff --git a/cpu/arm926ejs/start.S b/cpu/arm926ejs/start.S
index 4421b6a..117ffb1 100644
--- a/cpu/arm926ejs/start.S
+++ b/cpu/arm926ejs/start.S
@@ -183,10 +183,10 @@ clbss_l:str r2, [r0]/* clear
loop...*/
add r0, r0, #4
cmp r0, r1
ble clbss_l
-
+#ifdef CONFIG_STATUS_LED
bl coloured_LED_init
bl red_LED_on
-
+#endif
ldr pc, _start_armboot
_start_armboot:
diff --git a/lib_arm/board.c b/lib_arm/board.c
index 5e3d7f6..28b15da 100644
--- a/lib_arm/board.c
+++ b/lib_arm/board.c
@@ -87,6 +87,7 @@ extern void rtl8019_get_enetaddr (uchar * addr);
#endif
+#ifdef CONFIG_STATUS_LED
/
* Coloured LED functionality
@@ -110,6 +111,7 @@ void inline __blue_LED_on(void) {}
void inline blue_LED_on(void)__attribute__((weak, alias("__blue_LED_on")));
void inline __blue_LED_off(void) {}
void inline blue_LED_off(void)__attribute__((weak, alias("__blue_LED_off")));
+#endif
/
* Init Utilities *
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Improve read performance of gerenic mmc.
Signed-off-by: Terry Lv
---
drivers/mmc/mmc.c | 57 -
1 files changed, 43 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index b69ce15..dcc9548 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -88,7 +88,7 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const
void*src)
err = mmc_set_blocklen(mmc, mmc->write_bl_len);
if (err) {
- printf("set write bl len failed\n\r");
+ puts("set write bl len failed\n\r");
return err;
}
@@ -113,7 +113,7 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const
void*src)
err = mmc_send_cmd(mmc, &cmd, &data);
if (err) {
- printf("mmc write failed\n\r");
+ puts("mmc write failed\n\r");
return err;
}
@@ -164,7 +164,7 @@ int mmc_read(struct mmc *mmc, u64 src, uchar *dst, int size)
buffer = malloc(blklen);
if (!buffer) {
- printf("Could not allocate buffer for MMC read!\n");
+ puts("Could not allocate buffer for MMC read!\n");
return -1;
}
@@ -205,27 +205,56 @@ free_buffer:
static ulong mmc_bread(int dev_num, ulong start, lbaint_t blkcnt, void *dst)
{
+ struct mmc_cmd cmd;
+ struct mmc_data data;
int err;
- int i;
+ int stoperr = 0;
struct mmc *mmc = find_mmc_device(dev_num);
+ int blklen;
if (!mmc)
- return 0;
+ return -1;
- /* We always do full block reads from the card */
- err = mmc_set_blocklen(mmc, mmc->read_bl_len);
+ blklen = mmc->read_bl_len;
+
+ err = mmc_set_blocklen(mmc, blklen);
if (err) {
- return 0;
+ puts("set read bl len failed\n\r");
+ return err;
}
- for (i = start; i < start + blkcnt; i++, dst += mmc->read_bl_len) {
- err = mmc_read_block(mmc, dst, i);
+ if (blkcnt > 1)
+ cmd.cmdidx = MMC_CMD_READ_MULTIPLE_BLOCK;
+ else
+ cmd.cmdidx = MMC_CMD_READ_SINGLE_BLOCK;
- if (err) {
- printf("block read failed: %d\n", err);
- return i - start;
- }
+ if (mmc->high_capacity)
+ cmd.cmdarg = start;
+ else
+ cmd.cmdarg = start * blklen;
+
+ cmd.resp_type = MMC_RSP_R1;
+ cmd.flags = 0;
+
+ data.dest = dst;
+ data.blocks = blkcnt;
+ data.blocksize = blklen;
+ data.flags = MMC_DATA_READ;
+
+ err = mmc_send_cmd(mmc, &cmd, &data);
+
+ if (err) {
+ puts("mmc read failed\n\r");
+ return err;
+ }
+
+ if (blkcnt > 1) {
+ cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
+ cmd.cmdarg = 0;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.flags = 0;
+ stoperr = mmc_send_cmd(mmc, &cmd, NULL);
}
return blkcnt;
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MD Lists
Our AMERICAN Medical Doctor list has full contact data for all states. Coverage for These specialties and more: allergy/immunology anesthesiology cardiology dermatology emergency_medicine endocrinology_diabetes metabolism family_practice gastroenterology general_practice geriatrics infectious_disease internal medicine internal medicine medical genetics nephrology neurological_surgery neurology obgyn oncology ophthalmology orthopedics otolaryngology pathology pediatrics physical_medicine plastic_surgery preventive_medicine psychiatry radiology surgery urology gen.pract This week only the complete list is on sale for half price. For a data sheet please reply here julia...@bestchoiceformed.org respond to rem...@bestchoiceformed.org in the event that you are not happy receiving this email. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] No GOT in IRQ and use r12 as GOT ptr
Wolfgang Denk wrote on 03/11/2009 20:40:50: > > Dear Joakim Tjernlund, > > In message <1257180242-1299-1-git-send-email-joakim.tjernl...@transmode.se> > you wrote: > > This series removes the needs to access the GOT in > > IRQ handlers, then switches GOT PTR in start.S asm to > > use r12 instead of r14. This leads up to the removal of > > -ffixed-r14 gcc option for ppc > > Will you please also update the documentation (especially the README, > section register use) ? Right, had not seen that. Will fix. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8349E-MDS questions
Hi Mit Matelske, > I believe I made the changes to our FPGA that the eval's CPLD did when > the FCFG gets switched to 1 (bringing up flash enable at reset). > Since we have a smaller flash, I am putting the u-boot.bin at > 0xFFE0 (0xFFF0 for the original Freescale u-boot), the base > address for our flash. But I'm still not having any luck. Look at p33 for a logic analyzer power-on reset trace: http://www.ovro.caltech.edu/~dwh/carma_board/powerpc_mpc8349e.pdf When your board boots, assuming you have the configuration reset words pin strapping set to read from the local bus, the processor will read the RCWs starting from 'address zero' on CS#0, i.e., from the beginning of your flash. If you have BMS = 0, then the reset vector will be 100h. If you have BMS = 1, then the reset vector will be FFF0_0100h. The default memory window during boot is setup 8MB from the end of flash, i.e., starting at FF80_h. Your flash is 4Mx16 = 8MB, so it decodes in the 8MB window (a smaller flash would alias within the window, and a larger flash would not be completely visible). Your U-Boot image should be placed at FFF0_h, since the reset vector is located 100h into the image. If you look at the image, it probably has RCWs in it, however, they do nothing in that location, the RCWs must be located in the first sector on the Flash. Cheers, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for Linuxstamp II 9260
On Tue, Nov 3, 2009 at 2:21 PM, Mike Frysinger wrote: > On Tuesday 03 November 2009 16:12:40 Paul Thomas wrote: >> From: Paul Thomas > > looks like you need to fix your git environment & re-submit this patch > -mike > Mike, Yeah, I saw it does that in git send-email, but the first prompt "Who should the emails appear to be from?" is correct, and the email in the .gitconfig is correct. I don't know where's it's pulling that info from or why it's different from the prompt. It's very annoying. thanks, Paul ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for Linuxstamp II 9260
Dear Paul Thomas, please check/fix your mail addresses. In message <1257282760-18005-1-git-send-email-pthomas8...@gmail.com> you wrote: > From: Paul Thomas Signed-off-by: line is missing. > --- > Makefile |3 + > board/linuxstamp/at91sam9260ls/Makefile| 56 ++ > board/linuxstamp/at91sam9260ls/at91sam9260ls.c | 203 + > board/linuxstamp/at91sam9260ls/config.mk |1 + > board/linuxstamp/at91sam9260ls/led.c | 41 + > board/linuxstamp/at91sam9260ls/partition.c | 40 + > include/configs/at91sam9260ls.h| 223 > > 7 files changed, 567 insertions(+), 0 deletions(-) > create mode 100644 board/linuxstamp/at91sam9260ls/Makefile > create mode 100644 board/linuxstamp/at91sam9260ls/at91sam9260ls.c > create mode 100644 board/linuxstamp/at91sam9260ls/config.mk > create mode 100644 board/linuxstamp/at91sam9260ls/led.c > create mode 100644 board/linuxstamp/at91sam9260ls/partition.c > create mode 100644 include/configs/at91sam9260ls.h Entries to MAKEALL an MAINTAINERS are missing. > diff --git a/Makefile b/Makefile > index bcb3fe9..d8efa66 100644 > --- a/Makefile > +++ b/Makefile > @@ -2761,6 +2761,9 @@ at91sam9g20ek_config: unconfig > fi; > @$(MKCONFIG) -a at91sam9260ek arm arm926ejs at91sam9260ek atmel at91 > > +at91sam9260ls_config : unconfig > + @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9260ls linuxstamp at91 When the board name is Linuxstamp, and the board directory name is linuxstamp, then the board config file name and make target name should be linuxstamp, too. > at91sam9xeek_nandflash_config \ > at91sam9xeek_dataflash_cs0_config \ > at91sam9xeek_dataflash_cs1_config \ > diff --git a/board/linuxstamp/at91sam9260ls/Makefile > b/board/linuxstamp/at91sam9260ls/Makefile > new file mode 100644 > index 000..2a0ef78 > --- /dev/null > +++ b/board/linuxstamp/at91sam9260ls/Makefile > @@ -0,0 +1,56 @@ > +# > +# (C) Copyright 2003-2008 > +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. > +# > +# (C) Copyright 2008 > +# Stelian Pop > +# Lead Tech Design > +# > +# See file CREDITS for list of people who contributed to this > +# project. > +# > +# 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. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, > +# MA 02111-1307 USA > +# > + > +include $(TOPDIR)/config.mk > + > +LIB = $(obj)lib$(BOARD).a > + > +COBJS-y += at91sam9260ls.o > +COBJS-y += led.o > +COBJS-$(CONFIG_HAS_DATAFLASH) += partition.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) $(SOBJS) > + > +clean: > + rm -f $(SOBJS) $(OBJS) > + > +distclean: clean > + rm -f $(LIB) core *.bak $(obj).depend > + > +# > + > +# defines $(obj).depend target > +include $(SRCTREE)/rules.mk > + > +sinclude $(obj).depend > + > +# > diff --git a/board/linuxstamp/at91sam9260ls/at91sam9260ls.c > b/board/linuxstamp/at91sam9260ls/at91sam9260ls.c > new file mode 100644 > index 000..a1c4466 > --- /dev/null > +++ b/board/linuxstamp/at91sam9260ls/at91sam9260ls.c > @@ -0,0 +1,203 @@ > +/* > + * (C) Copyright 2007-2008 > + * Stelian Pop > + * Lead Tech Design > + * > + * (C) Copyright 2009 > + * Paul Thomas > + * http://opencircuits.com/Linuxstamp_II_9260 > + * > + * See file CREDITS for list of people who contributed to this > + * project. > + * > + * 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. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to
[U-Boot] [PATCH] Adding support for Linuxstamp II 9260
From: Paul Thomas
---
Makefile |3 +
board/linuxstamp/at91sam9260ls/Makefile| 56 ++
board/linuxstamp/at91sam9260ls/at91sam9260ls.c | 203 +
board/linuxstamp/at91sam9260ls/config.mk |1 +
board/linuxstamp/at91sam9260ls/led.c | 41 +
board/linuxstamp/at91sam9260ls/partition.c | 40 +
include/configs/at91sam9260ls.h| 223
7 files changed, 567 insertions(+), 0 deletions(-)
create mode 100644 board/linuxstamp/at91sam9260ls/Makefile
create mode 100644 board/linuxstamp/at91sam9260ls/at91sam9260ls.c
create mode 100644 board/linuxstamp/at91sam9260ls/config.mk
create mode 100644 board/linuxstamp/at91sam9260ls/led.c
create mode 100644 board/linuxstamp/at91sam9260ls/partition.c
create mode 100644 include/configs/at91sam9260ls.h
diff --git a/Makefile b/Makefile
index bcb3fe9..d8efa66 100644
--- a/Makefile
+++ b/Makefile
@@ -2761,6 +2761,9 @@ at91sam9g20ek_config : unconfig
fi;
@$(MKCONFIG) -a at91sam9260ek arm arm926ejs at91sam9260ek atmel at91
+at91sam9260ls_config : unconfig
+ @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9260ls linuxstamp at91
+
at91sam9xeek_nandflash_config \
at91sam9xeek_dataflash_cs0_config \
at91sam9xeek_dataflash_cs1_config \
diff --git a/board/linuxstamp/at91sam9260ls/Makefile
b/board/linuxstamp/at91sam9260ls/Makefile
new file mode 100644
index 000..2a0ef78
--- /dev/null
+++ b/board/linuxstamp/at91sam9260ls/Makefile
@@ -0,0 +1,56 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2008
+# Stelian Pop
+# Lead Tech Design
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# 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.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y+= at91sam9260ls.o
+COBJS-y+= led.o
+COBJS-$(CONFIG_HAS_DATAFLASH) += partition.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) $(SOBJS)
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/linuxstamp/at91sam9260ls/at91sam9260ls.c
b/board/linuxstamp/at91sam9260ls/at91sam9260ls.c
new file mode 100644
index 000..a1c4466
--- /dev/null
+++ b/board/linuxstamp/at91sam9260ls/at91sam9260ls.c
@@ -0,0 +1,203 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop
+ * Lead Tech Design
+ *
+ * (C) Copyright 2009
+ * Paul Thomas
+ * http://opencircuits.com/Linuxstamp_II_9260
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#if defined(CONFIG_RESET_PHY_R) && defined(CONFIG_MACB)
+#include
+#endif
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* - */
+/*
+ * Miscelaneous platform dependent initialisations
+ */
+
+#ifdef CONFIG_CMD_NAND
+static void at91sam9260ls_nand_hw_init(void)
+{
+ unsigned long csa;
+
+ /* Enable CS3 */
[U-Boot] MPC8349E-MDS questions
I am working on a board based on the MPC8349E-MDS eval board from Freescale. One of the few differences is that it has an Atmel flash part on it (AT49BV642DT 4Mx16) and a Xilinx FPGA. I have the old u-boot-1.1.3 that came with the eval board running both on the eval board and our "new" board, however I am having trouble getting the latest release, u-boot-2009.08, to come up on our board. I found this old post from Dave Liu: The MPC8349ADS is merged to MPC8349EMDS in the latest u-boot of GIT. The latest u-boot 83xx source code has more high quality than the U-boot-1.1.4 release. But be careful the boot address is changed from high end to low end memory. and the HRCW need come from flash. So 1) You must program the image to the head of flash. 2) Change the SW4[FCFG] to '1' and with that information I got the latest u-boot running on the eval board. I believe I made the changes to our FPGA that the eval's CPLD did when the FCFG gets switched to 1 (bringing up flash enable at reset). Since we have a smaller flash, I am putting the u-boot.bin at 0xFFE0 (0xFFF0 for the original Freescale u-boot), the base address for our flash. But I'm still not having any luck. Any ideas? Thanks!! Mit Matelske ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8349E-MDS questions
David Hawkins wrote: > Hi Mit Matelske, > >> I believe I made the changes to our FPGA that the eval's CPLD did when >> the FCFG gets switched to 1 (bringing up flash enable at reset). >> Since we have a smaller flash, I am putting the u-boot.bin at >> 0xFFE0 (0xFFF0 for the original Freescale u-boot), the base >> address for our flash. But I'm still not having any luck. > > Look at p33 for a logic analyzer power-on reset trace: > http://www.ovro.caltech.edu/~dwh/carma_board/powerpc_mpc8349e.pdf > > When your board boots, assuming you have the configuration > reset words pin strapping set to read from the local bus, > the processor will read the RCWs starting from 'address zero' > on CS#0, i.e., from the beginning of your flash. > > If you have BMS = 0, then the reset vector will be 100h. > > If you have BMS = 1, then the reset vector will be FFF0_0100h. > > The default memory window during boot is setup 8MB from > the end of flash, i.e., starting at FF80_h. Sorry, that should say high-boot (BMS = 1). For low-boot (BMS = 0), the 8MB window starts at address 0 on CS#0. In that case the U-Boot reset vector starts in the same sector as the RCWs, with the RCWs at 0, and the reset vectors at 100h. Thats why you also see the RCWs in the high-boot image (well, you used to, not sure if you do now). Cheers, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] No GOT in IRQ and use r12 as GOT ptr
Dear Joakim Tjernlund, In message <1257180242-1299-1-git-send-email-joakim.tjernl...@transmode.se> you wrote: > This series removes the needs to access the GOT in > IRQ handlers, then switches GOT PTR in start.S asm to > use r12 instead of r14. This leads up to the removal of > -ffixed-r14 gcc option for ppc Will you please also update the documentation (especially the README, section register use) ? 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 "The pathology is to want control, not that you ever get it, because of course you never do."- Gregory Bateson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91SAM7S9263B-EK + u-boot using sd card: linux uncompress ... crc error
Dear thomas.schu...@saf-kassel.de, In message you wrote: > > we urgently need some help. Read http://www.catb.org/~esr/faqs/smart-questions.html and/or hire an expert. > WE NEED TO RUN THE WHOLE THING FROM SD! No need to shout. > u-boot loads the uImage (linux-2.6.27)from SD to 0x2200 > u-boot does Bootm 0x2200 (0x2220 shows same result) > > Linux starts , but fails! see screen copy: > Uncompressing > Linux > crc error > > What went wrong? Can you help? Obviously there is some memory corruption. > An Alternative is an uncompressed Kernel in order to come around the crc > issue. Then Linux kernel starts, but crashes after 100lines of messages > anyway. Could be some memory corruption. > We found comments in some forum that flushing/invalidating the > icashe/dcashe is required when SD is used before u-boot is going on to run > the kernel. Indeed it is a good idea to make sure caches are properly flushed. 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 The trouble with our times is that the future is not what it used to be. - Paul Valery ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] multiple partitions in mtdparts
Hi,
I am trying to define multiple partitions using mtdparts variable. But I
can't get it set automatically right.
I defined the set_bootargs as the following:
set_bootargs=setenv bootargs root=/dev/mtdblock2 rootfs=cramfs,jffs2
mtdparts=ph
ysmap-flash.0:256k(u-boot),256k(u-boot-env),7936k(root1),7936k(root2);physmap-fl
ash.1:16384k(data) console=ttyS0,115200n8
But when I run set_bootargs, I got the following error -
# run set_bootargs
Unknown command 'physmap-flash.1:16384k(data)' - try 'help'
Can someone help me with the correct format on mtdparts? thanks a lot.
mtdparts=mtdparts=physmap-flash.0:256k(u-boot),256k(u-boot-env),7936k(root1),793
6k(root2);physmap-flash.1:16384k(data)
boot=run set_bootargs;chpart nor0,${boot_device};fsload
boot/uImage;bootm
mtdids=nor0=physmap-flash.0,nor1=physmap-flash.1
partition=nor0,2
mtddevnum=2
mtddevname=root1
set_bootargs=setenv bootargs root=/dev/mtdblock2 rootfs=cramfs,jffs2
mtdparts=ph
ysmap-flash.0:256k(u-boot),256k(u-boot-env),7936k(root1),7936k(root2);physmap-fl
ash.1:16384k(data) console=ttyS0,115200n8
bootargs=root=/dev/mtdblock2 rootfs=cramfs,jffs2
mtdparts=physmap-flash.0:256k(u
-boot),256k(u-boot-env),7936k(root1),7936k(root2)
Environment size: 847/262140 bytes
# run set_bootargs
Unknown command 'physmap-flash.1:16384k(data)' - try 'help'
#
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot with BDI
Hi all, I wish to configure my BDI3000 to boot from NAND flash on the mx31 platform. I do not want the BDI to do the low level init including processor/clock/SDRAM setup etc. Instead, i want my U-boot do it when "reset halt/run" is executed. What do i need to put in the BDI config in order to do that. Motivation is being able to debug NAND boot. Thanks all in advance, Stephanie. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tsec: Force TBI PHY to 1000Mbps full duplex in SGMII mode
In SGMII mode the link between a processor's internal TBI PHY and an
external PHY should always be 1000Mbps, full duplex. Also, the SGMII
interface between an internal TBI PHY and external PHY does not
support in-band auto-negotation.
Previously, when configured for SGMII mode a TBI PHY would attempt to
restart auto-negotation during initializtion. This auto-negotation
between a TBI PHY and external PHY would fail and result in unusable
ethernet operation.
Forcing the TBI PHY and and external PHY to link at 1000Mbps full duplex
in SGMII mode resolves this issue of auto-negotation failing.
Note that 10Mbps and 100Mbps operation is still possible on the external
side of the external PHY even when SGMII is operating at 1000Mbps.
The SGMII interface still operates at 1000Mbps, but each byte of data
is repeated 100 or 10 times for 10/100Mbps and the external PHY handles
converting this data stream into proper 10/100Mbps signalling.
Signed-off-by: Peter Tyser
---
In-band SGMII auto-negotiation doesn't work according to a lengthy
discussion with a Freescale FAE and the AN3869 SGMII appnote. XES's
MPC8572 and MPC8640 boards need this patch in order to use ethernet. These
boards generally use SGMII to connect to an BCM5482S PHY which has
an external gigabit-capable copper or fiber interface.
Some of Freescale's reference platforms have an SGMII riser card - any
idea how those function when using auto-negotiation? Do they function?
Are the really using SGMII, or are they using 1000 Base-X?
Some of the info in the manuals is misleading/confusing so any comments
are more than welcome from Freescalers:)
Thanks,
Peter
drivers/net/tsec.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 3f74118..cff5d38 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -276,12 +276,13 @@ uint tsec_local_mdio_read(volatile tsec_t *phyregs, uint
phyid, uint regnum)
| TBIANA_FULL_DUPLEX \
)
+/* Force the TBI PHY into 1000Mbps full duplex when in SGMII mode */
#define TBICR_SETTINGS ( \
TBICR_PHY_RESET \
- | TBICR_ANEG_ENABLE \
| TBICR_FULL_DUPLEX \
| TBICR_SPEED1_SET \
)
+
/* Configure the TBI for SGMII operation */
static void tsec_configure_serdes(struct tsec_private *priv)
{
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] jffs2 FS flash occupation
> Date: Tue, 3 Nov 2009 23:18:22 +0800 > From: xiangf...@gmail.com > To: leon...@msn.com > CC: u-boot@lists.denx.de > Subject: Re: [U-Boot] jffs2 FS flash occupation > > HeLei wrote: > > Hi, all > > > > > > > > If I wish to support uImage in jffs2 FS in NAND flash, how many size will > > be used for JFFS2 FS itself, such as wearing level, GC, JFFS2 INODE header? > > what you mean about uImage? is that kernel? uImage is the firmware including both kernel and application. > > > > > > > > > For example, NAND fash size is 32M and uImage is 8M including application > > and kernel. > > > I don't understand your question. > "uImage is 8M including application"? > uImage is the kernel right? > why there is application ? In our solution, application and kernel are wrapped into on firmware. I'm not sure it's accurate enought to call it uImage. My question is: Supposing pure data(kernel and application) is 8M, and NAND flash is 32M, then how many bytes|blocks JFFS2 file system will occupy by itself, such as wearing level, gc algorithm, JFFS2 INODE header... ? > > -- > Xiangfu Liu > Email: xiangfu at qi-hardware dot com > Web: http://www.qi-hardware.com _ 约会说不清地方？来试试微软地图最新msn互动功能！ http://ditu.live.com/?form=TL&swm=1___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for Linuxstamp II 9260
On Tuesday 03 November 2009 16:12:40 Paul Thomas wrote: > From: Paul Thomas looks like you need to fix your git environment & re-submit this patch -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
Re: [U-Boot] [PATCH] Adding support for Linuxstamp II 9260
>> +#ifdef CONFIG_RESET_PHY_R
>> +void reset_phy(void)
>> +{
>> +#ifdef CONFIG_MACB
>> + /*
>> + * Initialize ethernet HW addr prior to starting Linux,
>> + * needed for nfsroot
>> + */
>> + eth_init(gd->bd);
>> +#endif
>> +}
>
> NAK. Please fix your Linux drivers instead. See
> http://www.denx.de/wiki/view/DULG/EthernetDoesNotWorkInLinux
>
This is just what's in at91sam9260ek. If I comment it out it doesn't
even compile. It looks like reset_phy is called from lib_arm/board.c.
Is there another 9260 board that does the "right" thing here?
thanks,
Paul
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] crc32: Impl. linux optimized crc32()
Wolfgang Denk wrote on 03/11/2009 17:02:27: > > Dear Joakim Tjernlund, > > In message <1257263550-21504-1-git-send-email-joakim.tjernl...@transmode.se> > you wrote: > > Ported over the more efficient linux crc32() function. > > A quick comparsion on ppc: > > After changing the old crc32 to do 4 bytes in the > > inner loop to be able to compare with new version one can note: > > - old inner loop has 61 insn, new has 19 insn. > > - new crc32 does one 32 bit load of data to crc while > > the old does four 8 bits loads. > > - size is bit bigger for the new crc32: > > 1392(old) 1428(new) of text. Can probably be shrunk > > somewhat by inlining crc32(). > > The Purpose of Computing is Insight, Not Numbers. > > So how much faster does the new code run, on a real machine? How much > time can be saved to mount a real JFFS2 file system, or to checksum a > reall image file? Picky I see. Like I said, numbers was done long time ago and isn't available now, the effects on mount time in linux was real. The best I am prepared to do is this(on mpc832x): New => date;crc 0 0xfff;date Date: 2009-11-03 (Tuesday)Time: 17:00:55 CRC32 for ... 0ffe ==> b2474c51 Date: 2009-11-03 (Tuesday)Time: 17:01:34 -> 39 secs Old => date;crc 0 0xfff;date Date: 2009-11-03 (Tuesday)Time: 17:03:24 CRC32 for ... 0ffe ==> 218bdca9 Date: 2009-11-03 (Tuesday)Time: 17:04:24 -> 60 secs If this isn't enough, you can always hope someone else wants to do further testing. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] cmd_nand: push CONFIG check to Makefile
Mike Frysinger wrote: > Signed-off-by: Mike Frysinger > --- > common/Makefile |2 +- > common/cmd_nand.c |4 > 2 files changed, 1 insertions(+), 5 deletions(-) > > diff --git a/common/Makefile b/common/Makefile > index 3781738..b8c596c 100644 > --- a/common/Makefile > +++ b/common/Makefile > @@ -116,7 +116,7 @@ COBJS-$(CONFIG_CMD_MISC) += cmd_misc.o > COBJS-$(CONFIG_CMD_MMC) += cmd_mmc.o > COBJS-$(CONFIG_MP) += cmd_mp.o > COBJS-$(CONFIG_CMD_MTDPARTS) += cmd_mtdparts.o > -COBJS-y += cmd_nand.o > +COBJS-$(CONFIG_CMD_NAND) += cmd_nand.o > COBJS-$(CONFIG_CMD_NET) += cmd_net.o > COBJS-$(CONFIG_CMD_ONENAND) += cmd_onenand.o > COBJS-$(CONFIG_CMD_OTP) += cmd_otp.o > diff --git a/common/cmd_nand.c b/common/cmd_nand.c > index 158a55f..a5d2074 100644 > --- a/common/cmd_nand.c > +++ b/common/cmd_nand.c > @@ -18,9 +18,6 @@ > */ > #include > #include > - > -#if defined(CONFIG_CMD_NAND) > - > #include > #include > #include > @@ -686,4 +683,3 @@ U_BOOT_CMD(nboot, 4, 1, do_nandboot, > "boot from NAND device", > "[partition] | [[[loadAddr] dev] offset]" > ); > -#endif I already have a patch in u-boot-nand-flash/next from Peter Tyser that does this. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] lmb: only force on arches that use it
sorry Scott, didnt mean to direct this to you. meant to send the nand one only to you. -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
[U-Boot] [PATCH] spi_flash.h: pull in linux/types.h for u## types
---
include/spi_flash.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/spi_flash.h b/include/spi_flash.h
index de4f174..1f8ba29 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -24,6 +24,7 @@
#define _SPI_FLASH_H_
#include
+#include
struct spi_flash_region {
unsigned intcount;
--
1.6.5.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] bootm: mark local boot_os[] table static
Signed-off-by: Mike Frysinger
---
common/cmd_bootm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 22aa7f8..a4b2e26 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -129,7 +129,7 @@ int do_bootelf (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[]);
static boot_os_fn do_bootm_integrity;
#endif
-boot_os_fn * boot_os[] = {
+static boot_os_fn *boot_os[] = {
#ifdef CONFIG_BOOTM_LINUX
[IH_OS_LINUX] = do_bootm_linux,
#endif
--
1.6.5.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] cmd_nand: push CONFIG check to Makefile
Signed-off-by: Mike Frysinger --- common/Makefile |2 +- common/cmd_nand.c |4 2 files changed, 1 insertions(+), 5 deletions(-) diff --git a/common/Makefile b/common/Makefile index 3781738..b8c596c 100644 --- a/common/Makefile +++ b/common/Makefile @@ -116,7 +116,7 @@ COBJS-$(CONFIG_CMD_MISC) += cmd_misc.o COBJS-$(CONFIG_CMD_MMC) += cmd_mmc.o COBJS-$(CONFIG_MP) += cmd_mp.o COBJS-$(CONFIG_CMD_MTDPARTS) += cmd_mtdparts.o -COBJS-y += cmd_nand.o +COBJS-$(CONFIG_CMD_NAND) += cmd_nand.o COBJS-$(CONFIG_CMD_NET) += cmd_net.o COBJS-$(CONFIG_CMD_ONENAND) += cmd_onenand.o COBJS-$(CONFIG_CMD_OTP) += cmd_otp.o diff --git a/common/cmd_nand.c b/common/cmd_nand.c index 158a55f..a5d2074 100644 --- a/common/cmd_nand.c +++ b/common/cmd_nand.c @@ -18,9 +18,6 @@ */ #include #include - -#if defined(CONFIG_CMD_NAND) - #include #include #include @@ -686,4 +683,3 @@ U_BOOT_CMD(nboot, 4, 1, do_nandboot, "boot from NAND device", "[partition] | [[[loadAddr] dev] offset]" ); -#endif -- 1.6.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] lmb: only force on arches that use it
Signed-off-by: Mike Frysinger
---
common/cmd_bootm.c | 34 --
include/asm-m68k/config.h |2 ++
include/asm-ppc/config.h |2 ++
include/asm-sparc/config.h |2 ++
include/image.h|2 +-
include/lmb.h |4
lib_generic/Makefile |2 +-
lib_generic/lmb.c | 12
8 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 8f83598..22aa7f8 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -154,18 +154,6 @@ boot_os_fn * boot_os[] = {
ulong load_addr = CONFIG_SYS_LOAD_ADDR;/* Default Load Address */
static bootm_headers_t images; /* pointers to os/initrd/fdt images */
-void __board_lmb_reserve(struct lmb *lmb)
-{
- /* please define platform specific board_lmb_reserve() */
-}
-void board_lmb_reserve(struct lmb *lmb) __attribute__((weak,
alias("__board_lmb_reserve")));
-
-void __arch_lmb_reserve(struct lmb *lmb)
-{
- /* please define platform specific arch_lmb_reserve() */
-}
-void arch_lmb_reserve(struct lmb *lmb) __attribute__((weak,
alias("__arch_lmb_reserve")));
-
/* Allow for arch specific config before we boot */
void __arch_preboot_os(void)
{
@@ -201,15 +189,11 @@ void arch_preboot_os(void) __attribute__((weak,
alias("__arch_preboot_os")));
# error Unknown CPU type
#endif
-static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+static void bootm_start_lmb(void)
{
+#ifdef CONFIG_LMB
ulong mem_start;
phys_size_t mem_size;
- void*os_hdr;
- int ret;
-
- memset ((void *)&images, 0, sizeof (images));
- images.verify = getenv_yesno ("verify");
lmb_init(&images.lmb);
@@ -220,6 +204,20 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int
argc, char *argv[])
arch_lmb_reserve(&images.lmb);
board_lmb_reserve(&images.lmb);
+#else
+# define lmb_reserve(lmb, base, size)
+#endif
+}
+
+static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ void*os_hdr;
+ int ret;
+
+ memset ((void *)&images, 0, sizeof (images));
+ images.verify = getenv_yesno ("verify");
+
+ bootm_start_lmb();
/* get kernel image header, start address and length */
os_hdr = boot_get_kernel (cmdtp, flag, argc, argv,
diff --git a/include/asm-m68k/config.h b/include/asm-m68k/config.h
index 049c44e..36438be 100644
--- a/include/asm-m68k/config.h
+++ b/include/asm-m68k/config.h
@@ -21,4 +21,6 @@
#ifndef _ASM_CONFIG_H_
#define _ASM_CONFIG_H_
+#define CONFIG_LMB
+
#endif
diff --git a/include/asm-ppc/config.h b/include/asm-ppc/config.h
index af0853b..a735e8d 100644
--- a/include/asm-ppc/config.h
+++ b/include/asm-ppc/config.h
@@ -21,6 +21,8 @@
#ifndef _ASM_CONFIG_H_
#define _ASM_CONFIG_H_
+#define CONFIG_LMB
+
#ifndef CONFIG_MAX_MEM_MAPPED
#if defined(CONFIG_4xx) || defined(CONFIG_E500) || defined(CONFIG_MPC86xx)
#define CONFIG_MAX_MEM_MAPPED ((phys_size_t)2 << 30)
diff --git a/include/asm-sparc/config.h b/include/asm-sparc/config.h
index 049c44e..36438be 100644
--- a/include/asm-sparc/config.h
+++ b/include/asm-sparc/config.h
@@ -21,4 +21,6 @@
#ifndef _ASM_CONFIG_H_
#define _ASM_CONFIG_H_
+#define CONFIG_LMB
+
#endif
diff --git a/include/image.h b/include/image.h
index 5a424e6..b82f4b9 100644
--- a/include/image.h
+++ b/include/image.h
@@ -256,7 +256,7 @@ typedef struct bootm_headers {
#defineBOOTM_STATE_OS_GO (0x0080)
int state;
-#ifndef USE_HOSTCC
+#ifdef CONFIG_LMB
struct lmb lmb;/* for memory mgmt */
#endif
} bootm_headers_t;
diff --git a/include/lmb.h b/include/lmb.h
index 14e8727..43082a3 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -52,6 +52,10 @@ lmb_size_bytes(struct lmb_region *type, unsigned long
region_nr)
{
return type->region[region_nr].size;
}
+
+void board_lmb_reserve(struct lmb *lmb);
+void arch_lmb_reserve(struct lmb *lmb);
+
#endif /* __KERNEL__ */
#endif /* _LINUX_LMB_H */
diff --git a/lib_generic/Makefile b/lib_generic/Makefile
index 686601c..8d23c5d 100644
--- a/lib_generic/Makefile
+++ b/lib_generic/Makefile
@@ -37,7 +37,7 @@ COBJS-y += ctype.o
COBJS-y += display_options.o
COBJS-y += div64.o
COBJS-y += gunzip.o
-COBJS-y += lmb.o
+COBJS-$(CONFIG_LMB) += lmb.o
COBJS-y += ldiv.o
COBJS-$(CONFIG_MD5) += md5.o
COBJS-y += sha1.o
diff --git a/lib_generic/lmb.c b/lib_generic/lmb.c
index 1c6cf7c..c5e75fb 100644
--- a/lib_generic/lmb.c
+++ b/lib_generic/lmb.c
@@ -334,3 +334,15 @@ int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr)
}
return 0;
}
+
+void __board_lmb_reserve(struct lmb *lmb)
+{
+ /* please define platform specific board_lmb_reserve() */
+}
+void board_lmb_reserve(struct lmb *lmb) __attribute__((weak,
alias("__board_lmb_reserve")));
+
+void __arch_lmb_re
[U-Boot] [PATCH 1/1] net: pull CONFIG checks out of source and into makefile
Signed-off-by: Mike Frysinger
---
net/Makefile | 12 ++--
net/bootp.c |4
net/eth.c|7 +++
net/net.c|4
net/nfs.c|4
net/rarp.c |4
net/tftp.c |4
7 files changed, 9 insertions(+), 30 deletions(-)
diff --git a/net/Makefile b/net/Makefile
index ff87d87..4f819dd 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -27,14 +27,14 @@ include $(TOPDIR)/config.mk
LIB= $(obj)libnet.a
-COBJS-y += bootp.o
+COBJS-$(CONFIG_CMD_NET) += bootp.o
COBJS-$(CONFIG_CMD_DNS) += dns.o
-COBJS-y += eth.o
-COBJS-y += net.o
-COBJS-y += nfs.o
-COBJS-y += rarp.o
+COBJS-$(CONFIG_CMD_NET) += eth.o
+COBJS-$(CONFIG_CMD_NET) += net.o
+COBJS-$(CONFIG_CMD_NFS) += nfs.o
+COBJS-$(CONFIG_CMD_NET) += rarp.o
COBJS-$(CONFIG_CMD_SNTP) += sntp.o
-COBJS-y += tftp.o
+COBJS-$(CONFIG_CMD_NET) += tftp.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/net/bootp.c b/net/bootp.c
index 3093852..e679f8b 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -20,8 +20,6 @@
#define BOOTP_VENDOR_MAGIC 0x63825363 /* RFC1048 Magic Cookie
*/
-#if defined(CONFIG_CMD_NET)
-
#define TIMEOUT5000UL /* Milliseconds before trying BOOTP
again */
#ifndef CONFIG_NET_RETRY_COUNT
# define TIMEOUT_COUNT 5 /* # of timeouts before giving up */
@@ -948,5 +946,3 @@ void DhcpRequest(void)
BootpRequest();
}
#endif /* CONFIG_CMD_DHCP */
-
-#endif /* CONFIG_CMD_NET */
diff --git a/net/eth.c b/net/eth.c
index 9b50312..b650a20 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -26,7 +26,6 @@
#include
#include
-#ifdef CONFIG_CMD_NET
void eth_parse_enetaddr(const char *addr, uchar *enetaddr)
{
char *end;
@@ -60,9 +59,8 @@ int eth_getenv_enetaddr_by_index(int index, uchar *enetaddr)
sprintf(enetvar, index ? "eth%daddr" : "ethaddr", index);
return eth_getenv_enetaddr(enetvar, enetaddr);
}
-#endif
-#if defined(CONFIG_CMD_NET) && defined(CONFIG_NET_MULTI)
+#ifdef CONFIG_NET_MULTI
/*
* CPU and board-specific Ethernet initializations. Aliased function
@@ -492,7 +490,8 @@ char *eth_get_name (void)
{
return (eth_current ? eth_current->name : "unknown");
}
-#elif defined(CONFIG_CMD_NET) && !defined(CONFIG_NET_MULTI)
+
+#else /* !CONFIG_NET_MULTI */
#warning Ethernet driver is deprecated. Please update to use CONFIG_NET_MULTI
diff --git a/net/net.c b/net/net.c
index cab4b2d..d6d4838 100644
--- a/net/net.c
+++ b/net/net.c
@@ -96,8 +96,6 @@
#include "dns.h"
#endif
-#if defined(CONFIG_CMD_NET)
-
DECLARE_GLOBAL_DATA_PTR;
#ifndefCONFIG_ARP_TIMEOUT
@@ -1856,8 +1854,6 @@ void copy_filename (char *dst, char *src, int size)
*dst = '\0';
}
-#endif
-
#if defined(CONFIG_CMD_NFS) || defined(CONFIG_CMD_SNTP) ||
defined(CONFIG_CMD_DNS)
/*
* make port a little random, but use something trivial to compute
diff --git a/net/nfs.c b/net/nfs.c
index 27395fb..1d388a3 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -29,8 +29,6 @@
#include "nfs.h"
#include "bootp.h"
-#if defined(CONFIG_CMD_NET) && defined(CONFIG_CMD_NFS)
-
#define HASHES_PER_LINE 65 /* Number of "loading" hashes per line */
#define NFS_RETRY_COUNT 30
#define NFS_TIMEOUT 2000UL
@@ -754,5 +752,3 @@ NfsStart (void)
NfsSend ();
}
-
-#endif
diff --git a/net/rarp.c b/net/rarp.c
index d37981b..9444c03 100644
--- a/net/rarp.c
+++ b/net/rarp.c
@@ -29,8 +29,6 @@
#include "rarp.h"
#include "tftp.h"
-#if defined(CONFIG_CMD_NET)
-
#define TIMEOUT5000UL /* Milliseconds before trying BOOTP
again */
#ifndefCONFIG_NET_RETRY_COUNT
# define TIMEOUT_COUNT 5 /* # of timeouts before giving up */
@@ -116,5 +114,3 @@ RarpRequest (void)
NetSetTimeout(TIMEOUT, RarpTimeout);
NetSetHandler(RarpHandler);
}
-
-#endif
diff --git a/net/tftp.c b/net/tftp.c
index cc60a3b..090aa94 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -10,8 +10,6 @@
#include "tftp.h"
#include "bootp.h"
-#if defined(CONFIG_CMD_NET)
-
#define WELL_KNOWN_PORT69 /* Well known TFTP port #
*/
#define TIMEOUT5000UL /* Millisecs to timeout for
lost pkt */
#ifndefCONFIG_NET_RETRY_COUNT
@@ -690,5 +688,3 @@ static void parse_multicast_oack(char *pkt, int len)
}
#endif /* Multicast TFTP */
-
-#endif
--
1.6.5.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] at91SAM7S9263B-EK + u-boot using sd card: linux uncompress ... crc error
u-boot 2009.08 Hello, we urgently need some help. WE NEED TO RUN THE WHOLE THING FROM SD! We made the u-boot working with the SD (mci1) on the at91SAM7S9263B-EK board. Status: boot.bin (At91Bootstrap 3.0) starts from SD boot.bin (2009.08) loads u-boot form SD and starts it u-boot loads the uImage (linux-2.6.27)from SD to 0x2200 u-boot does Bootm 0x2200 (0x2220 shows same result) Linux starts , but fails! see screen copy: Uncompressing Linux crc error What went wrong? Can you help? An Alternative is an uncompressed Kernel in order to come around the crc issue. Then Linux kernel starts, but crashes after 100lines of messages anyway. see attached file RAM of the board seems to be okay per tests. Putting the u-boot and kernel into the nand seems to start and work. With Nand it is possible to start boot.bin from SD and call u-boot/kernel from sd. We found comments in some forum that flushing/invalidating the icashe/dcashe is required when SD is used before u-boot is going on to run the kernel. We tried already dcache_disable/icache_disable before u-boot starts kernel. But no imrpovement. Do you have a code snippet to do so? Looking forwart to hearing from you asap - THANKS INDEED! Mit freundlichen Grüßen Thomas Schulte _ Dipl.-Ing. Thomas Schulte Entwicklung SaF Gesellschaft für technische Sonderanlagen mbH Wohnstr. 10, 34123 Kassel t. +49 (561) 507 87-29, f. +49 (561) 507 87-99 thomas.schu...@saf-kassel.de www.saf-kassel.de Amtsgericht Kassel HRB 3758 Geschäftsführer: Dipl.-Inform. Michael Franz RomBOOT > -- AT91bootstrap Project 3.0 -- -- AT91SAM9263-EK -- Compiled: Nov 3 2009 14:29:24 -- -I- Setting: MCK = 100MHz -I- I cache enabled. -I- Init SDRAM -I- MEDSdcard init -I- mciID != 0 -I- SD card detection not available, assuming card is present -I- Cannot check if SD card is write-protected -I- SD/MMC card initialization successful -I- Card size: 982 MB -I- Block size: 512 Bytes -I- Copy "u-boot.bin" from SdCard to 0x23f0 -I- File Size = 0x00038338 = 230200 -I- I cache disabled. -I- D cache is already disabled. -I- Jump to 0x23f0 MACH_TYPE = 0x04b2 U-Boot 2009.08 (Nov 03 2009 - 16:05:48) DRAM: 64 MB NAND: 256 MiB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial MMC: ATMEL MCI: 0 Net: macb0 macb0: Starting autonegotiation... macb0: Autonegotiation timed out (status=0x7849) macb0: link down (status: 0x7849) Hit any key to stop autoboot: 0 mmc: clock 15 too low; setting CLKDIV to 255 mmc: clock 15 too low; setting CLKDIV to 255 mmc: command 8 failed (status: 0x0010c0e5) Device: ATMEL MCI Manufacturer ID: 2 OEM: 544d Name: SD01G Tran Speed: 2500 Rd Block Len: 512 SD version 1.0 High Capacity: No Capacity: 4424786634494258471 Bus Width: 1-bit 1538928 zimage 19192 boot.bin 18944 boot 2220.bin 18920 boot linux.bin 19400 boot lowerupper.bin 3157120 image 194620 u-boot nanu.bin 216092 u-boot-new.bin 194620 u-boot-nf.bin 193560 u-boot-old.bin 1551412 linux-2.6.27-at91-exp.2-at91sam9263ek.bin 194620 u-boot-1.3.4-exp.2-at91sam9263ek-nandflash.bin 224876 u-boot 2009.bin 230200 u-boot.bin 1538992 uimage.cpr 3157184 uimage.unc 1551412 linux.bin 17 file(s), 0 dir(s) reading uimage.unc 3157184 bytes read U-Boot> bootm 0x2220 ## Booting kernel from Legacy Image at 2220 ... Image Name: linux-2.6 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3157120 Bytes = 3 MB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Linux version 2.6.27 (t...@linux-pluto) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-161) ) #1 Fri Oct 30 17:13:51 CET 2009 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 Machine: Atmel AT91SAM9263-EK Ignoring unrecognised tag 0x54410008 Memory policy: ECC disabled, Data cache writeback Clocks: CPU 200 MHz, master 100 MHz, main 16.367 MHz CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: mem=64M console=ttyS0,115200 root=/dev/mtdblock1 rw rootfstype=jffs2 AT91: 160 gpio irqs in 5 banks PID hash table entries: 256 (order: 8, 1024 bytes) Console: colour dummy device 80x30 console [ttyS0] enabled Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 64MB = 64MB total Memory: 61656KB available (2844K code, 234K data, 124K init) Calibrating delay loop... 99.73 BogoMIPS (lpj=498688) Mount-cache hash table entries: 512 CPU: Test
Re: [U-Boot] [PATCH (repost)] Nomadik: fix reset_timer()
> Well, to me READ_TIMER() sounds like a function/macro to read some > value from some timer; if that timer counts doen, then successive > calls to that macro/function would return decreasing values. Counting > up or down is a property of the specific timer and should be handled > elsewhere; such policy does IMHO not belong into some accessor > function. Well, I thought this was an easy fix. Unfortunately, I can't test any new code for a few days, so a patch that changes this, while trivial, may be bugged. Unless I get an ack from you, I'll send a timer which negates elsewhere in a day or so. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] crc32: Impl. linux optimized crc32()
Dear Joakim Tjernlund, In message <1257263550-21504-1-git-send-email-joakim.tjernl...@transmode.se> you wrote: > Ported over the more efficient linux crc32() function. > A quick comparsion on ppc: > After changing the old crc32 to do 4 bytes in the > inner loop to be able to compare with new version one can note: > - old inner loop has 61 insn, new has 19 insn. > - new crc32 does one 32 bit load of data to crc while > the old does four 8 bits loads. > - size is bit bigger for the new crc32: > 1392(old) 1428(new) of text. Can probably be shrunk > somewhat by inlining crc32(). The Purpose of Computing is Insight, Not Numbers. So how much faster does the new code run, on a real machine? How much time can be saved to mount a real JFFS2 file system, or to checksum a reall image file? 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 young'uns. That was *long* before AltaVista, DejaNews, or even (gasp) the *Web*! In fact, we typed that thread on steam-powered card punchers, and shipped it around via Pony Express. -- Randal Schwartz in <8cwww1cd0d@gadget.cscaper.com> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
Wolfgang Denk wrote on 03/11/2009 14:21:08: > > Dear Joakim Tjernlund, > > In message 003bf...@transmode.se> you wrote: > > > > > > HeLei wrote on 03/11/2009 09:21:04: > > > > > > > > Thank you, Jocke > > > > > > > - impl. a better crc32(use the one from linux) > > > > > > Attaching a very crude port of linux crc32. This boots a linux img > > > for me and handles the environment crc as well. Feel free > > > to clean it up and submit to u-boot. > > > > > > Jocke > > > > So I could not help myself, here is a better port of crc32 to u-boot. > > You will probably get at small conflict due to LINK_OFF, just remove > > the LINK_OFF stuff for now. > > Could you test and report? > > Do you have a little or big endian target? > > I understand you will resend this patch with a proper Subject: for > real review on the list? > > You also might want to explain in which way this patch is "more > efficient" - in terms of memory footprint, or execution time, or > both? And by how much? Tested in which envrionment(s) ? Wolfgang, I hope the new patch I sent with some data points in the commit msg will do. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH (repost)] Nomadik: fix reset_timer()
Dear Alessandro Rubini, In message <20091103152354.ga12...@mail.gnudd.com> you wrote: > > Um... why is READ_TIMER doing such a stupid thing as negating values? > > Because the counter counts down. I could have returns "0 - value" or > "~value". Since I chose the latter initially, this fix keeps the same > approach. I can't return the value I read, since it goes backwards. Well, to me READ_TIMER() sounds like a function/macro to read some value from some timer; if that timer counts doen, then successive calls to that macro/function would return decreasing values. Counting up or down is a property of the specific timer and should be handled elsewhere; such policy does IMHO not belong into some accessor function. 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 Brain: an apparatus with which we think we think.- Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] crc32: Impl. linux optimized crc32()
Ported over the more efficient linux crc32() function.
A quick comparsion on ppc:
After changing the old crc32 to do 4 bytes in the
inner loop to be able to compare with new version one can note:
- old inner loop has 61 insn, new has 19 insn.
- new crc32 does one 32 bit load of data to crc while
the old does four 8 bits loads.
- size is bit bigger for the new crc32:
1392(old) 1428(new) of text. Can probably be shrunk
somewhat by inlining crc32().
Signed-off-by: Joakim Tjernlund
---
Only tested on PPC. little endian testing would be nice too.
lib_generic/crc32.c | 202 +--
1 files changed, 115 insertions(+), 87 deletions(-)
diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c
index b27048c..05b1431 100644
--- a/lib_generic/crc32.c
+++ b/lib_generic/crc32.c
@@ -13,6 +13,7 @@
#else
#include
#endif
+#include
#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
#include
@@ -52,6 +53,7 @@ local void make_crc_table OF((void));
the information needed to generate CRC's on data a byte at a time for all
combinations of CRC register values and incoming bytes.
*/
+#define tole(x) __cpu_to_le32(x)
local void make_crc_table()
{
uint32_t c;
@@ -70,7 +72,7 @@ local void make_crc_table()
c = (uLong)n;
for (k = 0; k < 8; k++)
c = c & 1 ? poly ^ (c >> 1) : c >> 1;
-crc_table[n] = c;
+crc_table[n] = tole(c);
}
crc_table_empty = 0;
}
@@ -78,59 +80,73 @@ local void make_crc_table()
/*
* Table of CRC-32's of all single-byte values (made by make_crc_table)
*/
+#define tole(x) __constant_cpu_to_le32(x)
+
local const uint32_t crc_table[256] = {
- 0xL, 0x77073096L, 0xee0e612cL, 0x990951baL, 0x076dc419L,
- 0x706af48fL, 0xe963a535L, 0x9e6495a3L, 0x0edb8832L, 0x79dcb8a4L,
- 0xe0d5e91eL, 0x97d2d988L, 0x09b64c2bL, 0x7eb17cbdL, 0xe7b82d07L,
- 0x90bf1d91L, 0x1db71064L, 0x6ab020f2L, 0xf3b97148L, 0x84be41deL,
- 0x1adad47dL, 0x6ddde4ebL, 0xf4d4b551L, 0x83d385c7L, 0x136c9856L,
- 0x646ba8c0L, 0xfd62f97aL, 0x8a65c9ecL, 0x14015c4fL, 0x63066cd9L,
- 0xfa0f3d63L, 0x8d080df5L, 0x3b6e20c8L, 0x4c69105eL, 0xd56041e4L,
- 0xa2677172L, 0x3c03e4d1L, 0x4b04d447L, 0xd20d85fdL, 0xa50ab56bL,
- 0x35b5a8faL, 0x42b2986cL, 0xdbbbc9d6L, 0xacbcf940L, 0x32d86ce3L,
- 0x45df5c75L, 0xdcd60dcfL, 0xabd13d59L, 0x26d930acL, 0x51de003aL,
- 0xc8d75180L, 0xbfd06116L, 0x21b4f4b5L, 0x56b3c423L, 0xcfba9599L,
- 0xb8bda50fL, 0x2802b89eL, 0x5f058808L, 0xc60cd9b2L, 0xb10be924L,
- 0x2f6f7c87L, 0x58684c11L, 0xc1611dabL, 0xb6662d3dL, 0x76dc4190L,
- 0x01db7106L, 0x98d220bcL, 0xefd5102aL, 0x71b18589L, 0x06b6b51fL,
- 0x9fbfe4a5L, 0xe8b8d433L, 0x7807c9a2L, 0x0f00f934L, 0x9609a88eL,
- 0xe10e9818L, 0x7f6a0dbbL, 0x086d3d2dL, 0x91646c97L, 0xe6635c01L,
- 0x6b6b51f4L, 0x1c6c6162L, 0x856530d8L, 0xf262004eL, 0x6c0695edL,
- 0x1b01a57bL, 0x8208f4c1L, 0xf50fc457L, 0x65b0d9c6L, 0x12b7e950L,
- 0x8bbeb8eaL, 0xfcb9887cL, 0x62dd1ddfL, 0x15da2d49L, 0x8cd37cf3L,
- 0xfbd44c65L, 0x4db26158L, 0x3ab551ceL, 0xa3bc0074L, 0xd4bb30e2L,
- 0x4adfa541L, 0x3dd895d7L, 0xa4d1c46dL, 0xd3d6f4fbL, 0x4369e96aL,
- 0x346ed9fcL, 0xad678846L, 0xda60b8d0L, 0x44042d73L, 0x33031de5L,
- 0xaa0a4c5fL, 0xdd0d7cc9L, 0x5005713cL, 0x270241aaL, 0xbe0b1010L,
- 0xc90c2086L, 0x5768b525L, 0x206f85b3L, 0xb966d409L, 0xce61e49fL,
- 0x5edef90eL, 0x29d9c998L, 0xb0d09822L, 0xc7d7a8b4L, 0x59b33d17L,
- 0x2eb40d81L, 0xb7bd5c3bL, 0xc0ba6cadL, 0xedb88320L, 0x9abfb3b6L,
- 0x03b6e20cL, 0x74b1d29aL, 0xead54739L, 0x9dd277afL, 0x04db2615L,
- 0x73dc1683L, 0xe3630b12L, 0x94643b84L, 0x0d6d6a3eL, 0x7a6a5aa8L,
- 0xe40ecf0bL, 0x9309ff9dL, 0x0a00ae27L, 0x7d079eb1L, 0xf00f9344L,
- 0x8708a3d2L, 0x1e01f268L, 0x6906c2feL, 0xf762575dL, 0x806567cbL,
- 0x196c3671L, 0x6e6b06e7L, 0xfed41b76L, 0x89d32be0L, 0x10da7a5aL,
- 0x67dd4accL, 0xf9b9df6fL, 0x8ebeeff9L, 0x17b7be43L, 0x60b08ed5L,
- 0xd6d6a3e8L, 0xa1d1937eL, 0x38d8c2c4L, 0x4fdff252L, 0xd1bb67f1L,
- 0xa6bc5767L, 0x3fb506ddL, 0x48b2364bL, 0xd80d2bdaL, 0xaf0a1b4cL,
- 0x36034af6L, 0x41047a60L, 0xdf60efc3L, 0xa867df55L, 0x316e8eefL,
- 0x4669be79L, 0xcb61b38cL, 0xbc66831aL, 0x256fd2a0L, 0x5268e236L,
- 0xcc0c7795L, 0xbb0b4703L, 0x220216b9L, 0x5505262fL, 0xc5ba3bbeL,
- 0xb2bd0b28L, 0x2bb45a92L, 0x5cb36a04L, 0xc2d7ffa7L, 0xb5d0cf31L,
- 0x2cd99e8bL, 0x5bdeae1dL, 0x9b64c2b0L, 0xec63f226L, 0x756aa39cL,
- 0x026d930aL, 0x9c0906a9L, 0xeb0e363fL, 0x72076785L, 0x05005713L,
- 0x95bf4a82L, 0xe2b87a14L, 0x7bb12baeL, 0x0cb61b38L, 0x92d28e9bL,
- 0xe5d5be0dL, 0x7cdcefb7L, 0x0bdbdf21L, 0x86d3d2d4L, 0xf1d4e242L,
- 0x68ddb3f8L, 0x1fda836eL, 0x81be16cdL, 0xf6b9265bL, 0x6fb077e1L,
- 0x18b74777L, 0x88085ae6L, 0xff0f6a70L, 0x66063bcaL, 0x11010b5cL,
- 0x8f659effL, 0xf862ae69L, 0x616bffd3L, 0x166ccf45L, 0xa00ae278L,
- 0xd70dd2eeL, 0x4e048354L, 0x3903b3c2L, 0xa7672661L, 0xd06016f7L,
- 0x4969474dL, 0x3e6e77dbL, 0xaed16a4aL, 0xd9d65adcL, 0x40df0b66L,
- 0x37d83bf0L, 0xa9bcae53L, 0xdebb9ec5L, 0x47b2cf7fL, 0
Re: [U-Boot] [PATCH (repost)] Nomadik: fix reset_timer()
> Um... why is READ_TIMER doing such a stupid thing as negating values? Because the counter counts down. I could have returns "0 - value" or "~value". Since I chose the latter initially, this fix keeps the same approach. I can't return the value I read, since it goes backwards. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] jffs2 FS flash occupation
HeLei wrote: > Hi, all > > > > If I wish to support uImage in jffs2 FS in NAND flash, how many size will > be used for JFFS2 FS itself, such as wearing level, GC, JFFS2 INODE header? what you mean about uImage? is that kernel? > > > > For example, NAND fash size is 32M and uImage is 8M including application > and kernel. > I don't understand your question. "uImage is 8M including application"? uImage is the kernel right? why there is application ? -- Xiangfu Liu Email: xiangfu at qi-hardware dot com Web: http://www.qi-hardware.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Don't inline weak symbols
Wolfgang Denk wrote: > Dear Roman Zeyde, > > In message <6d23e4ef0911030355j47a653a0iea7b6cae2f3cb...@mail.gmail.com> you > wrote: >> I have noticed that the same error as described here >> (http://lists.denx.de/pipermail/u-boot/2009-October/061913.html) >> happens when compiling the latest version of U-boot (v2009-11-rc1) >> using arm-cortex_a8-linux-gnueabi gcc version 4.4.0 >> (crosstool-ng-hg_defa...@1620_187e06178dcb). > > This has been discussed here before. Please see the archives. > >> Could you please apply the patch described above to resolve this issue? > > No, I will not. This has to go through the ARM custodian first. > > Best regards, > > Wolfgang Denk > I am currently reviewing this patch. After reviewing the history. There is a interest in #if-defing this code. The reason I can see is at least 2 of the start.S call bl coloured_LED_init bl red_LED_on In general, what happens is they call into the weak stubs. Only if the cpu/board provides an overriding function does these calls cause anything meaningful to happen. A good candidate for an if-def variable is the existing CONFIG_STATUS_LED. I am testing this change now. Since it effects all the boards, I am using the regressions of undefined symbol from MAKEALL arm to verify. When this change is done there will only be a handful of failures for the inline weak problem. Then this patch to remove the inlines will take care of them. I have looked at the assembly these produce and it does not look different for non-inline to inline. There was a slight increase in the binary size (zoom2) of 8 bytes using the code sourcry 2009. For my roll-your-own gcc 4.4.2, the size was about 400 bytes larger. Of course it is harder to tell since it wouldn't compile without the fix. After I run through some more testing, I will send out the patch set. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: 44x_spd_ddr2.c: Fix register macro ECCCR -> ECCES (SDRAM_ECCES)
This error only appears when DEBUG is enabled in this driver. That's why it went unnoticed till now. Signed-off-by: Stefan Roese --- cpu/ppc4xx/44x_spd_ddr2.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cpu/ppc4xx/44x_spd_ddr2.c b/cpu/ppc4xx/44x_spd_ddr2.c index 3975306..f8aa14a 100644 --- a/cpu/ppc4xx/44x_spd_ddr2.c +++ b/cpu/ppc4xx/44x_spd_ddr2.c @@ -3160,7 +3160,7 @@ inline void ppc4xx_ibm_ddr2_register_dump(void) PPC4xx_IBM_DDR2_DUMP_REGISTER(SDTR3); PPC4xx_IBM_DDR2_DUMP_REGISTER(MMODE); PPC4xx_IBM_DDR2_DUMP_REGISTER(MEMODE); - PPC4xx_IBM_DDR2_DUMP_REGISTER(ECCCR); + PPC4xx_IBM_DDR2_DUMP_REGISTER(ECCES); #if (defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \ defined(CONFIG_460EX) || defined(CONFIG_460GT)) PPC4xx_IBM_DDR2_DUMP_REGISTER(CID); -- 1.6.5.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
Wolfgang Denk wrote on 03/11/2009 14:21:08: > > Dear Joakim Tjernlund, > > In message 003bf...@transmode.se> you wrote: > > > > > > HeLei wrote on 03/11/2009 09:21:04: > > > > > > > > Thank you, Jocke > > > > > > > - impl. a better crc32(use the one from linux) > > > > > > Attaching a very crude port of linux crc32. This boots a linux img > > > for me and handles the environment crc as well. Feel free > > > to clean it up and submit to u-boot. > > > > > > Jocke > > > > So I could not help myself, here is a better port of crc32 to u-boot. > > You will probably get at small conflict due to LINK_OFF, just remove > > the LINK_OFF stuff for now. > > Could you test and report? > > Do you have a little or big endian target? > > I understand you will resend this patch with a proper Subject: for > real review on the list? Yes, I just wanted some external testing but this seems not to happen. > > You also might want to explain in which way this patch is "more > efficient" - in terms of memory footprint, or execution time, or > both? And by how much? Tested in which envrionment(s) ? hmm, I did this optimization many years ago for JFFS2 in linux. I don't have any numbers but I can give you some hints w.r.t number of insn in the inner loop(later though). Footprint will be higher. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/10] ARM Add New Board GEC2410
Dear Hui Tang,
In message you
wrote:
> Dear Wolfgang,
>
> >> - printf("s3c2410_nand_correct_data: not implemented\n");
> >> + debugX(1, "s3c2410_nand_correct_data: not implemented\n");
> >
> > I think this should remain a printf().
>
> Since when booting from nand flash, the printf() is not available in
> the early stage, here I replace printf() with debugX() to avoid using
> the undefined function.
But this is wrong. When you enable debuging, the same problem would be
present again.
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 that makes any sense to you, you have a big problem."
-- C. Durance, Computer Science 234
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH (repost)] Nomadik: fix reset_timer()
Dear Alessandro Rubini, In message <20091103121250.ga8...@mail.gnudd.com> you wrote: > From: Alessandro Rubini > > The timer decrements and READ_TIMER() negates the value read. > Writing 0 in reset_timer() is this wrong, as a readback before 400us > will read back 0 and will report 1780 seconds, so nand operations did > timeout. This patch writes ~0 in reset_timer to prevent this. > > Signed-off-by: Alessandro Rubini > Acked-by: Andrea Gallo > --- > > This must be applied for nand to work. It's a simple bugfix so > I think it got simply forgotten. Um... why is READ_TIMER doing such a stupid thing as negating values? This is not what it is supposed to do - as the name says, it should _read_ the _timer_. There is no mentioning of "NEgATE" anywhere? 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 "The majority of the stupid is invincible and guaranteed for all time. The terror of their tyranny, however, is alleviated by their lack of consistency." - Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Don't inline weak symbols
Dear Roman Zeyde, In message <6d23e4ef0911030355j47a653a0iea7b6cae2f3cb...@mail.gmail.com> you wrote: > > I have noticed that the same error as described here > (http://lists.denx.de/pipermail/u-boot/2009-October/061913.html) > happens when compiling the latest version of U-boot (v2009-11-rc1) > using arm-cortex_a8-linux-gnueabi gcc version 4.4.0 > (crosstool-ng-hg_defa...@1620_187e06178dcb). This has been discussed here before. Please see the archives. > Could you please apply the patch described above to resolve this issue? No, I will not. This has to go through the ARM custodian first. 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 The perversity of nature is nowhere better demonstrated by the fact that, when exposed to the same atmosphere, bread becomes hard while crackers become soft. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
Dear Joakim Tjernlund, In message you wrote: > > > > HeLei wrote on 03/11/2009 09:21:04: > > > > > > Thank you, Jocke > > > > > - impl. a better crc32(use the one from linux) > > > > Attaching a very crude port of linux crc32. This boots a linux img > > for me and handles the environment crc as well. Feel free > > to clean it up and submit to u-boot. > > > > Jocke > > So I could not help myself, here is a better port of crc32 to u-boot. > You will probably get at small conflict due to LINK_OFF, just remove > the LINK_OFF stuff for now. > Could you test and report? > Do you have a little or big endian target? I understand you will resend this patch with a proper Subject: for real review on the list? You also might want to explain in which way this patch is "more efficient" - in terms of memory footprint, or execution time, or both? And by how much? Tested in which envrionment(s) ? 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 People are always a lot more complicated than you think. It's very important to remember that. - Terry Pratchett, _Truckers_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] ARM Add New Board GEC2410
Dear Minkyu Kang, In message <1f3430fb0911030227t2c204fd6s52a0685628748...@mail.gmail.com> you wrote: > > > Would you please give me some advice where should I put the gec2410 > > board config? > > I think, It is better to put bottom of s3c24x0 board series. (next to VCMA9) This is definitely wrong. Lists shall be kept sorted. 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 FORTRAN? The syntactically incorrect statement "DO 10 I = 1.10" will parse and generate code creating a variable, DO10I, as follows: "DO10I = 1.10" If that doesn't terrify you, it should. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2009.11-rc1 is out
Dear rhabarber1848, In message you wrote: > > I just tested it on my Dbox2 board where U-Boot 2009.08 is working > perfectly well with unchanged config. > But now U-Boot raises an exception during machine check: > > = > U-Boot 2009.11 (Tuxbox) (Nov 03 2009 - 08:59:24) > > CPU: PPC823ZTnnB2 at 66 MHz: 2 kB I-Cache 1 kB D-Cache > Board: DBOX2, Sagem, BMon V1.0 This does not seem to be any of the boards supported in mainline. It does not even show a correct version id, so I'm not surprised that more bugs are present in this code. 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 Many companies that have made themselves dependent on [the equipment of a certain major manufacturer] (and in doing so have sold their soul to the devil) will collapse under the sheer weight of the un- mastered complexity of their data processing systems. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] ARM Add New Board GEC2410
Dear Hui Tang, > > In message you > wrote: > > > An ARM920 board does not belong into the arm926ejs block. ... > Would you please give me some advice where should I put the gec2410 > board config? Sorry, I was wrong here. Please ignore this comment. 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 "Beware of programmers carrying screwdrivers." - Chip Salzenberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/10] ARM Add New Board GEC2410
Dear Wolfgang,
>> - printf("s3c2410_nand_correct_data: not implemented\n");
>> + debugX(1, "s3c2410_nand_correct_data: not implemented\n");
>
> I think this should remain a printf().
Since when booting from nand flash, the printf() is not available in
the early stage, here I replace printf() with debugX() to avoid using
the undefined function.
BR.
Hui.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH (repost)] Nomadik: fix reset_timer()
From: Alessandro Rubini
The timer decrements and READ_TIMER() negates the value read.
Writing 0 in reset_timer() is this wrong, as a readback before 400us
will read back 0 and will report 1780 seconds, so nand operations did
timeout. This patch writes ~0 in reset_timer to prevent this.
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
This must be applied for nand to work. It's a simple bugfix so
I think it got simply forgotten.
BTW: I got no feedback for the lcd/keypad stuff, neither positive
nor negative. Shall I repost my current status in that regard?
thanks
/alessandro
cpu/arm926ejs/nomadik/timer.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpu/arm926ejs/nomadik/timer.c b/cpu/arm926ejs/nomadik/timer.c
index 16067c9..2115b71 100644
--- a/cpu/arm926ejs/nomadik/timer.c
+++ b/cpu/arm926ejs/nomadik/timer.c
@@ -46,10 +46,10 @@ int timer_init(void)
return 0;
}
-/* Restart counting from 0 */
+/* Restart counting from ~0 (can't be 0, since READ_TIMER negates) */
void reset_timer(void)
{
- writel(0, CONFIG_SYS_TIMERBASE + MTU_LR(0)); /* Immediate effect */
+ writel(~0, CONFIG_SYS_TIMERBASE + MTU_LR(0)); /* Immediate effect */
}
/* Return how many HZ passed since "base" */
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Don't inline weak symbols
Hi Wolfgang , I have noticed that the same error as described here (http://lists.denx.de/pipermail/u-boot/2009-October/061913.html) happens when compiling the latest version of U-boot (v2009-11-rc1) using arm-cortex_a8-linux-gnueabi gcc version 4.4.0 (crosstool-ng-hg_defa...@1620_187e06178dcb). Could you please apply the patch described above to resolve this issue? Thanks, Roman. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] ARM Add New Board GEC2410
Dear Minkyu, > I think, It is better to put bottom of s3c24x0 board series. (next to VCMA9) OK, I will fix it and re-send the patch. Thanks. BR. Hui. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_pci_init_port end-point initialization isbroken
> From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Swarthout > Edward L-SWARTHOU > Sent: Monday, November 02, 2009 8:36 PM > To: u-boot@lists.denx.de > Cc: Swarthout Edward L-SWARTHOU > Subject: [U-Boot] [PATCH] fsl_pci_init_port end-point > initialization isbroken > > commit 70ed869e broke fsl pcie end-point initialization. > Returning 0 is not correct. The function must return the > first free bus number for the next controller. > > fsl_pci_init() must still be called and a bus allocated even > if the controller is an end-point. > > Signed-off-by: Ed Swarthout Acked-by: Vivek Mahajan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
> Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > scaning time? > To: leon...@msn.com > CC: u-boot@lists.denx.de > From: joakim.tjernl...@transmode.se > Date: Tue, 3 Nov 2009 12:13:11 +0100 > > HeLei wrote on 03/11/2009 12:08:39: > > > > > Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > > scaning time? > > > CC: leon...@msn.com; u-boot@lists.denx.de > > > From: joakim.tjernl...@transmode.se > > > Date: Tue, 3 Nov 2009 11:55:18 +0100 > > > > > > > > > > > HeLei wrote on 03/11/2009 09:21:04: > > > > > > > > > > Thank you, Jocke > > > > > > > > > - impl. a better crc32(use the one from linux) > > > > > > > > Attaching a very crude port of linux crc32. This boots a linux img > > > > for me and handles the environment crc as well. Feel free > > > > to clean it up and submit to u-boot. > > > > > > > > Jocke > > > > > > So I could not help myself, here is a better port of crc32 to u-boot. > > > You will probably get at small conflict due to LINK_OFF, just remove > > > the LINK_OFF stuff for now. > > > Could you test and report? > > > Do you have a little or big endian target? > > > >I cannot test it for current stage, for project time issue. > >I'll test it and report some time later. > > OK, when then? In the near future or weeks away? Weeks away, I'm sorry. > This week I have to spend time on project. And I have to leave the office for > continuous 3 weeks for my wife will give a birth to my baby:) > > >Our target is ARM11, little endian. > Good, I got big endian(PPC). > > Please trim your replies, including my patch in the reply is just a waste > of space. > > Jocke > _ “游日本，拿现金”MClub白领股神大赛火热报名中 http://club.msn.cn/pr/?a=emoney___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
HeLei wrote on 03/11/2009 12:08:39: > > > Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > scaning time? > > CC: leon...@msn.com; u-boot@lists.denx.de > > From: joakim.tjernl...@transmode.se > > Date: Tue, 3 Nov 2009 11:55:18 +0100 > > > > > > > > HeLei wrote on 03/11/2009 09:21:04: > > > > > > > > Thank you, Jocke > > > > > > > - impl. a better crc32(use the one from linux) > > > > > > Attaching a very crude port of linux crc32. This boots a linux img > > > for me and handles the environment crc as well. Feel free > > > to clean it up and submit to u-boot. > > > > > > Jocke > > > > So I could not help myself, here is a better port of crc32 to u-boot. > > You will probably get at small conflict due to LINK_OFF, just remove > > the LINK_OFF stuff for now. > > Could you test and report? > > Do you have a little or big endian target? > >I cannot test it for current stage, for project time issue. >I'll test it and report some time later. OK, when then? In the near future or weeks away? >Our target is ARM11, little endian. Good, I got big endian(PPC). Please trim your replies, including my patch in the reply is just a waste of space. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM] Clean-up of s3c24x0 header files
Minkyu Kang wrote:
> Dear Kevin Morfitt
>
> 2009/11/3 kevin.morf...@fearnside-systems.co.uk
> :
>> Cleans up the s3c24x0 header files:
>
> Thank you for patch
>
>> s4c24x0.h: removes the use of 'volatile' from the S3C24X0_REG8,
>> S3C24X0_REG16 and S3C24X0_REG32 register typedef's. Registers are always
>> accessed using the IO accessor functions which cast the register address
>> as 'volatile' anyway so it isn't required here.
>>
>> s3c2400.h and s3c2410.h: insert a blank line between the static inline
>> functions.
>>
>> Signed-off-by: Kevin Morfitt
>> ---
>> include/asm-arm/arch-s3c24x0/s3c2400.h | 16
>> include/asm-arm/arch-s3c24x0/s3c2410.h | 17 +
>> include/asm-arm/arch-s3c24x0/s3c24x0.h |6 +++---
>> 3 files changed, 36 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/asm-arm/arch-s3c24x0/s3c2400.h
>> b/include/asm-arm/arch-s3c24x0/s3c2400.h
>> index 26bd4e4..2678be1 100644
>> --- a/include/asm-arm/arch-s3c24x0/s3c2400.h
>> +++ b/include/asm-arm/arch-s3c24x0/s3c2400.h
>> @@ -67,67 +67,83 @@ static inline struct s3c24x0_memctl
>> *s3c24x0_get_base_memctl(void)
>> {
>>return (struct s3c24x0_memctl *)S3C24X0_MEMCTL_BASE;
>> }
>> +
>> static inline struct s3c24x0_usb_host *s3c24x0_get_base_usb_host(void)
>> {
>>return (struct s3c24x0_usb_host *)S3C24X0_USB_HOST_BASE;
>> }
>> +
>> static inline struct s3c24x0_interrupt *s3c24x0_get_base_interrupt(void)
>> {
>>return (struct s3c24x0_interrupt *)S3C24X0_INTERRUPT_BASE;
>> }
>> +
>> static inline struct s3c24x0_dmas *s3c24x0_get_base_dmas(void)
>> {
>>return (struct s3c24x0_dmas *)S3C24X0_DMA_BASE;
>> }
>> +
>> static inline struct s3c24x0_clock_power *s3c24x0_get_base_clock_power(void)
>> {
>>return (struct s3c24x0_clock_power *)S3C24X0_CLOCK_POWER_BASE;
>> }
>> +
>> static inline struct s3c24x0_lcd *s3c24x0_get_base_lcd(void)
>> {
>>return (struct s3c24x0_lcd *)S3C24X0_LCD_BASE;
>> }
>> +
>> static inline struct s3c24x0_uart
>>*s3c24x0_get_base_uart(enum s3c24x0_uarts_nr n)
>> {
>>return (struct s3c24x0_uart *)(S3C24X0_UART_BASE + (n * 0x4000));
>> }
>> +
>> static inline struct s3c24x0_timers *s3c24x0_get_base_timers(void)
>> {
>>return (struct s3c24x0_timers *)S3C24X0_TIMER_BASE;
>> }
>> +
>> static inline struct s3c24x0_usb_device *s3c24x0_get_base_usb_device(void)
>> {
>>return (struct s3c24x0_usb_device *)S3C24X0_USB_DEVICE_BASE;
>> }
>> +
>> static inline struct s3c24x0_watchdog *s3c24x0_get_base_watchdog(void)
>> {
>>return (struct s3c24x0_watchdog *)S3C24X0_WATCHDOG_BASE;
>> }
>> +
>> static inline struct s3c24x0_i2c *s3c24x0_get_base_i2c(void)
>> {
>>return (struct s3c24x0_i2c *)S3C24X0_I2C_BASE;
>> }
>> +
>> static inline struct s3c24x0_i2s *s3c24x0_get_base_i2s(void)
>> {
>>return (struct s3c24x0_i2s *)S3C24X0_I2S_BASE;
>> }
>> +
>> static inline struct s3c24x0_gpio *s3c24x0_get_base_gpio(void)
>> {
>>return (struct s3c24x0_gpio *)S3C24X0_GPIO_BASE;
>> }
>> +
>> static inline struct s3c24x0_rtc *s3c24x0_get_base_rtc(void)
>> {
>>return (struct s3c24x0_rtc *)S3C24X0_RTC_BASE;
>> }
>> +
>> static inline struct s3c2400_adc *s3c2400_get_base_adc(void)
>> {
>>return (struct s3c2400_adc *)S3C24X0_ADC_BASE;
>> }
>> +
>> static inline struct s3c24x0_spi *s3c24x0_get_base_spi(void)
>> {
>>return (struct s3c24x0_spi *)S3C24X0_SPI_BASE;
>> }
>> +
>> static inline struct s3c2400_mmc *s3c2400_get_base_mmc(void)
>> {
>>return (struct s3c2400_mmc *)S3C2400_MMC_BASE;
>> diff --git a/include/asm-arm/arch-s3c24x0/s3c2410.h
>> b/include/asm-arm/arch-s3c24x0/s3c2410.h
>> index be2e76e..0543fe1 100644
>> --- a/include/asm-arm/arch-s3c24x0/s3c2410.h
>> +++ b/include/asm-arm/arch-s3c24x0/s3c2410.h
>> @@ -73,71 +73,88 @@ static inline struct s3c24x0_memctl
>> *s3c24x0_get_base_memctl(void)
>> {
>>return (struct s3c24x0_memctl *)S3C24X0_MEMCTL_BASE;
>> }
>> +
>> static inline struct s3c24x0_usb_host *s3c24x0_get_base_usb_host(void)
>> {
>>return (struct s3c24x0_usb_host *)S3C24X0_USB_HOST_BASE;
>> }
>> +
>> static inline struct s3c24x0_interrupt *s3c24x0_get_base_interrupt(void)
>> {
>>return (struct s3c24x0_interrupt *)S3C24X0_INTERRUPT_BASE;
>> }
>> +
>> static inline struct s3c24x0_dmas *s3c24x0_get_base_dmas(void)
>> {
>>return (struct s3c24x0_dmas *)S3C24X0_DMA_BASE;
>> }
>> +
>> static inline struct s3c24x0_clock_power *s3c24x0_get_base_clock_power(void)
>> {
>>return (struct s3c24x0_clock_power *)S3C24X0_CLOCK_POWER_BASE;
>> }
>> +
>> static inline struct s3c24x0_lcd *s3c24x0_get_base_lcd(void)
>> {
>>return (struct s3c24x0_lcd *)S3C24X0_LCD_BASE;
>> }
>> +
>> static inline struct s3c2410_nand *s3c2410_get_base_nand(void)
>> {
>>return (struct s3c2410_nand *)S3C2410_NAND_BASE;
>> }
>> +
>> static inline struct s3c24x0_uart
>>*s3c
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
> Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2
> scaning time?
> CC: leon...@msn.com; u-boot@lists.denx.de
> From: joakim.tjernl...@transmode.se
> Date: Tue, 3 Nov 2009 11:55:18 +0100
>
> >
> > HeLei wrote on 03/11/2009 09:21:04:
> > >
> > > Thank you, Jocke
>
> > > > - impl. a better crc32(use the one from linux)
> >
> > Attaching a very crude port of linux crc32. This boots a linux img
> > for me and handles the environment crc as well. Feel free
> > to clean it up and submit to u-boot.
> >
> > Jocke
>
> So I could not help myself, here is a better port of crc32 to u-boot.
> You will probably get at small conflict due to LINK_OFF, just remove
> the LINK_OFF stuff for now.
> Could you test and report?
> Do you have a little or big endian target?
I cannot test it for current stage, for project time issue. I'll test it
and report some time later. Our target is ARM11, little endian.
>
> Jocke
>
>
> From 7b98aab2aa940b47b81d3a548c8d786016cd2ee8 Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund
> Date: Tue, 3 Nov 2009 11:39:43 +0100
> Subject: [PATCH] crc32: Impl. linux optimized crc32()
>
> Ported over the more efficient linux crc32() function.
> ---
> lib_generic/crc32.c | 208
> +--
> 1 files changed, 117 insertions(+), 91 deletions(-)
>
> diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c
> index 2e11548..d3bb92b 100644
> --- a/lib_generic/crc32.c
> +++ b/lib_generic/crc32.c
> @@ -13,6 +13,7 @@
> #else
> #include
> #endif
> +#include
>
> #if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
> #include
> @@ -52,6 +53,7 @@ local void make_crc_table OF((void));
>the information needed to generate CRC's on data a byte at a time for all
>combinations of CRC register values and incoming bytes.
> */
> +#define tole(x) cpu_to_le32(x)
> local void make_crc_table()
> {
>uint32_t c;
> @@ -70,7 +72,7 @@ local void make_crc_table()
> c = (uLong)n;
> for (k = 0; k < 8; k++)
>c = c & 1 ? poly ^ (c >> 1) : c >> 1;
> -crc_table[n] = c;
> +crc_table[n] = tole(c);
>}
>crc_table_empty = 0;
> }
> @@ -78,59 +80,73 @@ local void make_crc_table()
> /*
> * Table of CRC-32's of all single-byte values (made by make_crc_table)
> */
> +#define tole(x) __constant_cpu_to_le32(x)
> +
> local const uint32_t crc_table[256] = {
> - 0xL, 0x77073096L, 0xee0e612cL, 0x990951baL, 0x076dc419L,
> - 0x706af48fL, 0xe963a535L, 0x9e6495a3L, 0x0edb8832L, 0x79dcb8a4L,
> - 0xe0d5e91eL, 0x97d2d988L, 0x09b64c2bL, 0x7eb17cbdL, 0xe7b82d07L,
> - 0x90bf1d91L, 0x1db71064L, 0x6ab020f2L, 0xf3b97148L, 0x84be41deL,
> - 0x1adad47dL, 0x6ddde4ebL, 0xf4d4b551L, 0x83d385c7L, 0x136c9856L,
> - 0x646ba8c0L, 0xfd62f97aL, 0x8a65c9ecL, 0x14015c4fL, 0x63066cd9L,
> - 0xfa0f3d63L, 0x8d080df5L, 0x3b6e20c8L, 0x4c69105eL, 0xd56041e4L,
> - 0xa2677172L, 0x3c03e4d1L, 0x4b04d447L, 0xd20d85fdL, 0xa50ab56bL,
> - 0x35b5a8faL, 0x42b2986cL, 0xdbbbc9d6L, 0xacbcf940L, 0x32d86ce3L,
> - 0x45df5c75L, 0xdcd60dcfL, 0xabd13d59L, 0x26d930acL, 0x51de003aL,
> - 0xc8d75180L, 0xbfd06116L, 0x21b4f4b5L, 0x56b3c423L, 0xcfba9599L,
> - 0xb8bda50fL, 0x2802b89eL, 0x5f058808L, 0xc60cd9b2L, 0xb10be924L,
> - 0x2f6f7c87L, 0x58684c11L, 0xc1611dabL, 0xb6662d3dL, 0x76dc4190L,
> - 0x01db7106L, 0x98d220bcL, 0xefd5102aL, 0x71b18589L, 0x06b6b51fL,
> - 0x9fbfe4a5L, 0xe8b8d433L, 0x7807c9a2L, 0x0f00f934L, 0x9609a88eL,
> - 0xe10e9818L, 0x7f6a0dbbL, 0x086d3d2dL, 0x91646c97L, 0xe6635c01L,
> - 0x6b6b51f4L, 0x1c6c6162L, 0x856530d8L, 0xf262004eL, 0x6c0695edL,
> - 0x1b01a57bL, 0x8208f4c1L, 0xf50fc457L, 0x65b0d9c6L, 0x12b7e950L,
> - 0x8bbeb8eaL, 0xfcb9887cL, 0x62dd1ddfL, 0x15da2d49L, 0x8cd37cf3L,
> - 0xfbd44c65L, 0x4db26158L, 0x3ab551ceL, 0xa3bc0074L, 0xd4bb30e2L,
> - 0x4adfa541L, 0x3dd895d7L, 0xa4d1c46dL, 0xd3d6f4fbL, 0x4369e96aL,
> - 0x346ed9fcL, 0xad678846L, 0xda60b8d0L, 0x44042d73L, 0x33031de5L,
> - 0xaa0a4c5fL, 0xdd0d7cc9L, 0x5005713cL, 0x270241aaL, 0xbe0b1010L,
> - 0xc90c2086L, 0x5768b525L, 0x206f85b3L, 0xb966d409L, 0xce61e49fL,
> - 0x5edef90eL, 0x29d9c998L, 0xb0d09822L, 0xc7d7a8b4L, 0x59b33d17L,
> - 0x2eb40d81L, 0xb7bd5c3bL, 0xc0ba6cadL, 0xedb88320L, 0x9abfb3b6L,
> - 0x03b6e20cL, 0x74b1d29aL, 0xead54739L, 0x9dd277afL, 0x04db2615L,
> - 0x73dc1683L, 0xe3630b12L, 0x94643b84L, 0x0d6d6a3eL, 0x7a6a5aa8L,
> - 0xe40ecf0bL, 0x9309ff9dL, 0x0a00ae27L, 0x7d079eb1L, 0xf00f9344L,
> - 0x8708a3d2L, 0x1e01f268L, 0x6906c2feL, 0xf762575dL, 0x806567cbL,
> - 0x196c3671L, 0x6e6b06e7L, 0xfed41b76L, 0x89d32be0L, 0x10da7a5aL,
> - 0x67dd4accL, 0xf9b9df6fL, 0x8ebeeff9L, 0x17b7be43L, 0x60b08ed5L,
> - 0xd6d6a3e8L, 0xa1d1937eL, 0x38d8c2c4L, 0x4fdff252L, 0xd1bb67f1L,
> - 0xa6bc5767L, 0x3fb506ddL, 0x48b2364bL, 0xd80d2bdaL, 0xaf0a1b4cL,
> - 0x36034af6L, 0x41047a60L, 0xdf60efc3L, 0xa867df55L, 0x316e8eefL,
> - 0x4669be79L, 0xcb61b38cL, 0xbc66831aL, 0x256fd2a0L, 0
[U-Boot] Support dbox in mainline, was: Re: [STATUS] v2009.11-rc1 is out
Am Tue, 03 Nov 2009 11:47:08 +0100 schrieb Detlev Zundel: >> After unpacking U-Boot 2009.08 these files are copied into the source >> tree: http://cvs.tuxbox.org/tuxbox/boot/u-boot-tuxbox/ > > Ah uh, I would even offer some help in the process (like adding a branch > in the u-boot-testing repository), but this instruction is somewhat > unspecific, i.e. I see three boards being supported. If we want to get > the support mainline, we should start with only one of them - including > only the neccessary changes, i.e. cpu/ppc4xx/serial_sicc.c is very > likely not relevant for the dbox :) > the Dreambox files are not used atm, they were added 5 years ago, I never cared about them. The IPBox stuff is used with U-Boot 1.2.0, I do not have plans to upgrade to a more recent U-Boot version because I do not have the hardware for testing. So only the Dbox is left, and yes, merging it will be fun;) Our code includes functions to read files (config, logos) from a JFFS2 partition, display LCD and framebuffer logos during boot, some unfinished support for booting from HDD and loading kernels from Squashfs partitions. The Squashfs code is based on Squashfs 3.0, it can not be upgrade to 3.3 or 4.x because we use Linux 2.4.37.6, where Squashfs > 3.0 is not available. Squashfs support in U-Boot also includes optional LZMA support, but not the LZMA 4.65-based code from U-Boot, but LZMA 4.40 included in fs/ squashfs/. It is therefore not possible to link both LZMA libs into U- Boot at compile time. This is not needed for us because the root filesystem is either Squashfs/LZMA-4.40 or JFFS2/LZMA-4.65. As hinted before, I do not have much C skills to do necessary cleanups nor do I want to be mentioned as official maintainer ;) But the code is in use for many years by lots of users so technically there should not be many problems. Cheers, rhabarber1848 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
>
> HeLei wrote on 03/11/2009 09:21:04:
> >
> > Thank you, Jocke
> > > - impl. a better crc32(use the one from linux)
>
> Attaching a very crude port of linux crc32. This boots a linux img
> for me and handles the environment crc as well. Feel free
> to clean it up and submit to u-boot.
>
> Jocke
So I could not help myself, here is a better port of crc32 to u-boot.
You will probably get at small conflict due to LINK_OFF, just remove
the LINK_OFF stuff for now.
Could you test and report?
Do you have a little or big endian target?
Jocke
>From 7b98aab2aa940b47b81d3a548c8d786016cd2ee8 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund
Date: Tue, 3 Nov 2009 11:39:43 +0100
Subject: [PATCH] crc32: Impl. linux optimized crc32()
Ported over the more efficient linux crc32() function.
---
lib_generic/crc32.c | 208 +--
1 files changed, 117 insertions(+), 91 deletions(-)
diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c
index 2e11548..d3bb92b 100644
--- a/lib_generic/crc32.c
+++ b/lib_generic/crc32.c
@@ -13,6 +13,7 @@
#else
#include
#endif
+#include
#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
#include
@@ -52,6 +53,7 @@ local void make_crc_table OF((void));
the information needed to generate CRC's on data a byte at a time for all
combinations of CRC register values and incoming bytes.
*/
+#define tole(x) cpu_to_le32(x)
local void make_crc_table()
{
uint32_t c;
@@ -70,7 +72,7 @@ local void make_crc_table()
c = (uLong)n;
for (k = 0; k < 8; k++)
c = c & 1 ? poly ^ (c >> 1) : c >> 1;
-crc_table[n] = c;
+crc_table[n] = tole(c);
}
crc_table_empty = 0;
}
@@ -78,59 +80,73 @@ local void make_crc_table()
/*
* Table of CRC-32's of all single-byte values (made by make_crc_table)
*/
+#define tole(x) __constant_cpu_to_le32(x)
+
local const uint32_t crc_table[256] = {
- 0xL, 0x77073096L, 0xee0e612cL, 0x990951baL, 0x076dc419L,
- 0x706af48fL, 0xe963a535L, 0x9e6495a3L, 0x0edb8832L, 0x79dcb8a4L,
- 0xe0d5e91eL, 0x97d2d988L, 0x09b64c2bL, 0x7eb17cbdL, 0xe7b82d07L,
- 0x90bf1d91L, 0x1db71064L, 0x6ab020f2L, 0xf3b97148L, 0x84be41deL,
- 0x1adad47dL, 0x6ddde4ebL, 0xf4d4b551L, 0x83d385c7L, 0x136c9856L,
- 0x646ba8c0L, 0xfd62f97aL, 0x8a65c9ecL, 0x14015c4fL, 0x63066cd9L,
- 0xfa0f3d63L, 0x8d080df5L, 0x3b6e20c8L, 0x4c69105eL, 0xd56041e4L,
- 0xa2677172L, 0x3c03e4d1L, 0x4b04d447L, 0xd20d85fdL, 0xa50ab56bL,
- 0x35b5a8faL, 0x42b2986cL, 0xdbbbc9d6L, 0xacbcf940L, 0x32d86ce3L,
- 0x45df5c75L, 0xdcd60dcfL, 0xabd13d59L, 0x26d930acL, 0x51de003aL,
- 0xc8d75180L, 0xbfd06116L, 0x21b4f4b5L, 0x56b3c423L, 0xcfba9599L,
- 0xb8bda50fL, 0x2802b89eL, 0x5f058808L, 0xc60cd9b2L, 0xb10be924L,
- 0x2f6f7c87L, 0x58684c11L, 0xc1611dabL, 0xb6662d3dL, 0x76dc4190L,
- 0x01db7106L, 0x98d220bcL, 0xefd5102aL, 0x71b18589L, 0x06b6b51fL,
- 0x9fbfe4a5L, 0xe8b8d433L, 0x7807c9a2L, 0x0f00f934L, 0x9609a88eL,
- 0xe10e9818L, 0x7f6a0dbbL, 0x086d3d2dL, 0x91646c97L, 0xe6635c01L,
- 0x6b6b51f4L, 0x1c6c6162L, 0x856530d8L, 0xf262004eL, 0x6c0695edL,
- 0x1b01a57bL, 0x8208f4c1L, 0xf50fc457L, 0x65b0d9c6L, 0x12b7e950L,
- 0x8bbeb8eaL, 0xfcb9887cL, 0x62dd1ddfL, 0x15da2d49L, 0x8cd37cf3L,
- 0xfbd44c65L, 0x4db26158L, 0x3ab551ceL, 0xa3bc0074L, 0xd4bb30e2L,
- 0x4adfa541L, 0x3dd895d7L, 0xa4d1c46dL, 0xd3d6f4fbL, 0x4369e96aL,
- 0x346ed9fcL, 0xad678846L, 0xda60b8d0L, 0x44042d73L, 0x33031de5L,
- 0xaa0a4c5fL, 0xdd0d7cc9L, 0x5005713cL, 0x270241aaL, 0xbe0b1010L,
- 0xc90c2086L, 0x5768b525L, 0x206f85b3L, 0xb966d409L, 0xce61e49fL,
- 0x5edef90eL, 0x29d9c998L, 0xb0d09822L, 0xc7d7a8b4L, 0x59b33d17L,
- 0x2eb40d81L, 0xb7bd5c3bL, 0xc0ba6cadL, 0xedb88320L, 0x9abfb3b6L,
- 0x03b6e20cL, 0x74b1d29aL, 0xead54739L, 0x9dd277afL, 0x04db2615L,
- 0x73dc1683L, 0xe3630b12L, 0x94643b84L, 0x0d6d6a3eL, 0x7a6a5aa8L,
- 0xe40ecf0bL, 0x9309ff9dL, 0x0a00ae27L, 0x7d079eb1L, 0xf00f9344L,
- 0x8708a3d2L, 0x1e01f268L, 0x6906c2feL, 0xf762575dL, 0x806567cbL,
- 0x196c3671L, 0x6e6b06e7L, 0xfed41b76L, 0x89d32be0L, 0x10da7a5aL,
- 0x67dd4accL, 0xf9b9df6fL, 0x8ebeeff9L, 0x17b7be43L, 0x60b08ed5L,
- 0xd6d6a3e8L, 0xa1d1937eL, 0x38d8c2c4L, 0x4fdff252L, 0xd1bb67f1L,
- 0xa6bc5767L, 0x3fb506ddL, 0x48b2364bL, 0xd80d2bdaL, 0xaf0a1b4cL,
- 0x36034af6L, 0x41047a60L, 0xdf60efc3L, 0xa867df55L, 0x316e8eefL,
- 0x4669be79L, 0xcb61b38cL, 0xbc66831aL, 0x256fd2a0L, 0x5268e236L,
- 0xcc0c7795L, 0xbb0b4703L, 0x220216b9L, 0x5505262fL, 0xc5ba3bbeL,
- 0xb2bd0b28L, 0x2bb45a92L, 0x5cb36a04L, 0xc2d7ffa7L, 0xb5d0cf31L,
- 0x2cd99e8bL, 0x5bdeae1dL, 0x9b64c2b0L, 0xec63f226L, 0x756aa39cL,
- 0x026d930aL, 0x9c0906a9L, 0xeb0e363fL, 0x72076785L, 0x05005713L,
- 0x95bf4a82L, 0xe2b87a14L, 0x7bb12baeL, 0x0cb61b38L, 0x92d28e9bL,
- 0xe5d5be0dL, 0x7cdcefb7L, 0x0bdbdf21L, 0x86d3d2d4L, 0xf1d4e242L,
- 0x68ddb3f8L, 0x1fda836eL, 0x81be16cdL, 0xf6b9265bL, 0x6fb077e1L,
- 0x18b74777L, 0x88085ae6L, 0xff0f6a70L, 0x66063bcaL, 0x11010b5cL,
- 0x8f659effL, 0xf86
Re: [U-Boot] [PATCH ARM] Clean-up of s3c24x0 header files
Dear Kevin Morfitt
2009/11/3 kevin.morf...@fearnside-systems.co.uk
:
> Cleans up the s3c24x0 header files:
Thank you for patch
>
> s4c24x0.h: removes the use of 'volatile' from the S3C24X0_REG8,
> S3C24X0_REG16 and S3C24X0_REG32 register typedef's. Registers are always
> accessed using the IO accessor functions which cast the register address
> as 'volatile' anyway so it isn't required here.
>
> s3c2400.h and s3c2410.h: insert a blank line between the static inline
> functions.
>
> Signed-off-by: Kevin Morfitt
> ---
> include/asm-arm/arch-s3c24x0/s3c2400.h | 16
> include/asm-arm/arch-s3c24x0/s3c2410.h | 17 +
> include/asm-arm/arch-s3c24x0/s3c24x0.h | 6 +++---
> 3 files changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/include/asm-arm/arch-s3c24x0/s3c2400.h
> b/include/asm-arm/arch-s3c24x0/s3c2400.h
> index 26bd4e4..2678be1 100644
> --- a/include/asm-arm/arch-s3c24x0/s3c2400.h
> +++ b/include/asm-arm/arch-s3c24x0/s3c2400.h
> @@ -67,67 +67,83 @@ static inline struct s3c24x0_memctl
> *s3c24x0_get_base_memctl(void)
> {
> return (struct s3c24x0_memctl *)S3C24X0_MEMCTL_BASE;
> }
> +
> static inline struct s3c24x0_usb_host *s3c24x0_get_base_usb_host(void)
> {
> return (struct s3c24x0_usb_host *)S3C24X0_USB_HOST_BASE;
> }
> +
> static inline struct s3c24x0_interrupt *s3c24x0_get_base_interrupt(void)
> {
> return (struct s3c24x0_interrupt *)S3C24X0_INTERRUPT_BASE;
> }
> +
> static inline struct s3c24x0_dmas *s3c24x0_get_base_dmas(void)
> {
> return (struct s3c24x0_dmas *)S3C24X0_DMA_BASE;
> }
> +
> static inline struct s3c24x0_clock_power *s3c24x0_get_base_clock_power(void)
> {
> return (struct s3c24x0_clock_power *)S3C24X0_CLOCK_POWER_BASE;
> }
> +
> static inline struct s3c24x0_lcd *s3c24x0_get_base_lcd(void)
> {
> return (struct s3c24x0_lcd *)S3C24X0_LCD_BASE;
> }
> +
> static inline struct s3c24x0_uart
> *s3c24x0_get_base_uart(enum s3c24x0_uarts_nr n)
> {
> return (struct s3c24x0_uart *)(S3C24X0_UART_BASE + (n * 0x4000));
> }
> +
> static inline struct s3c24x0_timers *s3c24x0_get_base_timers(void)
> {
> return (struct s3c24x0_timers *)S3C24X0_TIMER_BASE;
> }
> +
> static inline struct s3c24x0_usb_device *s3c24x0_get_base_usb_device(void)
> {
> return (struct s3c24x0_usb_device *)S3C24X0_USB_DEVICE_BASE;
> }
> +
> static inline struct s3c24x0_watchdog *s3c24x0_get_base_watchdog(void)
> {
> return (struct s3c24x0_watchdog *)S3C24X0_WATCHDOG_BASE;
> }
> +
> static inline struct s3c24x0_i2c *s3c24x0_get_base_i2c(void)
> {
> return (struct s3c24x0_i2c *)S3C24X0_I2C_BASE;
> }
> +
> static inline struct s3c24x0_i2s *s3c24x0_get_base_i2s(void)
> {
> return (struct s3c24x0_i2s *)S3C24X0_I2S_BASE;
> }
> +
> static inline struct s3c24x0_gpio *s3c24x0_get_base_gpio(void)
> {
> return (struct s3c24x0_gpio *)S3C24X0_GPIO_BASE;
> }
> +
> static inline struct s3c24x0_rtc *s3c24x0_get_base_rtc(void)
> {
> return (struct s3c24x0_rtc *)S3C24X0_RTC_BASE;
> }
> +
> static inline struct s3c2400_adc *s3c2400_get_base_adc(void)
> {
> return (struct s3c2400_adc *)S3C24X0_ADC_BASE;
> }
> +
> static inline struct s3c24x0_spi *s3c24x0_get_base_spi(void)
> {
> return (struct s3c24x0_spi *)S3C24X0_SPI_BASE;
> }
> +
> static inline struct s3c2400_mmc *s3c2400_get_base_mmc(void)
> {
> return (struct s3c2400_mmc *)S3C2400_MMC_BASE;
> diff --git a/include/asm-arm/arch-s3c24x0/s3c2410.h
> b/include/asm-arm/arch-s3c24x0/s3c2410.h
> index be2e76e..0543fe1 100644
> --- a/include/asm-arm/arch-s3c24x0/s3c2410.h
> +++ b/include/asm-arm/arch-s3c24x0/s3c2410.h
> @@ -73,71 +73,88 @@ static inline struct s3c24x0_memctl
> *s3c24x0_get_base_memctl(void)
> {
> return (struct s3c24x0_memctl *)S3C24X0_MEMCTL_BASE;
> }
> +
> static inline struct s3c24x0_usb_host *s3c24x0_get_base_usb_host(void)
> {
> return (struct s3c24x0_usb_host *)S3C24X0_USB_HOST_BASE;
> }
> +
> static inline struct s3c24x0_interrupt *s3c24x0_get_base_interrupt(void)
> {
> return (struct s3c24x0_interrupt *)S3C24X0_INTERRUPT_BASE;
> }
> +
> static inline struct s3c24x0_dmas *s3c24x0_get_base_dmas(void)
> {
> return (struct s3c24x0_dmas *)S3C24X0_DMA_BASE;
> }
> +
> static inline struct s3c24x0_clock_power *s3c24x0_get_base_clock_power(void)
> {
> return (struct s3c24x0_clock_power *)S3C24X0_CLOCK_POWER_BASE;
> }
> +
> static inline struct s3c24x0_lcd *s3c24x0_get_base_lcd(void)
> {
> return (struct s3c24x0_lcd *)S3C24X0_LCD_BASE;
> }
> +
> static inline struct s3c2410_nand *s3c2410_get_base_nand(void)
> {
> return (struct s3c2410_nand *)S3C2410_NAND_BASE;
> }
> +
> static inline struct s3c24x0_uart
> *s3c24x0_get_base_uart(enum s3c24x0_uarts_nr n)
> {
> return (struct s3c24x0_uart *)(S3C24X0_UART_BASE + (n * 0x4000));
> }
> +
> static inline struct s3c24x0_timers *s3c24x0_g
Re: [U-Boot] [STATUS] v2009.11-rc1 is out
Hi rhabarber1848, >> Grepping through my source, I cannot find such a configuration - do you >> plan to submit this support here sometime? > > the code was written by other people and is maintained out-of-uboot-tree > in our public CVS. So why not move mainline? Usually it's pretty fun to get other peoples code into mainline *lol* > After unpacking U-Boot 2009.08 these files are copied into the source > tree: http://cvs.tuxbox.org/tuxbox/boot/u-boot-tuxbox/ Ah uh, I would even offer some help in the process (like adding a branch in the u-boot-testing repository), but this instruction is somewhat unspecific, i.e. I see three boards being supported. If we want to get the support mainline, we should start with only one of them - including only the neccessary changes, i.e. cpu/ppc4xx/serial_sicc.c is very likely not relevant for the dbox :) > Then this patch is applied > http://cvs.tuxbox.org/tuxbox/cdk/Patches/u-boot-2009.08.diff?view=markup > > This is the board config used: > http://cvs.tuxbox.org/tuxbox/cdk/config/u-boot.dbox2.h.m4?view=markup > > I do not know if the code meets U-Boot coding standards, but it works ;) > Adding the code to the U-Boot tree makes sense but I think I do not have > the needed skills to support it in the future. You will learn the skills while doing it - no problem. >> Apart from that, I'd strongly start looking for implications of the >> recent rewrite of the relocation strategy to code not in mainline. > > Ah, this is the message I was waiting for. After 2009.08 I did not follow > the coding process due to lack of time so I am sure I missed something. > Do you mean "[TESTING PATCH] ppc: Relocation test patch" from Sep 12th? > Btw, I am using gcc-3.4.6. This is a rather long story, but it starts with this commit: commit 858290178f222d998b6425d85cf06822467918f3 Author: Peter Tyser Date: Mon Sep 21 11:20:25 2009 -0500 ppc: Enable full relocation to RAM The following changes allow U-Boot to fully relocate from flash to RAM: - Remove linker scripts' .fixup sections from the .text section - Add -mrelocatable to PLATFORM_RELFLAGS for all boards - Define CONFIG_RELOC_FIXUP_WORKS for all boards Previously, U-Boot would partially relocate, but statically initialized pointers needed to be manually relocated. Signed-off-by: Peter Tyser On top of this many fixes have been provided already. Just grep for "relocat" in "git log". Cheers Detlev -- These days, even the most pure and abstract mathematics is in danger to be applied. -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2009.11-rc1 is out
Am Tue, 03 Nov 2009 10:37:41 +0100 schrieb Detlev Zundel: > Apart from that, I'd strongly start looking for implications of the > recent rewrite of the relocation strategy to code not in mainline. Hi, with great relieve I can say the removing "*(.fixup)" from the *.lds files solved the problem: U-Boot 2009.11 (Tuxbox) (Nov 03 2009 - 11:36:34) CPU: PPC823ZTnnB2 at 66 MHz: 2 kB I-Cache 1 kB D-Cache Board: DBOX2, Sagem, BMon V1.0 Watchdog enabled I2C: ready DRAM: 64 MB FLASH: 8 MB FB:ready In:serial Out: serial Err: serial Net: SCC ETHERNET BOOTP broadcast 1 Cheers, rhabarber1848 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: write command for RAW partition.
This patch implements write support to usb device with raw partition.
It will be useful for filesystem write support to usb device from
u-boot in future.
Tested with writing kernel image to raw usb disk & booting with usb
read command into ram.
[Note: run usb part to get info about start sector & number of
sectors on a partition for usb write operation.]
Signed-off-by: Mahavir Jain
---
common/cmd_usb.c | 24
common/usb_storage.c | 99 ++
2 files changed, 123 insertions(+), 0 deletions(-)
diff --git a/common/cmd_usb.c b/common/cmd_usb.c
index 7b8ee6b..1acb6fc 100644
--- a/common/cmd_usb.c
+++ b/common/cmd_usb.c
@@ -642,6 +642,28 @@ int do_usb(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
return 1;
}
}
+ if (strcmp(argv[1], "write") == 0) {
+ if (usb_stor_curr_dev < 0) {
+ printf("no current device selected\n");
+ return 1;
+ }
+ if (argc == 5) {
+ unsigned long addr = simple_strtoul(argv[2], NULL, 16);
+ unsigned long blk = simple_strtoul(argv[3], NULL, 16);
+ unsigned long cnt = simple_strtoul(argv[4], NULL, 16);
+ unsigned long n;
+ printf("\nUSB write: device %d block # %ld, count %ld"
+ " ... ", usb_stor_curr_dev, blk, cnt);
+ stor_dev = usb_stor_get_dev(usb_stor_curr_dev);
+ n = stor_dev->block_write(usb_stor_curr_dev, blk, cnt,
+ (ulong *)addr);
+ printf("%ld blocks write: %s\n", n,
+ (n == cnt) ? "OK" : "ERROR");
+ if (n == cnt)
+ return 0;
+ return 1;
+ }
+ }
if (strncmp(argv[1], "dev", 3) == 0) {
if (argc == 3) {
int dev = (int)simple_strtoul(argv[2], NULL, 10);
@@ -687,6 +709,8 @@ U_BOOT_CMD(
" devices\n"
"usb read addr blk# cnt - read `cnt' blocks starting at block `blk#'\n"
"to memory address `addr'"
+ "usb write addr blk# cnt - write `cnt' blocks starting at block
`blk#'\n"
+ "from memory address `addr'"
);
diff --git a/common/usb_storage.c b/common/usb_storage.c
index 19613f2..ed5b3f3 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -168,6 +168,8 @@ int usb_storage_probe(struct usb_device *dev, unsigned int
ifnum,
struct us_data *ss);
unsigned long usb_stor_read(int device, unsigned long blknr,
unsigned long blkcnt, void *buffer);
+unsigned long usb_stor_write(int device, unsigned long blknr,
+unsigned long blkcnt, const void *buffer);
struct usb_device * usb_get_dev_index(int index);
void uhci_show_temp_int_td(void);
@@ -227,6 +229,7 @@ int usb_stor_scan(int mode)
usb_dev_desc[i].dev = i;
usb_dev_desc[i].part_type = PART_TYPE_UNKNOWN;
usb_dev_desc[i].block_read = usb_stor_read;
+ usb_dev_desc[i].block_write = usb_stor_write;
}
usb_max_devs = 0;
@@ -964,6 +967,22 @@ static int usb_read_10(ccb *srb, struct us_data *ss,
unsigned long start,
return ss->transport(srb, ss);
}
+static int usb_write_10(ccb *srb, struct us_data *ss, unsigned long start,
+ unsigned short blocks)
+{
+ memset(&srb->cmd[0], 0, 12);
+ srb->cmd[0] = SCSI_WRITE10;
+ srb->cmd[2] = ((unsigned char) (start >> 24)) & 0xff;
+ srb->cmd[3] = ((unsigned char) (start >> 16)) & 0xff;
+ srb->cmd[4] = ((unsigned char) (start >> 8)) & 0xff;
+ srb->cmd[5] = ((unsigned char) (start)) & 0xff;
+ srb->cmd[7] = ((unsigned char) (blocks >> 8)) & 0xff;
+ srb->cmd[8] = (unsigned char) blocks & 0xff;
+ srb->cmdlen = 12;
+ USB_STOR_PRINTF("write10: start %lx blocks %x\n", start, blocks);
+ return ss->transport(srb, ss);
+}
+
#ifdef CONFIG_USB_BIN_FIXUP
/*
@@ -1065,6 +1084,86 @@ retry_it:
return blkcnt;
}
+#define USB_MAX_WRITE_BLK 20
+
+unsigned long usb_stor_write(int device, unsigned long blknr,
+ unsigned long blkcnt, const void *buffer)
+{
+ unsigned long start, blks, buf_addr;
+ unsigned short smallblks;
+ struct usb_device *dev;
+ int retry, i;
+ ccb *srb = &usb_ccb;
+
+ if (blkcnt == 0)
+ return 0;
+
+ device &= 0xff;
+ /* Setup device */
+ USB_STOR_PRINTF("\nusb_write: dev %d \n", device);
+ dev = NULL;
+ for (i = 0; i < USB_MAX_DEVICE; i++) {
+ dev = usb_get_dev_index(i);
+ if (dev == NULL)
+ return 0;
+
Re: [U-Boot] [PATCH 04/10] ARM Add New Board GEC2410
Dear Hui Tang 2009/11/3 Hui Tang : > Dear Wolfgang, > > 2009/11/1 Wolfgang Denk : >> Dear "Hui.Tang", >> >> In message >> <6c7a9a5dcafb1f535ed33cb29d579db993846325.1256898456.git.zetal...@gmail.com> >> you wrote: >>> Add gec2410_config option for GEC2410 >>> >>> Signed-off-by: Hui.Tang >>> --- >>> Makefile | 7 +++ >>> 1 files changed, 7 insertions(+), 0 deletions(-) >> >> This belongs all in one commit. >> >>> index bcb3fe9..2de0b1d 100644 >>> --- a/Makefile >>> +++ b/Makefile >>> @@ -2951,6 +2951,13 @@ davinci_dm365evm_config : unconfig >>> davinci_dm6467evm_config : unconfig >>> @$(MKCONFIG) $(@:_config=) arm arm926ejs dm6467evm davinci davinci >>> >>> +gec2410_config : unconfig >>> + @mkdir -p $(obj)include $(obj)board/gec/gec2410 >>> + @mkdir -p $(obj)nand_spl/board/gec/gec2410 >>> + @echo "RAM_TEXT = 0x33e0" >> $(obj)board/gec/gec2410/config.tmp >>> + @$(MKCONFIG) $(@:_config=) arm arm920t gec2410 gec s3c24x0 >>> + @echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk >>> + >>> imx27lite_config: unconfig >>> @$(MKCONFIG) $(@:_config=) arm arm926ejs imx27lite logicpd mx27 >> >> An ARM920 board does not belong into the arm926ejs block. >> > > I have put the board config in the part of > > > ## ARM Integrator boards - see doc/README-integrator for more info. > > as the sbc2410x_config does, > > Would you please give me some advice where should I put the gec2410 > board config? I think, It is better to put bottom of s3c24x0 board series. (next to VCMA9) > > Thanks. > > BR. > Hui. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2009.11-rc1 is out
Hi, Am Tue, 03 Nov 2009 10:37:41 +0100 schrieb Detlev Zundel: > Grepping through my source, I cannot find such a configuration - do you > plan to submit this support here sometime? the code was written by other people and is maintained out-of-uboot-tree in our public CVS. After unpacking U-Boot 2009.08 these files are copied into the source tree: http://cvs.tuxbox.org/tuxbox/boot/u-boot-tuxbox/ Then this patch is applied http://cvs.tuxbox.org/tuxbox/cdk/Patches/u-boot-2009.08.diff?view=markup This is the board config used: http://cvs.tuxbox.org/tuxbox/cdk/config/u-boot.dbox2.h.m4?view=markup I do not know if the code meets U-Boot coding standards, but it works ;) Adding the code to the U-Boot tree makes sense but I think I do not have the needed skills to support it in the future. > Apart from that, I'd strongly start looking for implications of the > recent rewrite of the relocation strategy to code not in mainline. Ah, this is the message I was waiting for. After 2009.08 I did not follow the coding process due to lack of time so I am sure I missed something. Do you mean "[TESTING PATCH] ppc: Relocation test patch" from Sep 12th? Btw, I am using gcc-3.4.6. > Apart from that you could also use the information in our DULG[1] for > debugging of U-Boot after relocation and use gdb I´ll try this as well. Cheers, rhabarber1848 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
> Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > scaning time? > To: leon...@msn.com > CC: u-boot@lists.denx.de > From: joakim.tjernl...@transmode.se > Date: Tue, 3 Nov 2009 10:52:06 +0100 > > HeLei wrote on 03/11/2009 10:39:48: > > > > > > > Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > > scaning time? > > > To: leon...@msn.com > > > CC: u-boot@lists.denx.de > > > From: joakim.tjernl...@transmode.se > > > Date: Tue, 3 Nov 2009 10:29:47 +0100 > > > > > > HeLei wrote on 03/11/2009 10:21:13: > > > > > > > > Ok, thank you, jocke. > > > > Can you tell me how much time can be saved according to your idea, by > > > > your > > experience? > > > > > > Can't remember any figures, but is was lots by not scanning empty space. > > > It all > > > depends on how full your fs is. > >Thanks, I got it! > >I think the problem of JFFS2 is it never store the index of file system > > in > > flash. However 1~2GiB flash is quite popular, how JFFS2 face such > > situation :( > > JFFS2 isn't really suited for such big FS:es and works best on NOR flash. > You should consider some other FS(YAFFS, LogFS, UBIFS etc.). I can't say > which tough as I haven't used any of them. I got it, thanks > > Jocke > _ 上Windows Live 中国首页，下载Messenger2009安全版！ http://www.windowslive.cn___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
> Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > scaning time? > To: leon...@msn.com > CC: u-boot@lists.denx.de > From: joakim.tjernl...@transmode.se > Date: Tue, 3 Nov 2009 10:43:46 +0100 > > HeLei wrote on 03/11/2009 09:21:04: > > > - Don't scan more than you have to, that is, ls/read /some/file > > > should only scan and keep records to do the ls/read of that > > > particular file. > >So we have to have an index, or something like that, to tell which file > > in > > which EBs. This index is always generated by the scan for the first time. > >The only workaround like this idea is to divide the flash into several > > paritions, the scan is performed on certain partition each time. > > Forgot to comment on this one :) > I belive u-boot creates a cache for the whole FS a first access > so that later accesses are fast. I think this is suboptimal. Consider > the common case to boot a linux kernel, you only want to get at the > kernel image so creating a cache for the whole FS is a waste. Yes, I agree! > > Partitions works too, but is a waste of flash and it can be hard to get the > partition size(s) right. Yes, this need another information on partition > size as well as starting address. I think uboot environment can handle this. > > Jocke > _ 约会说不清地方？来试试微软地图最新msn互动功能！ http://ditu.live.com/?form=TL&swm=1___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
HeLei wrote on 03/11/2009 10:39:48: > > > > Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > scaning time? > > To: leon...@msn.com > > CC: u-boot@lists.denx.de > > From: joakim.tjernl...@transmode.se > > Date: Tue, 3 Nov 2009 10:29:47 +0100 > > > > HeLei wrote on 03/11/2009 10:21:13: > > > > > > Ok, thank you, jocke. > > > Can you tell me how much time can be saved according to your idea, by your > experience? > > > > Can't remember any figures, but is was lots by not scanning empty space. It > > all > > depends on how full your fs is. >Thanks, I got it! >I think the problem of JFFS2 is it never store the index of file system in > flash. However 1~2GiB flash is quite popular, how JFFS2 face such situation > :( JFFS2 isn't really suited for such big FS:es and works best on NOR flash. You should consider some other FS(YAFFS, LogFS, UBIFS etc.). I can't say which tough as I haven't used any of them. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
HeLei wrote on 03/11/2009 09:21:04: > > - Don't scan more than you have to, that is, ls/read /some/file > > should only scan and keep records to do the ls/read of that > > particular file. >So we have to have an index, or something like that, to tell which file in > which EBs. This index is always generated by the scan for the first time. >The only workaround like this idea is to divide the flash into several > paritions, the scan is performed on certain partition each time. Forgot to comment on this one :) I belive u-boot creates a cache for the whole FS a first access so that later accesses are fast. I think this is suboptimal. Consider the common case to boot a linux kernel, you only want to get at the kernel image so creating a cache for the whole FS is a waste. Partitions works too, but is a waste of flash and it can be hard to get the partition size(s) right. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
> Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > scaning time? > To: leon...@msn.com > CC: u-boot@lists.denx.de > From: joakim.tjernl...@transmode.se > Date: Tue, 3 Nov 2009 10:29:47 +0100 > > HeLei wrote on 03/11/2009 10:21:13: > > > > Ok, thank you, jocke. > > Can you tell me how much time can be saved according to your idea, by your > > experience? > > Can't remember any figures, but is was lots by not scanning empty space. It > all > depends on how full your fs is. Thanks, I got it! I think the problem of JFFS2 is it never store the index of file system in flash. However 1~2GiB flash is quite popular, how JFFS2 face such situation :( > > Jocke > _ 上Windows Live 中国首页，下载Messenger2009安全版！ http://www.windowslive.cn___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
HeLei wrote on 03/11/2009 10:26:44: > Jocke, you are so kind. > Thank you very much:) NP, it was easy considering I did the first impl. for linux :) It is probably easier to paste the missing bits into the current crc32 impl. though. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2009.11-rc1 is out
Hi rhabarber1848, > I just tested it on my Dbox2 board where U-Boot 2009.08 is working > perfectly well with unchanged config. > But now U-Boot raises an exception during machine check: > > = > U-Boot 2009.11 (Tuxbox) (Nov 03 2009 - 08:59:24) > > CPU: PPC823ZTnnB2 at 66 MHz: 2 kB I-Cache 1 kB D-Cache > Board: DBOX2, Sagem, BMon V1.0 >Watchdog enabled > I2C: ready > DRAM: 64 MB > Top of RAM usable for U-Boot at: 0400 > Reserving 201k for U-Boot at: 03fcd000 > Reserving 144k for malloc() at: 03fa9000 > Reserving 60 Bytes for Board Info at: 03fa8fc4 > Reserving 52 Bytes for Global Data at: 03fa8f90 > Stack Pointer at: 03fa8f78 > New Stack Pointer is: 03fa8f78 > Now running in RAM - U-Boot at: 03fcd000 > FLASH: 8 MB > FB:ready > Bus Fault @ 0x03fcfe0c, fixup 0x > Machine check in kernel mode. > Caused by (from msr): regs 03fa8d88 Unknown values in msr > NIP: 03FCFE0C XER: 807F LR: 03FCFD98 REGS: 03fa8d88 TRAP: 0200 DAR: > 3038B700 > MSR: 1002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 > > GPR00: 30323030 03FA8E78 03FA8F90 0008 30323030 3037 000686CC > GPR08: 03FF56CC 3038B6FC 0002 000F423F FF002848 00031CBC 03FFB600 03F8D000 > GPR16: 20004000 0001 60634001 90640170 > GPR24: 03FA8F90 0040 03FCD000 0006868C 0001 03FFB678 03FCD000 > Call backtrace: > machine check > = > > The remaining boot messages would be: > > In:serial > Out: serial > Err: serial > Net: SCC ETHERNET > LCD: ready > > Any pointers where I could start debugging? Grepping through my source, I cannot find such a configuration - do you plan to submit this support here sometime? Apart from that, I'd strongly start looking for implications of the recent rewrite of the relocation strategy to code not in mainline. Given that the last message is "FB:" (also not in mainline), the corresponding code would be my start for the debugging. Apart from that you could also use the information in our DULG[1] for debugging of U-Boot after relocation and use gdb to find the code corresponding to "0x3fcfe0c". You'll not even need a JTAG debugger for this address lookup as all neccessary informations are in your dump ;) Cheers Detlev [1] http://www.denx.de/wiki/view/DULG/DebuggingUBoot#Section_10.1.2. -- Man is a fool, and woman, for tolerating him, is a damned fool -- Mark Twain -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
HeLei wrote on 03/11/2009 10:21:13: > > Ok, thank you, jocke. > Can you tell me how much time can be saved according to your idea, by your > experience? Can't remember any figures, but is was lots by not scanning empty space. It all depends on how full your fs is. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
Jocke, you are so kind.Thank you very much:) > Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > scaning time? > To: leon...@msn.com > CC: u-boot@lists.denx.de > From: joakim.tjernl...@transmode.se > Date: Tue, 3 Nov 2009 10:20:19 +0100 > > HeLei wrote on 03/11/2009 09:21:04: > > > > Thank you, Jocke > > > > > Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > > scaning time? > > > To: leon...@msn.com > > > CC: u-boot@lists.denx.de > > > From: joakim.tjernl...@transmode.se > > > Date: Tue, 3 Nov 2009 08:41:08 +0100 > > > > > > > > > > > > > > Hi, All > > > > > > > > > > > > > > > > Each time JFFS2 initialized, uboot need to scan the whole flash. This is > > > > fairly time consuming. > > > > > > > > > > > > > > > > So EBS(erase block summary) is used to JFFS2 to reduce mounting time. > > > > And I > > > > believe this can also be used to UBOOT to reduce booting time. > > > > > > > > > > > > > > > > Does UBOOT support this feature? or does any other solution in uboot to > > > > reduce JFFS2 scaning time? > > > > > > Don't think EBS is going to buy you much. The main problem is that the > > > >You mean even EBS is used in UBOOT, it will not give me much help. But it > > seems there is great efficiency in jffs2 mounting, from some artical in > > internet, such as:http://www.embedded-linux.co.uk/tutorial/jffs2-summary > > > > > scanning of JFFS2 in u-boot is inefficient. u-boot could take a > > > hint from the kernel impl. of JFFS2 to reduce scanning. The biggest > > > ones are: > > > - do no scan the whole EB when it is empty. > >If we don't scan the block, how can we tell the EB is empty? > > > > > - impl. a better crc32(use the one from linux) > > Attaching a very crude port of linux crc32. This boots a linux img > for me and handles the environment crc as well. Feel free > to clean it up and submit to u-boot. > > Jocke > > (See attached file: crc32-new.c)(See attached file: crc32defs.h)(See > attached file: crc32table.h) _ 约会说不清地方？来试试微软地图最新msn互动功能！ http://ditu.live.com/?form=TL&swm=1___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
HeLei wrote on 03/11/2009 09:21:04: > > Thank you, Jocke > > > Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > scaning time? > > To: leon...@msn.com > > CC: u-boot@lists.denx.de > > From: joakim.tjernl...@transmode.se > > Date: Tue, 3 Nov 2009 08:41:08 +0100 > > > > > > > > > > Hi, All > > > > > > > > > > > > Each time JFFS2 initialized, uboot need to scan the whole flash. This is > > > fairly time consuming. > > > > > > > > > > > > So EBS(erase block summary) is used to JFFS2 to reduce mounting time. And > > > I > > > believe this can also be used to UBOOT to reduce booting time. > > > > > > > > > > > > Does UBOOT support this feature? or does any other solution in uboot to > > > reduce JFFS2 scaning time? > > > > Don't think EBS is going to buy you much. The main problem is that the > >You mean even EBS is used in UBOOT, it will not give me much help. But it > seems there is great efficiency in jffs2 mounting, from some artical in > internet, such as:http://www.embedded-linux.co.uk/tutorial/jffs2-summary > > > scanning of JFFS2 in u-boot is inefficient. u-boot could take a > > hint from the kernel impl. of JFFS2 to reduce scanning. The biggest > > ones are: > > - do no scan the whole EB when it is empty. >If we don't scan the block, how can we tell the EB is empty? > > > - impl. a better crc32(use the one from linux) Attaching a very crude port of linux crc32. This boots a linux img for me and handles the environment crc as well. Feel free to clean it up and submit to u-boot. Jocke (See attached file: crc32-new.c)(See attached file: crc32defs.h)(See attached file: crc32table.h) crc32-new.c Description: Binary data crc32defs.h Description: Binary data crc32table.h Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
Ok, thank you, jocke. Can you tell me how much time can be saved according to your idea, by your experience? > Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > scaning time? > To: leon...@msn.com > CC: u-boot@lists.denx.de > From: joakim.tjernl...@transmode.se > Date: Tue, 3 Nov 2009 10:08:06 +0100 > > HeLei wrote on 03/11/2009 09:21:04: > > Thank you, Jocke > > > > > Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > > scaning time? > > > To: leon...@msn.com > > > CC: u-boot@lists.denx.de > > > From: joakim.tjernl...@transmode.se > > > Date: Tue, 3 Nov 2009 08:41:08 +0100 > > > > > > > > > > > > > > Hi, All > > > > > > > > > > > > > > > > Each time JFFS2 initialized, uboot need to scan the whole flash. This is > > > > fairly time consuming. > > > > > > > > > > > > > > > > So EBS(erase block summary) is used to JFFS2 to reduce mounting time. > > > > And I > > > > believe this can also be used to UBOOT to reduce booting time. > > > > > > > > > > > > > > > > Does UBOOT support this feature? or does any other solution in uboot to > > > > reduce JFFS2 scaning time? > > > > > > Don't think EBS is going to buy you much. The main problem is that the > > > > You mean even EBS is used in UBOOT, it will not give me much help. But it > > seems there is great efficiency in jffs2 mounting, from some artical in > > internet, such as:http://www.embedded-linux.co.uk/tutorial/jffs2-summary > > I tried summary long time ago and it wasn't such a big win. It has other > drawbacks too such as not beeing able to mark nodes on NOR flash obsolete. > > > > > > scanning of JFFS2 in u-boot is inefficient. u-boot could take a > > > hint from the kernel impl. of JFFS2 to reduce scanning. The biggest > > > ones are: > > > - do no scan the whole EB when it is empty. > > If we don't scan the block, how can we tell the EB is empty? > > This was the key for me. I added an optimization that had been forgotten: > just scan the first 512-1024 bytes, if these are empty, assume that > the rest of the EB is too. You can find this optimization in the kernel > also. > > Once this optimization was in place, summary didn't help me. > > > > > - impl. a better crc32(use the one from linux) > > > - Don't scan more than you have to, that is, ls/read /some/file > > > should only scan and keep records to do the ls/read of that > > > particular file. > > So we have to have an index, or something like that, to tell which file in > > which EBs. This index is always generated by the scan for the first time. > > The only workaround like this idea is to divide the flash into several > > paritions, the scan is performed on certain partition each time. > > > > > > > > There were some patches floating around quite some time ago to improve > > > scanning but I don't think they made it into the u-boot repo. > > > > > > > > > > As far as I know, YAFFS2 also has this problem however the code is ported > > from linux. It's also inefficient for YAFFS2 scanning? > > No idea, I am not using YAFFS2 > _ MSN十年回馈，每位用户可免费获得价值25元的卡巴斯基反病毒软件2010激活码，快来领取！ http://kaba.msn.com.cn/?k=1___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH ARM] Clean-up of s3c24x0 header files
Cleans up the s3c24x0 header files:
s4c24x0.h: removes the use of 'volatile' from the S3C24X0_REG8,
S3C24X0_REG16 and S3C24X0_REG32 register typedef's. Registers are always
accessed using the IO accessor functions which cast the register address
as 'volatile' anyway so it isn't required here.
s3c2400.h and s3c2410.h: insert a blank line between the static inline
functions.
Signed-off-by: Kevin Morfitt
---
include/asm-arm/arch-s3c24x0/s3c2400.h | 16
include/asm-arm/arch-s3c24x0/s3c2410.h | 17 +
include/asm-arm/arch-s3c24x0/s3c24x0.h |6 +++---
3 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/include/asm-arm/arch-s3c24x0/s3c2400.h
b/include/asm-arm/arch-s3c24x0/s3c2400.h
index 26bd4e4..2678be1 100644
--- a/include/asm-arm/arch-s3c24x0/s3c2400.h
+++ b/include/asm-arm/arch-s3c24x0/s3c2400.h
@@ -67,67 +67,83 @@ static inline struct s3c24x0_memctl
*s3c24x0_get_base_memctl(void)
{
return (struct s3c24x0_memctl *)S3C24X0_MEMCTL_BASE;
}
+
static inline struct s3c24x0_usb_host *s3c24x0_get_base_usb_host(void)
{
return (struct s3c24x0_usb_host *)S3C24X0_USB_HOST_BASE;
}
+
static inline struct s3c24x0_interrupt *s3c24x0_get_base_interrupt(void)
{
return (struct s3c24x0_interrupt *)S3C24X0_INTERRUPT_BASE;
}
+
static inline struct s3c24x0_dmas *s3c24x0_get_base_dmas(void)
{
return (struct s3c24x0_dmas *)S3C24X0_DMA_BASE;
}
+
static inline struct s3c24x0_clock_power *s3c24x0_get_base_clock_power(void)
{
return (struct s3c24x0_clock_power *)S3C24X0_CLOCK_POWER_BASE;
}
+
static inline struct s3c24x0_lcd *s3c24x0_get_base_lcd(void)
{
return (struct s3c24x0_lcd *)S3C24X0_LCD_BASE;
}
+
static inline struct s3c24x0_uart
*s3c24x0_get_base_uart(enum s3c24x0_uarts_nr n)
{
return (struct s3c24x0_uart *)(S3C24X0_UART_BASE + (n * 0x4000));
}
+
static inline struct s3c24x0_timers *s3c24x0_get_base_timers(void)
{
return (struct s3c24x0_timers *)S3C24X0_TIMER_BASE;
}
+
static inline struct s3c24x0_usb_device *s3c24x0_get_base_usb_device(void)
{
return (struct s3c24x0_usb_device *)S3C24X0_USB_DEVICE_BASE;
}
+
static inline struct s3c24x0_watchdog *s3c24x0_get_base_watchdog(void)
{
return (struct s3c24x0_watchdog *)S3C24X0_WATCHDOG_BASE;
}
+
static inline struct s3c24x0_i2c *s3c24x0_get_base_i2c(void)
{
return (struct s3c24x0_i2c *)S3C24X0_I2C_BASE;
}
+
static inline struct s3c24x0_i2s *s3c24x0_get_base_i2s(void)
{
return (struct s3c24x0_i2s *)S3C24X0_I2S_BASE;
}
+
static inline struct s3c24x0_gpio *s3c24x0_get_base_gpio(void)
{
return (struct s3c24x0_gpio *)S3C24X0_GPIO_BASE;
}
+
static inline struct s3c24x0_rtc *s3c24x0_get_base_rtc(void)
{
return (struct s3c24x0_rtc *)S3C24X0_RTC_BASE;
}
+
static inline struct s3c2400_adc *s3c2400_get_base_adc(void)
{
return (struct s3c2400_adc *)S3C24X0_ADC_BASE;
}
+
static inline struct s3c24x0_spi *s3c24x0_get_base_spi(void)
{
return (struct s3c24x0_spi *)S3C24X0_SPI_BASE;
}
+
static inline struct s3c2400_mmc *s3c2400_get_base_mmc(void)
{
return (struct s3c2400_mmc *)S3C2400_MMC_BASE;
diff --git a/include/asm-arm/arch-s3c24x0/s3c2410.h
b/include/asm-arm/arch-s3c24x0/s3c2410.h
index be2e76e..0543fe1 100644
--- a/include/asm-arm/arch-s3c24x0/s3c2410.h
+++ b/include/asm-arm/arch-s3c24x0/s3c2410.h
@@ -73,71 +73,88 @@ static inline struct s3c24x0_memctl
*s3c24x0_get_base_memctl(void)
{
return (struct s3c24x0_memctl *)S3C24X0_MEMCTL_BASE;
}
+
static inline struct s3c24x0_usb_host *s3c24x0_get_base_usb_host(void)
{
return (struct s3c24x0_usb_host *)S3C24X0_USB_HOST_BASE;
}
+
static inline struct s3c24x0_interrupt *s3c24x0_get_base_interrupt(void)
{
return (struct s3c24x0_interrupt *)S3C24X0_INTERRUPT_BASE;
}
+
static inline struct s3c24x0_dmas *s3c24x0_get_base_dmas(void)
{
return (struct s3c24x0_dmas *)S3C24X0_DMA_BASE;
}
+
static inline struct s3c24x0_clock_power *s3c24x0_get_base_clock_power(void)
{
return (struct s3c24x0_clock_power *)S3C24X0_CLOCK_POWER_BASE;
}
+
static inline struct s3c24x0_lcd *s3c24x0_get_base_lcd(void)
{
return (struct s3c24x0_lcd *)S3C24X0_LCD_BASE;
}
+
static inline struct s3c2410_nand *s3c2410_get_base_nand(void)
{
return (struct s3c2410_nand *)S3C2410_NAND_BASE;
}
+
static inline struct s3c24x0_uart
*s3c24x0_get_base_uart(enum s3c24x0_uarts_nr n)
{
return (struct s3c24x0_uart *)(S3C24X0_UART_BASE + (n * 0x4000));
}
+
static inline struct s3c24x0_timers *s3c24x0_get_base_timers(void)
{
return (struct s3c24x0_timers *)S3C24X0_TIMER_BASE;
}
+
static inline struct s3c24x0_usb_device *s3c24x0_get_base_usb_device(void)
{
return (struct s3c24x0_usb_device *)S3C24X0_USB_DEVICE_BASE;
}
+
static inline struct s3c24x0_watchdog *s3c24x0_get_base_watchdog(void)
{
return (struct s3c24x0_watchdog *)S3C24X0_WA
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
HeLei wrote on 03/11/2009 09:21:04: > Thank you, Jocke > > > Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > scaning time? > > To: leon...@msn.com > > CC: u-boot@lists.denx.de > > From: joakim.tjernl...@transmode.se > > Date: Tue, 3 Nov 2009 08:41:08 +0100 > > > > > > > > > > Hi, All > > > > > > > > > > > > Each time JFFS2 initialized, uboot need to scan the whole flash. This is > > > fairly time consuming. > > > > > > > > > > > > So EBS(erase block summary) is used to JFFS2 to reduce mounting time. And > > > I > > > believe this can also be used to UBOOT to reduce booting time. > > > > > > > > > > > > Does UBOOT support this feature? or does any other solution in uboot to > > > reduce JFFS2 scaning time? > > > > Don't think EBS is going to buy you much. The main problem is that the > >You mean even EBS is used in UBOOT, it will not give me much help. But it > seems there is great efficiency in jffs2 mounting, from some artical in > internet, such as:http://www.embedded-linux.co.uk/tutorial/jffs2-summary I tried summary long time ago and it wasn't such a big win. It has other drawbacks too such as not beeing able to mark nodes on NOR flash obsolete. > > > scanning of JFFS2 in u-boot is inefficient. u-boot could take a > > hint from the kernel impl. of JFFS2 to reduce scanning. The biggest > > ones are: > > - do no scan the whole EB when it is empty. >If we don't scan the block, how can we tell the EB is empty? This was the key for me. I added an optimization that had been forgotten: just scan the first 512-1024 bytes, if these are empty, assume that the rest of the EB is too. You can find this optimization in the kernel also. Once this optimization was in place, summary didn't help me. > > > - impl. a better crc32(use the one from linux) > > - Don't scan more than you have to, that is, ls/read /some/file > > should only scan and keep records to do the ls/read of that > > particular file. >So we have to have an index, or something like that, to tell which file in > which EBs. This index is always generated by the scan for the first time. >The only workaround like this idea is to divide the flash into several > paritions, the scan is performed on certain partition each time. > > > > > There were some patches floating around quite some time ago to improve > > scanning but I don't think they made it into the u-boot repo. > > > > > >As far as I know, YAFFS2 also has this problem however the code is ported > from linux. It's also inefficient for YAFFS2 scanning? No idea, I am not using YAFFS2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91: Enable slow master clock on meesc board
In some cases, we need low speed master clock. So depending on the
"mdiv" variable, the processor clock is divided by 2 (default) or 4.
Signed-off-by: Daniel Gorsulowski
---
PS: Tom, are you still temporary at91 custodian?
board/esd/meesc/meesc.c | 24
include/configs/meesc.h |1 +
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/board/esd/meesc/meesc.c b/board/esd/meesc/meesc.c
index efba60d..4f6c5b7 100644
--- a/board/esd/meesc/meesc.c
+++ b/board/esd/meesc/meesc.c
@@ -219,6 +219,30 @@ u32 get_board_rev(void)
}
#endif
+#ifdef CONFIG_MISC_INIT_R
+int misc_init_r(void)
+{
+ char *str;
+ char buf[32];
+
+ /*
+* In some cases, we need low speed master clock. So depending on the
+* "mdiv" variable, the processor clock is divided by 2 (default) or 4.
+*/
+ if ((str = getenv("mdiv")) && (!strcmp(str, "4"))) {
+ at91_sys_write(AT91_PMC_MCKR,
+ (at91_sys_read(AT91_PMC_MCKR) & ~AT91_PMC_MDIV) |
+ AT91SAM9_PMC_MDIV_4);
+ at91_clock_init(0);
+ serial_setbrg();
+ printf("Setting master clock to %s MHz\n",
+ strmhz(buf, get_mck_clk_rate()));
+ }
+
+ return 0;
+}
+#endif /* CONFIG_MISC_INIT_R */
+
int board_init(void)
{
/* Peripheral Clock Enable Register */
diff --git a/include/configs/meesc.h b/include/configs/meesc.h
index b996854..034e81c 100644
--- a/include/configs/meesc.h
+++ b/include/configs/meesc.h
@@ -48,6 +48,7 @@
#define CONFIG_SKIP_LOWLEVEL_INIT
#define CONFIG_SKIP_RELOCATE_UBOOT
+#define CONFIG_MISC_INIT_R /* Call misc_init_r */
#define CONFIG_ARCH_CPU_INIT
--
1.5.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
Thank you, Jocke > Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 > scaning time? > To: leon...@msn.com > CC: u-boot@lists.denx.de > From: joakim.tjernl...@transmode.se > Date: Tue, 3 Nov 2009 08:41:08 +0100 > > > > > > Hi, All > > > > > > > > Each time JFFS2 initialized, uboot need to scan the whole flash. This is > > fairly time consuming. > > > > > > > > So EBS(erase block summary) is used to JFFS2 to reduce mounting time. And I > > believe this can also be used to UBOOT to reduce booting time. > > > > > > > > Does UBOOT support this feature? or does any other solution in uboot to > > reduce JFFS2 scaning time? > > Don't think EBS is going to buy you much. The main problem is that the You mean even EBS is used in UBOOT, it will not give me much help. But it seems there is great efficiency in jffs2 mounting, from some artical in internet, such as:http://www.embedded-linux.co.uk/tutorial/jffs2-summary > scanning of JFFS2 in u-boot is inefficient. u-boot could take a > hint from the kernel impl. of JFFS2 to reduce scanning. The biggest > ones are: > - do no scan the whole EB when it is empty. If we don't scan the block, how can we tell the EB is empty? > - impl. a better crc32(use the one from linux) > - Don't scan more than you have to, that is, ls/read /some/file > should only scan and keep records to do the ls/read of that > particular file. So we have to have an index, or something like that, to tell which file in which EBs. This index is always generated by the scan for the first time. The only workaround like this idea is to divide the flash into several paritions, the scan is performed on certain partition each time. > > There were some patches floating around quite some time ago to improve > scanning but I don't think they made it into the u-boot repo. > > As far as I know, YAFFS2 also has this problem however the code is ported from linux. It's also inefficient for YAFFS2 scanning? > Jocke > _ 上Windows Live 中国首页，下载Messenger2009安全版！ http://www.windowslive.cn___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2009.11-rc1 is out
Am Wed, 28 Oct 2009 14:42:10 +0100 schrieb Wolfgang Denk: > just in case you did not notice yet: U-Boot v2009.11-rc1 was released > last night. Hi, I just tested it on my Dbox2 board where U-Boot 2009.08 is working perfectly well with unchanged config. But now U-Boot raises an exception during machine check: = U-Boot 2009.11 (Tuxbox) (Nov 03 2009 - 08:59:24) CPU: PPC823ZTnnB2 at 66 MHz: 2 kB I-Cache 1 kB D-Cache Board: DBOX2, Sagem, BMon V1.0 Watchdog enabled I2C: ready DRAM: 64 MB Top of RAM usable for U-Boot at: 0400 Reserving 201k for U-Boot at: 03fcd000 Reserving 144k for malloc() at: 03fa9000 Reserving 60 Bytes for Board Info at: 03fa8fc4 Reserving 52 Bytes for Global Data at: 03fa8f90 Stack Pointer at: 03fa8f78 New Stack Pointer is: 03fa8f78 Now running in RAM - U-Boot at: 03fcd000 FLASH: 8 MB FB:ready Bus Fault @ 0x03fcfe0c, fixup 0x Machine check in kernel mode. Caused by (from msr): regs 03fa8d88 Unknown values in msr NIP: 03FCFE0C XER: 807F LR: 03FCFD98 REGS: 03fa8d88 TRAP: 0200 DAR: 3038B700 MSR: 1002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 GPR00: 30323030 03FA8E78 03FA8F90 0008 30323030 3037 000686CC GPR08: 03FF56CC 3038B6FC 0002 000F423F FF002848 00031CBC 03FFB600 03F8D000 GPR16: 20004000 0001 60634001 90640170 GPR24: 03FA8F90 0040 03FCD000 0006868C 0001 03FFB678 03FCD000 Call backtrace: machine check = The remaining boot messages would be: In:serial Out: serial Err: serial Net: SCC ETHERNET LCD: ready Any pointers where I could start debugging? Cheers, rhabarber1848 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
