Re: [U-Boot] [PATCH ARM 2/3 v2] s3c24x0 code style changes
Dear Kevin Morfitt,
On 11 February 2010 00:20, Kevin Morfitt
wrote:
> Changes the s3c24x0 files to meet the code style requirements.
>
> Signed-off-by: Kevin Morfitt
> ---
>
> v2 changes:
> - re-number to be 2/3
>
> checkpatch.pl reports no errors.
>
> board/MAI/AmigaOneG3SE/video.c | 1 -
> board/mpl/common/common_util.h | 1 +
> board/mpl/common/flash.c | 1 -
> board/mpl/vcma9/cmd_vcma9.c | 9 -
> board/mpl/vcma9/vcma9.c | 27 ++--
> board/mpl/vcma9/vcma9.h | 6 +-
> board/samsung/smdk2400/smdk2400.c | 12 +-
> board/sbc2410x/sbc2410x.c | 6 +-
> board/trab/auto_update.c | 30 +---
> board/trab/cmd_trab.c | 213 +++-
> board/trab/rs485.c | 16 +-
> board/trab/trab.c | 43 ++---
> board/trab/trab.h | 38 +
> board/trab/trab_fkt.c | 331
> -
> board/trab/tsc2000.c | 12 +-
> board/trab/tsc2000.h | 1 +
> board/trab/vfd.c | 70
> common/cmd_version.c | 2 -
> common/cmd_vfd.c | 2 -
> common/main.c | 5 +-
> drivers/i2c/s3c24x0_i2c.c | 71 -
> drivers/video/cfb_console.c | 1 -
> include/common.h | 14 ++
> lib_generic/display_options.c | 2 -
> 24 files changed, 418 insertions(+), 496 deletions(-)
> create mode 100644 board/trab/trab.h
>
> diff --git a/board/MAI/AmigaOneG3SE/video.c b/board/MAI/AmigaOneG3SE/video.c
> index e24e28b..e8d1f64 100644
> --- a/board/MAI/AmigaOneG3SE/video.c
> +++ b/board/MAI/AmigaOneG3SE/video.c
> @@ -478,7 +478,6 @@ void video_easteregg(void)
> #endif
>
> extern block_dev_desc_t * ide_get_dev(int dev);
> -extern char version_string[];
>
> void video_banner(void)
> {
> diff --git a/board/mpl/common/common_util.h b/board/mpl/common/common_util.h
> index 29cd14f..9978ce4 100644
> --- a/board/mpl/common/common_util.h
> +++ b/board/mpl/common/common_util.h
> @@ -42,4 +42,5 @@ void check_env(void);
> void doc_init (void);
> #endif
>
> +int do_mplcommon(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
> #endif /* _COMMON_UTIL_H_ */
> diff --git a/board/mpl/common/flash.c b/board/mpl/common/flash.c
> index 682f0e7..2e40610 100644
> --- a/board/mpl/common/flash.c
> +++ b/board/mpl/common/flash.c
> @@ -159,7 +159,6 @@ unsigned long flash_init (void)
> #if !defined(CONFIG_PATI)
> unsigned long size_b1,flashcr,size_reg;
> int mode;
> - extern char version_string;
> char *p = &version_string;
>
> /* Since we are relocated, we can set-up the CS finally */
> diff --git a/board/mpl/vcma9/cmd_vcma9.c b/board/mpl/vcma9/cmd_vcma9.c
> index 49558d8..10dcd8e 100644
> --- a/board/mpl/vcma9/cmd_vcma9.c
> +++ b/board/mpl/vcma9/cmd_vcma9.c
> @@ -43,15 +43,6 @@ static uchar cs8900_chksum(ushort data)
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -extern void print_vcma9_info(void);
> -extern int vcma9_cantest(int);
> -extern int vcma9_nandtest(void);
> -extern int vcma9_nanderase(void);
> -extern int vcma9_nandread(ulong);
> -extern int vcma9_nandwrite(ulong);
> -extern int vcma9_dactest(int);
> -extern int do_mplcommon(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
> -
> /* -
> */
>
removing extern functions and values are ok.
but I wonder if it occur compile warnings.
Did you test it?
> int do_vcma9(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
> diff --git a/board/mpl/vcma9/vcma9.c b/board/mpl/vcma9/vcma9.c
> index 9a7c0fa..5401664 100644
> --- a/board/mpl/vcma9/vcma9.c
> +++ b/board/mpl/vcma9/vcma9.c
> @@ -137,22 +137,19 @@ int board_init(void)
> * NAND flash initialization.
> */
> #if defined(CONFIG_CMD_NAND)
> -extern ulong
> -nand_probe(ulong physadr);
> -
> -
> static inline void NF_Reset(void)
> {
> int i;
>
> NF_SetCE(NFCE_LOW);
> - NF_Cmd(0xFF); /* reset command */
> - for (i = 0; i < 10; i++); /* tWB = 100ns. */
> - NF_WaitRB(); /* wait 200~500us; */
> + NF_Cmd(0xFF); /* reset command */
> + /* tWB = 100ns. */
> + for (i = 0; i < 10; i++)
> + /* delay */;
> + NF_WaitRB(); /* wait 200~500us; */
> NF_SetCE(NFCE_HIGH);
> }
>
> -
> static inline void NF_Init(void)
> {
> #define TACLS 0
> @@ -187,36 +184,36 @@ static u8 Get_PLD_ID(void)
> {
> VCMA9_PLD * const pld = VCMA9_get_base_PLD();
>
> - return (pld->ID);
> + return pld->ID;
> }
>
> static u8 Get_PLD_BOARD(void)
> {
> VCMA9_PLD * const pld = VCMA9_get_base_PLD();
>
> - return (pld->BOARD);
> + return pld->BOARD;
> }
>
> static u8 Get_PLD_SDRAM(void)
> {
> VCMA9_PLD * const pld = VCMA9_get_base_PLD();
>
> - return (pld->SDRA
Re: [U-Boot] [PATCH V2 1/3] S5PC100: Memory SubSystem Header file, register description(SROMC).
Dear Naveen Krishna Ch,
On 10 February 2010 21:42, Naveen Krishna Ch wrote:
> From: Naveen Krishna CH
>
> Memory subsystem of S5PC100 handles SROM, SRAM, OneDRAM, OneNand,
> NAND Flash, DDRs.
> mem.h is a common place for the register description of Memory subsystem
> of S5PC100.
> Note: Only SROM related registers are descibed now.
>
> Signed-off-by: Naveen Krishna Ch
> ---
> Changes since V1:
>
> 1. The header file is renamed to smc.h from mem.h
> 2. The Macros are renamed according to TRM.
> Comments from Minkyu kang are fixed.
>
> Note: Some of the defined macros are not used now. They are added to
> facilitiate
> simple cofiguration of SMC registers.
>
> include/asm-arm/arch-s5pc1xx/smc.h | 54
>
> 1 files changed, 54 insertions(+), 0 deletions(-)
> create mode 100644 include/asm-arm/arch-s5pc1xx/smc.h
>
> diff --git a/include/asm-arm/arch-s5pc1xx/smc.h
> b/include/asm-arm/arch-s5pc1xx/smc.h
> new file mode 100644
> index 000..2a1ee07
> --- /dev/null
> +++ b/include/asm-arm/arch-s5pc1xx/smc.h
> @@ -0,0 +1,54 @@
> +/*
> + * (C) Copyright 2010 Samsung Electronics
> + * Naveen Krishna Ch
> + *
> + * 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
> + *
> + * Note: This file contains the register description for Memory subsystem
> + * (SROM, NAND Flash, OneNand, DDR, OneDRAM) on S5PC1XX.
> + *
> + * Only SROMC is defined as of now
> + */
> +
> +#ifndef __ASM_ARCH_SMC_H_
> +#define __ASM_ARCH_SMC_H_
> +
> +#define SMC_DATA16_WIDTH(x) (1<<((x*4)+0))
> +#define SMC_BYTE_ADDR_MODE(x) (1<<((x*4)+1)) /* 0-> Half-word base
> address*/
> + /* 1-> Byte base address*/
> +#define SMC_WAIT_ENABLE(x) (1<<((x*4)+2))
> +#define SMC_BYTE_ENABLE(x) (1<<((x*4)+3))
> +
> +#define SMC_BC_TACS 0x0 /* 0clk address set-up */
> +#define SMC_BC_TCOS 0x4 /* 4clk chip selection set-up */
> +#define SMC_BC_TACC 0xe /* 14clk access cycle */
> +#define SMC_BC_TCOH 0x1 /* 1clk chip selection hold */
> +#define SMC_BC_TAH 0x4 /* 4clk address holding time */
> +#define SMC_BC_TACP 0x6 /* 6clk page mode access cycle */
> +#define SMC_BC_PMC 0x0 /* normal(1data)page mode configuration */
> +
> +#define SMC_BC_CON ((SMC_BC_TACS<<28)|(SMC_BC_TCOS<<24)| \
> + (SMC_BC_TACC<<16)|(SMC_BC_TCOH<<12)| \
> + (SMC_BC_TAH<<8)|(SMC_BC_TACP<<4)|(SMC_BC_PMC))
> +
> +#ifndef __ASSEMBLY__
> +struct s5pc1xx_smc {
> + unsigned int bw;
> + unsigned int bc[6];
> +};
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* __ASM_ARCH_SMC_H_ */
> --
> 1.6.6
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
Did you see my comments?
http://lists.denx.de/pipermail/u-boot/2010-February/067647.html
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] POST related question
On Wed, Feb 10, 2010 at 5:54 PM, Detlev Zundel wrote: > Hi Michael, > >> Working on the POST for our board (which I am going to submit >> to the u-boot in the near future) I was asked to output the POST tests >> sequence progress to the dedicated LEDs (current test’s index and >> test’s result – PASS or FAIL) in addition to the conventional console >> output. Such indication can be helpful at the customer premises when >> console is not available as well as at the production testing/diagnostics >> to understand which POST test has failed while serial console does not >> show signs of life. >> In order to fulfill this requirement I see two possibilities: >> >> 1) Common infrastructure change - add pre-test and after test callbacks >> to the post_test structure in the tests.c file. Call these callbacks >> before and after each POST test in the post_run_single routine of post.c >> file. >> >> 2) Local, board specific change – duplicate all necessary POST tests into >> specific board folder and add output to LEDs interface into every >> _post_test routine. >> >> Please advise. > > Thinking about it, why can't we 3) introduce show_post_progress(). It > seems to me that the show_boot_progress (grep the README) implements > exactly the same idea for the boot process, so it would make sense to > re-use the implementation idea. Nowadays we could solve the overrideing > with weak functions. > > What do you think? > > Cheers > Detlev > > -- > It's very important that you sleep because that's when your brain is > garbage collecting. And a dream is if you are interrupted in the > middle and have junk left in the registers. > -- Gerald Sussman > -- > 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 > Actually the option #3 is very similar to the #1 option about which I thought also before my first post… However, option #1 has few advantages as: a) Flexibility - it is not restricted to the progress status only; rather it can be customized for additional functionality such as printing of extended user notification before and after specific test or doing something else… b) In the case of slow POST tests it will be especially helpful to know which test is currently executing, immediately at the beginning of the test (form within pre-test phase) while the test’s results will come long time after this moment and can be indicated via after-test phase. Again, we need such indication only when POST output for some reason is not available via serial console. Of course, these pre/after callbacks can be added explicitly at the beginning/end of every post test (what is actually the option #3) but making them to be a part of the post_test structure keeps code smaller and more readable. I agree that the show_boot_progress is good approach in general but in the POST system where we have the callback infrastructure already in place why do not use its advantages? Thanks, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] S5PC100: Memory SubSystem Header file, register description(SROMC).
HI Kang,
On 10 February 2010 16:04, Minkyu Kang wrote:
> Dear Naveen Krishna Ch,
>
> On 10 February 2010 15:16, Naveen Krishna Ch
> wrote:
> > Hi Kang,
> >
> > On 10 February 2010 11:18, Minkyu Kang wrote:
> >>
> >> Dear Naveen Krishna Ch,
> >>
> >> On 9 February 2010 18:34, Naveen Krishna Ch
> wrote:
> >> > From: Naveen Krishna CH
> >> >
> >> > Memory subsystem of S5PC100 handles SROM, SRAM, OneDRAM, OneNand,
> >> > NAND Flash, DDRs.
> >> > mem.h is a common place for the register description of Memory
> subsystem
> >> > of S5PC100.
> >> > Note: Only SROM related registers are descibed now.
> >> >
> >> > Signed-off-by: Naveen Krishna Ch samsung.com>
> >> > ---
> >> > include/asm-arm/arch-s5pc1xx/mem.h | 55
> >> >
> >> > 1 files changed, 55 insertions(+), 0 deletions(-)
> >> > create mode 100644 include/asm-arm/arch-s5pc1xx/mem.h
> >> >
> >> > diff --git a/include/asm-arm/arch-s5pc1xx/mem.h
> >> > b/include/asm-arm/arch-s5pc1xx/mem.h
> >> > new file mode 100644
> >> > index 000..66272ff
> >> > --- /dev/null
> >> > +++ b/include/asm-arm/arch-s5pc1xx/mem.h
> >>
> >> I think srom.h is better than mem.h.
> >
> > As the SMC of S5PC100 is supporting several memories SRAM, SROM, NAND,
> NOR,
> > DDR. I kept it as mem.h
>
> So what?
> This patch add about sromc. (not another memories)
> If need, separate each controller.
>
I have renamed it according to the TRM (smc.h) as it is SMC subsystem.
>
> >>
> >> > @@ -0,0 +1,55 @@
> >> > +/*
> >> > + * (C) Copyright 2010 Samsung Electronics
> >> > + * Naveen Krishna Ch
> >> > + *
> >> > + * 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
> >> > + *
> >> > + * Note: This file contains the register description for Memory
> >> > subsystem
> >> > + * (SROM, NAND Flash, OneNand, DDR, OneDRAM) on S5PC1XX.
> >> > + *
> >> > + * Only SROMC is defined as of now
> >> > + */
> >> > +
> >> > +#ifndef __ASM_ARCH_MEM_H_
> >> > +#define __ASM_ARCH_MEM_H_
> >> > +
> >> > +#define SROM_DATA16_WIDTH(x)(1<<((x*4)+0))
> >> > +#define SROM_BYTE_ADDR_MODE(x) (1<<((x*4)+1)) /* 0-> Half-word base
> >> > address*/
> >> > + /* 1-> Byte base
> >> > address*/
> >> > +#define SROM_WAIT_ENABLE(x) (1<<((x*4)+2))
> >> > +#define SROM_BYTE_ENABLE(x) (1<<((x*4)+3))
> >>
> >> Do you use all of these defines?
> >
> > For Net support i use only SROM_DATA16_WIDTH
> > But for NAND support we may need SROM_BYTE_ADDR_MODE
> > These Macros can serve for generic pupose.
> >>
> >> > +
> >> > +#define SMCBC_X_Tacs(0x0) /* 0clk address set-up */
> >> > +#define SMCBC_X_Tcos(0x4) /* 4clk chip selection set-up
> >> > */
> >> > +#define SMCBC_X_Tacc(0xe) /* 14clkaccess cycle */
> >> > +#define SMCBC_X_Tcoh(0x1) /* 1clk chip selection hold
> */
> >> > +#define SMCBC_X_Tah (0x4) /* 4clk address holding time
> */
> >> > +#define SMCBC_X_Tacp(0x6) /* 6clk page mode access
> cycle
> >> > */
> >> > +#define SMCBC_X_PMC (0x0) /* normal(1data)page mode
> configuration
> >> > */
> >>
> >> Please don't use lowercase at define
> >
> > I will change it.
> >>
> >> and () is unnecessary.
> >
> > Should remove it
> >>
> >> and.. what mean X is?
> >
> > The SROM has 6 banks, I used "X" to indicate that
>
> then, it must be different each banks.
> but your code set same value at all banks (Almost hard code)
> Please modify to can set values each banks.
>
For all the SROM bank configuration registers the values remains same.
As all the banks uses HCLK D0 as the base clock.
So, Same value is applicable to all SROM Banks.
>
> And one more question, what mean SMCBC is?
>
Sorry i changed it in V2 patch.
>
> >>
> >> > +
> >> > +#define SMC_BC_X_CON((SMCBC_X_Tacs<<28)|(SMCBC_X_Tcos<<24)| \
> >> > +(SMCBC_X_Tacc<<16)|(SMCBC_X_Tcoh<<12)| \
> >> > +(SMCBC_X_Tah<<8)|(SMCBC_X_Tacp<<4)|\
> >> > +(SMCBC_X_PMC))
> >> > +
> >> > +#ifndef __ASSEMBLY__
> >> > +struct s5pc1xx_sromc {
> >> > + unsigned intsmc_bw;
> >> > + unsigned intsmc_bc[6];
> >> > +};
> >> > +#endif /* __ASSEMBLY__ */
>
Re: [U-Boot] [PATCH V2 1/3] S5PC100: Memory SubSystem Header file, register description(SROMC).
Hi kang,
On 11 February 2010 14:12, Minkyu Kang wrote:
> Dear Naveen Krishna Ch,
>
> On 10 February 2010 21:42, Naveen Krishna Ch
> wrote:
> > From: Naveen Krishna CH
> >
> > Memory subsystem of S5PC100 handles SROM, SRAM, OneDRAM, OneNand,
> > NAND Flash, DDRs.
> > mem.h is a common place for the register description of Memory subsystem
> > of S5PC100.
> > Note: Only SROM related registers are descibed now.
> >
> > Signed-off-by: Naveen Krishna Ch
> > ---
> > Changes since V1:
> >
> > 1. The header file is renamed to smc.h from mem.h
> > 2. The Macros are renamed according to TRM.
> > Comments from Minkyu kang are fixed.
> >
> > Note: Some of the defined macros are not used now. They are added to
> facilitiate
> > simple cofiguration of SMC registers.
> >
> > include/asm-arm/arch-s5pc1xx/smc.h | 54
>
> > 1 files changed, 54 insertions(+), 0 deletions(-)
> > create mode 100644 include/asm-arm/arch-s5pc1xx/smc.h
> >
> > diff --git a/include/asm-arm/arch-s5pc1xx/smc.h
> b/include/asm-arm/arch-s5pc1xx/smc.h
> > new file mode 100644
> > index 000..2a1ee07
> > --- /dev/null
> > +++ b/include/asm-arm/arch-s5pc1xx/smc.h
> > @@ -0,0 +1,54 @@
> > +/*
> > + * (C) Copyright 2010 Samsung Electronics
> > + * Naveen Krishna Ch
> > + *
> > + * 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
> > + *
> > + * Note: This file contains the register description for Memory
> subsystem
> > + * (SROM, NAND Flash, OneNand, DDR, OneDRAM) on S5PC1XX.
> > + *
> > + * Only SROMC is defined as of now
> > + */
> > +
> > +#ifndef __ASM_ARCH_SMC_H_
> > +#define __ASM_ARCH_SMC_H_
> > +
> > +#define SMC_DATA16_WIDTH(x)(1<<((x*4)+0))
> > +#define SMC_BYTE_ADDR_MODE(x) (1<<((x*4)+1)) /* 0-> Half-word base
> address*/
> > + /* 1-> Byte base
> address*/
> > +#define SMC_WAIT_ENABLE(x) (1<<((x*4)+2))
> > +#define SMC_BYTE_ENABLE(x) (1<<((x*4)+3))
> > +
> > +#define SMC_BC_TACS0x0 /* 0clk address set-up */
> > +#define SMC_BC_TCOS0x4 /* 4clk chip selection set-up */
> > +#define SMC_BC_TACC0xe /* 14clkaccess cycle */
> > +#define SMC_BC_TCOH0x1 /* 1clk chip selection hold */
> > +#define SMC_BC_TAH 0x4 /* 4clk address holding time */
> > +#define SMC_BC_TACP0x6 /* 6clk page mode access cycle */
> > +#define SMC_BC_PMC 0x0 /* normal(1data)page mode configuration */
> > +
> > +#define SMC_BC_CON((SMC_BC_TACS<<28)|(SMC_BC_TCOS<<24)| \
> > + (SMC_BC_TACC<<16)|(SMC_BC_TCOH<<12)| \
> > + (SMC_BC_TAH<<8)|(SMC_BC_TACP<<4)|(SMC_BC_PMC))
> > +
> > +#ifndef __ASSEMBLY__
> > +struct s5pc1xx_smc {
> > + unsigned intbw;
> > + unsigned intbc[6];
> > +};
> > +#endif /* __ASSEMBLY__ */
> > +
> > +#endif /* __ASM_ARCH_SMC_H_ */
> > --
> > 1.6.6
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
>
> Did you see my comments?
> http://lists.denx.de/pipermail/u-boot/2010-February/067647.html
I fixed most of your comments and for some i gave explanations,
Can you please follow the previous mail once again.
>
>
> 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
>
--
Shine bright,
(: Naveen Krishna Ch :)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9 V4] convert common files to new SoC access
Daniel Gorsulowski wrote: > - tmp = at91_sys_read(AT91_CKGR_MCFR); > - } while (!(tmp & AT91_PMC_MAINRDY)); > - main_clock = (tmp & AT91_PMC_MAINF) * (AT91_SLOW_CLOCK / 16); > + tmp = readl(&pmc->mcfr); > + } while (!(tmp & AT91_PMC_IXR_MCKRDY)); > + main_clock = (tmp & (0x << 0)) * (AT91_SLOW_CLOCK / 16); > } > #endif > main_clk_rate_hz = main_clock; > -- > > I replaced AT91_PMC_MAINF with (0x << 0), because AT91_PMC_MAINF in not > available anymore. Maybe you find a better solution... > Sorry, I committed before testing. AT91_PMC_IXR_MCKRDY is wrong. It should be replaced by 0x0001 or an appropriate #define Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 2/3 v2] s3c24x0 code style changes
Hi Minkyu
Thanks for your comments...
On 11/02/2010 08:37, Minkyu Kang wrote:
> Dear Kevin Morfitt,
>
> On 11 February 2010 00:20, Kevin Morfitt
> wrote:
>> Changes the s3c24x0 files to meet the code style requirements.
>>
>> Signed-off-by: Kevin Morfitt
>> ---
>>
>> v2 changes:
>> - re-number to be 2/3
>>
>> checkpatch.pl reports no errors.
>>
>> board/MAI/AmigaOneG3SE/video.c|1 -
>> board/mpl/common/common_util.h|1 +
>> board/mpl/common/flash.c |1 -
>> board/mpl/vcma9/cmd_vcma9.c |9 -
>> board/mpl/vcma9/vcma9.c | 27 ++--
>> board/mpl/vcma9/vcma9.h |6 +-
>> board/samsung/smdk2400/smdk2400.c | 12 +-
>> board/sbc2410x/sbc2410x.c |6 +-
>> board/trab/auto_update.c | 30 +---
>> board/trab/cmd_trab.c | 213 +++-
>> board/trab/rs485.c| 16 +-
>> board/trab/trab.c | 43 ++---
>> board/trab/trab.h | 38 +
>> board/trab/trab_fkt.c | 331
>> -
>> board/trab/tsc2000.c | 12 +-
>> board/trab/tsc2000.h |1 +
>> board/trab/vfd.c | 70
>> common/cmd_version.c |2 -
>> common/cmd_vfd.c |2 -
>> common/main.c |5 +-
>> drivers/i2c/s3c24x0_i2c.c | 71 -
>> drivers/video/cfb_console.c |1 -
>> include/common.h | 14 ++
>> lib_generic/display_options.c |2 -
>> 24 files changed, 418 insertions(+), 496 deletions(-)
>> create mode 100644 board/trab/trab.h
>>
>>
>> -extern void print_vcma9_info(void);
>> -extern int vcma9_cantest(int);
>> -extern int vcma9_nandtest(void);
>> -extern int vcma9_nanderase(void);
>> -extern int vcma9_nandread(ulong);
>> -extern int vcma9_nandwrite(ulong);
>> -extern int vcma9_dactest(int);
>> -extern int do_mplcommon(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
>> -
>> /*
>> - */
>>
>
> removing extern functions and values are ok.
> but I wonder if it occur compile warnings.
> Did you test it?
I added a new file, trab.h, with the function prototypes for the
external functions. There were no new build warnings.
>
>> int do_vcma9(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
>> diff --git a/board/mpl/vcma9/vcma9.c b/board/mpl/vcma9/vcma9.c
>> index 9a7c0fa..5401664 100644
>> --- a/board/mpl/vcma9/vcma9.c
>> +++ b/board/mpl/vcma9/vcma9.c
>> @@ -137,22 +137,19 @@ int board_init(void)
>> * NAND flash initialization.
>> */
>> #if defined(CONFIG_CMD_NAND)
>> -extern ulong
>> -nand_probe(ulong physadr);
>> -
>> -
>> static inline void NF_Reset(void)
>> {
>> int i;
>>
>> NF_SetCE(NFCE_LOW);
>> - NF_Cmd(0xFF); /* reset command */
>> - for (i = 0; i< 10; i++); /* tWB = 100ns. */
>> - NF_WaitRB();/* wait 200~500us; */
>> + NF_Cmd(0xFF); /* reset command */
>> + /* tWB = 100ns. */
>> + for (i = 0; i< 10; i++)
>> + /* delay */;
>> + NF_WaitRB();/* wait 200~500us; */
>> NF_SetCE(NFCE_HIGH);
>> }
>>
>> static u8 Get_PLD_Revision(void)
>> {
>> - return (Get_PLD_ID()& 0x0F);
>> + return Get_PLD_ID()& 0x0F;
>> }
>>
>> static uchar Get_Board_PCB(void)
>> {
>> - return (((Get_PLD_BOARD()>> 4)& 0x03) + 'A');
>> + return ((Get_PLD_BOARD()>> 4)& 0x03) + 'A';
>> }
>>
>> static u8 Get_SDRAM_ChipNr(void)
>
> Do you have plan for clean up such upper case function names?
I didn't notice those, probably because checkpatch doesn't warn about
them. I'll change it.
>
>> @@ -307,7 +304,7 @@ int checkboard(void)
>> s[5] = 0;
>> Show_VCMA9_Info(s,&s[6]);
>> }
>> - return (0);
>> + return 0;
>> }
>>
>> int last_stage_init(void)
>> diff --git a/board/mpl/vcma9/vcma9.h b/board/mpl/vcma9/vcma9.h
>> index e1ec1fe..adc7673 100644
>> --- a/board/mpl/vcma9/vcma9.h
>> +++ b/board/mpl/vcma9/vcma9.h
>> @@ -27,7 +27,8 @@
>>
>> #include
>>
>> -extern int mem_test(unsigned long start, unsigned long ramsize, int mode);
>> +int mem_test(unsigned long start, unsigned long ramsize, int mode);
>> +int vcma9_cantest(int);
>> void print_vcma9_info(void);
>>
>> #if defined(CONFIG_CMD_NAND)
>> @@ -81,7 +82,8 @@ static inline void NF_WaitRB(void)
>> {
>> struct s3c2410_nand * const nand = s3c2410_get_base_nand();
>>
>> - while (!(nand->NFSTAT& (1<< 0)));
>> + while (!(nand->NFSTAT& (1<< 0)))
>> + /* Wait */;
>> }
>>
>> static inline void NF_Write(u8 data)
>> diff --git a/board/samsung/smdk2400/smdk2400.c
>> b/board/samsung/smdk2400/smdk2400.c
>> index 5825ce9..a1b0e0c 100644
>> --- a/board/samsung/smdk2400/smdk2400.c
Re: [U-Boot] POST related question
Hi Michael, > On Wed, Feb 10, 2010 at 5:54 PM, Detlev Zundel wrote: >> Hi Michael, >> >>> Working on the POST for our board (which I am going to submit >>> to the u-boot in the near future) I was asked to output the POST tests >>> sequence progress to the dedicated LEDs (current test’s index and >>> test’s result – PASS or FAIL) in addition to the conventional console >>> output. Such indication can be helpful at the customer premises when >>> console is not available as well as at the production testing/diagnostics >>> to understand which POST test has failed while serial console does not >>> show signs of life. >>> In order to fulfill this requirement I see two possibilities: >>> >>> 1) Common infrastructure change - add pre-test and after test callbacks >>> to the post_test structure in the tests.c file. Call these callbacks >>> before and after each POST test in the post_run_single routine of post.c >>> file. >>> >>> 2) Local, board specific change – duplicate all necessary POST tests into >>> specific board folder and add output to LEDs interface into every >>> _post_test routine. >>> >>> Please advise. >> >> Thinking about it, why can't we 3) introduce show_post_progress(). It >> seems to me that the show_boot_progress (grep the README) implements >> exactly the same idea for the boot process, so it would make sense to >> re-use the implementation idea. Nowadays we could solve the overrideing >> with weak functions. >> >> What do you think? >> [...] > Actually the option #3 is very similar to the #1 option about which I thought > also before my first post… However, option #1 has few advantages as: > > a) Flexibility - it is not restricted to the progress status only; > rather it can be > customized for additional functionality such as printing of extended user > notification before and after specific test or doing something else… > > b) In the case of slow POST tests it will be especially helpful to know which > test is currently executing, immediately at the beginning of the test (form > within pre-test phase) while the test’s results will come long time after this > moment and can be indicated via after-test phase. > > Again, we need such indication only when POST output for some reason is > not available via serial console. > > Of course, these pre/after callbacks can be added explicitly at the > beginning/end > of every post test (what is actually the option #3) but making them to > be a part of > the post_test structure keeps code smaller and more readable. > > I agree that the show_boot_progress is good approach in general but in the > POST > system where we have the callback infrastructure already in place why > do not use > its advantages? Ok, maybe we should get more specific here. If I understand you correctly, your original option #1 would add two callback fields to the post_test structure post_list in tests.c, right? I believe this to be real overkill - this allows for potentialle 2 times the number of tests different functions to be called, whereas I would imagine that at most two functions will be used in reality, i.e. one before a test runs - called with an argument of what test will be started - and one after the test ran - again called with an argument indicating the test. My original idea of only onw function still makes sense to me in that I myself would want to keep the code doing indications to the user in one central place. So maybe we could have a show_post_progress(int index, int before, int result) which is called from the common infrastructure with the corresponding values before and after a test. In this setup one should be able to produce meaningful output through whatever means are available and it boils down to very little code in the end. Do you believe you need more flexibility? Cheers Detlev -- The structure of a system reflects the structure of the organization that built it. -- Richard E. Fairley -- 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] Booting from NAND on MX51
Hi Eric, Thank you for the information. Yes, I have found 2 DCD errors when comparing RedBood DCDs with u-boot DCDs, I fixed those error and now the MX51 ROM boot loader copies the u-boot code into RAM. Someone will need to double check those in Redboot with those in u-boot and update the u-boot code. See below the flash_header.S file that I am using. Now the system copies code from NAND but crashes somewhere at the early stage. Are any more switches that might need to be turned "on", or "off" in the mx51_3stack config file? Regards, Andreas /* * Copyright 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 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 "board-mx51_3stack.h" #ifdef CONFIG_FLASH_HEADER #ifndef CONFIG_FLASH_HEADER_OFFSET # error "Must define the offset of flash header" #endif #define MXC_DCD_ITEM(i, type, addr, val)\ dcd_node_##i: \ .word type ; \ .word addr ; \ .word val ; \ .section ".text.flasheader", "x" b _start .orgCONFIG_FLASH_HEADER_OFFSET app_code_jump_v:.word _start app_code_code_barker: .word CONFIG_FLASH_HEADER_BARKER app_code_csf: .word (TEXT_BASE + 0x4 - 0x1000) //0 dcd_ptr_ptr:.word dcd_ptr super_root_key: .word 0 dcd_ptr:.word dcd_array_start app_dest_ptr: .word TEXT_BASE dcd_array_start: magic: .word 0xB17219E9 dcd_array_size: .word dcd_data_end - dcd_array_start - 8 /* DCD */ /* DDR2 IOMUX configuration */ MXC_DCD_ITEM(1, 4, IOMUXC_BASE_ADDR + 0x8a0, 0x200) MXC_DCD_ITEM(2, 4, IOMUXC_BASE_ADDR + 0x50c, 0x20c5) MXC_DCD_ITEM(3, 4, IOMUXC_BASE_ADDR + 0x510, 0x20c5) MXC_DCD_ITEM(4, 4, IOMUXC_BASE_ADDR + 0x83c, 0x2) MXC_DCD_ITEM(5, 4, IOMUXC_BASE_ADDR + 0x848, 0x2) MXC_DCD_ITEM(6, 4, IOMUXC_BASE_ADDR + 0x4b8, 0xe7) MXC_DCD_ITEM(7, 4, IOMUXC_BASE_ADDR + 0x4bc, 0x45) MXC_DCD_ITEM(8, 4, IOMUXC_BASE_ADDR + 0x4c0, 0x45) MXC_DCD_ITEM(9, 4, IOMUXC_BASE_ADDR + 0x4c4, 0x45) MXC_DCD_ITEM(10, 4, IOMUXC_BASE_ADDR + 0x4c8, 0x45) MXC_DCD_ITEM(11, 4, IOMUXC_BASE_ADDR + 0x820, 0x0) MXC_DCD_ITEM(12, 4, IOMUXC_BASE_ADDR + 0x4a4, 0x3) MXC_DCD_ITEM(13, 4, IOMUXC_BASE_ADDR + 0x4a8, 0x3) MXC_DCD_ITEM(14, 4, IOMUXC_BASE_ADDR + 0x4ac, 0xe3) MXC_DCD_ITEM(15, 4, IOMUXC_BASE_ADDR + 0x4b0, 0xe3) MXC_DCD_ITEM(16, 4, IOMUXC_BASE_ADDR + 0x4b4, 0xe3) MXC_DCD_ITEM(17, 4, IOMUXC_BASE_ADDR + 0x4cc, 0xe3) MXC_DCD_ITEM(18, 4, IOMUXC_BASE_ADDR + 0x4d0, 0xe2) /* Set drive strength to MAX */ #if 0 MXC_DCD_ITEM(19, 4, IOMUXC_BASE_ADDR + 0x82c, 0x6) MXC_DCD_ITEM(20, 4, IOMUXC_BASE_ADDR + 0x8a4, 0x6) MXC_DCD_ITEM(21, 4, IOMUXC_BASE_ADDR + 0x8ac, 0x6) MXC_DCD_ITEM(22, 4, IOMUXC_BASE_ADDR + 0x8b8, 0x6) #endif /* 13 ROW, 10 COL, 32Bit, SREF=4 Micron Model */ /* CAS=3, BL=4 */ MXC_DCD_ITEM(19, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDCTL0, 0x82a2) MXC_DCD_ITEM(20, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDCTL1, 0x82a2) MXC_DCD_ITEM(21, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDMISC, 0x000ad0d0) MXC_DCD_ITEM(22, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDCFG0, 0x333574aa) MXC_DCD_ITEM(23, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDCFG1, 0x333574aa) /* Init DRAM on CS0 */ MXC_DCD_ITEM(24, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x04008008) MXC_DCD_ITEM(25, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x801a) MXC_DCD_ITEM(26, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x801b) MXC_DCD_ITEM(27, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x8019) /* error*/ MXC_DCD_ITEM(28, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x07328018) MXC_DCD_ITEM(29, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x04008008) MXC_DCD_ITEM(30, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x8010) MXC_DCD_ITEM(31, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x8010) MXC_DCD_ITEM(32, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x06328018) MXC_DCD_ITEM(33, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x03808019) MXC_DCD_ITEM(34, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x00428019) /* error */ MXC_DCD_ITEM(35, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x8000) /* Init DRAM on CS1 */ MXC_DCD_ITEM(36, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x0400800c) MXC_DCD_ITEM(37, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x801e) MXC_DCD_ITEM(38, 4, ESDCTL_BASE_ADDR + ESDCTL_ESDSCR, 0x801f) MXC_
Re: [U-Boot] POST related question
On Thu, Feb 11, 2010 at 11:49 AM, Detlev Zundel wrote: > Hi Michael, > >> On Wed, Feb 10, 2010 at 5:54 PM, Detlev Zundel wrote: >>> Hi Michael, >>> Working on the POST for our board (which I am going to submit to the u-boot in the near future) I was asked to output the POST tests sequence progress to the dedicated LEDs (current test’s index and test’s result – PASS or FAIL) in addition to the conventional console output. Such indication can be helpful at the customer premises when console is not available as well as at the production testing/diagnostics to understand which POST test has failed while serial console does not show signs of life. In order to fulfill this requirement I see two possibilities: 1) Common infrastructure change - add pre-test and after test callbacks to the post_test structure in the tests.c file. Call these callbacks before and after each POST test in the post_run_single routine of post.c file. 2) Local, board specific change – duplicate all necessary POST tests into specific board folder and add output to LEDs interface into every _post_test routine. Please advise. >>> >>> Thinking about it, why can't we 3) introduce show_post_progress(). It >>> seems to me that the show_boot_progress (grep the README) implements >>> exactly the same idea for the boot process, so it would make sense to >>> re-use the implementation idea. Nowadays we could solve the overrideing >>> with weak functions. >>> >>> What do you think? >>> > > [...] > >> Actually the option #3 is very similar to the #1 option about which I thought >> also before my first post… However, option #1 has few advantages as: >> >> a) Flexibility - it is not restricted to the progress status only; >> rather it can be >> customized for additional functionality such as printing of extended user >> notification before and after specific test or doing something else… >> >> b) In the case of slow POST tests it will be especially helpful to know >> which >> test is currently executing, immediately at the beginning of the test (form >> within pre-test phase) while the test’s results will come long time after >> this >> moment and can be indicated via after-test phase. >> >> Again, we need such indication only when POST output for some reason is >> not available via serial console. >> >> Of course, these pre/after callbacks can be added explicitly at the >> beginning/end >> of every post test (what is actually the option #3) but making them to >> be a part of >> the post_test structure keeps code smaller and more readable. >> >> I agree that the show_boot_progress is good approach in general but in the >> POST >> system where we have the callback infrastructure already in place why >> do not use >> its advantages? > > Ok, maybe we should get more specific here. If I understand you > correctly, your original option #1 would add two callback fields to the > post_test structure post_list in tests.c, right? I believe this to be > real overkill - this allows for potentialle 2 times the number of tests > different functions to be called, whereas I would imagine that at most > two functions will be used in reality, i.e. one before a test runs - > called with an argument of what test will be started - and one after the > test ran - again called with an argument indicating the test. > > My original idea of only onw function still makes sense to me in that I > myself would want to keep the code doing indications to the user in one > central place. So maybe we could have a show_post_progress(int index, > int before, int result) which is called from the common infrastructure > with the corresponding values before and after a test. In this setup > one should be able to produce meaningful output through whatever means > are available and it boils down to very little code in the end. > > Do you believe you need more flexibility? > > Cheers > Detlev > > -- > The structure of a system reflects the structure of the organization > that built it. > -- Richard E. Fairley > -- > 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 > If I understand you correctly, you suggest adding of direct “weak” calls before and after call to POST test callback in the post_run_single routine of post.c file instead of adding callbacks to the post_test structure. Agree, its has the same measure of flexibility. Thanks, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] POST related question
Hi Michael, > If I understand you correctly, you suggest adding of direct “weak” calls > before and after call to POST test callback in the post_run_single > routine of post.c file > instead of adding callbacks to the post_test structure. > Agree, its has the same measure of flexibility. Yes, I was thinking of adding such weak calls before and after the individual calls to the test routines themselves. Cheers Detlev -- Just the omission of Jane Austen's books alone would make a fairly good library out of a library that hadn't a book in it. -- 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] Booting from NAND on MX51
Hi Andreas, > Thank you for the information. Yes, I have found 2 DCD errors when comparing > RedBood DCDs with u-boot DCDs, > I fixed those error and now the MX51 ROM boot loader copies the u-boot code > into RAM. Would you please be so kind and point those errors out explicitely so that not every reader has to find the differences by himself? Posting a patch which does the updates would be an easy way to accompish this... Thanks Detlev -- 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
[U-Boot] MCF5235 use internal Flash as a MTD device
Hi I want to use the internal flash , with the U-Boot Loader inside, on my M5235EVB Demo Board as a MTD Device. What do I have to do ? Regards Wilfried ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting from NAND on MX51
Detlev Zundel wrote: > Would you please be so kind and point those errors out explicitely so > that not every reader has to find the differences by himself? Posting a > patch which does the updates would be an easy way to accompish this... And why not to send a patch to try to get the 3stack board supported in the u-boot mainline ? The differences reported are related to the Freescale's delivery, that is at the end a u-boot fork (2009.01 or 2009.08), not part of mainline. Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] POST related question
On Thu, Feb 11, 2010 at 1:43 PM, Detlev Zundel wrote: > Hi Michael, > >> If I understand you correctly, you suggest adding of direct “weak” calls >> before and after call to POST test callback in the post_run_single >> routine of post.c file >> instead of adding callbacks to the post_test structure. >> Agree, its has the same measure of flexibility. > > Yes, I was thinking of adding such weak calls before and after the > individual calls to the test routines themselves. > > Cheers > Detlev > > -- > Just the omission of Jane Austen's books alone would make a fairly > good library out of a library that hadn't a book in it. > -- 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 > Detlev, Thanks for advice, I will submit this patch promptly. Regards, Michael. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9 V4] add new CONFIG_AT91_LEGACY
Daniel Gorsulowski wrote: > Hello Tom, > > Tom wrote: >> Jens Scharsig wrote: >>> * add's the new temporary CONFIG_AT91_LEGACY to all board configs >>> This will need for backward compatiblity, while change the SoC access >>> to c structures. If CONFIG_AT91_LEGACY is defined, the deprecated >>> SoC is used. >>> >>> >>> Signed-off-by: Jens Scharsig >> This looks good. >> The only problem is the new at91 target otc570 is breaking. >> >> Please take a look at errors in otc570 >> >> otc570 : >> >> at91sam9263_devices.c: In function 'at91_serial0_hw_init': >> at91sam9263_devices.c:40: warning: implicit declaration of function >> 'at91_set_a_periph' >> at91sam9263_devices.c: In function 'at91_spi0_hw_init': >> at91sam9263_devices.c:96: warning: implicit declaration of function >> 'at91_set_b_periph' >> at91sam9263_devices.c:116: warning: implicit declaration of function >> 'at91_set_pio_output' >> clock.c: In function 'at91_clock_init': >> clock.c:160: warning: implicit declaration of function 'at91_sys_read' >> clock.c:160: error: 'AT91_CKGR_MCFR' undeclared (first use in this function) >> clock.c:160: error: (Each undeclared identifier is reported only once >> clock.c:160: error: for each function it appears in.) >> >> Tom > > This is caused by missing defines in include\configs\otc570.h: > #define CONFIG_AT91_LEGACY > and > #define CONFIG_AT91_GPIO 1 > > Should I send a patch to fix this, or should I wait for Jens patches coming > mainline? > Please send a patch. It should be a 2-3 liner. I will combine it with Jens' patchset and push them together. Tom > Best regards, > Daniel Gorsulowski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] AT91: Update otc570 board to new SoC access
* convert otc570 board to use c stucture SoC access
* change gpio access to at91_gpio syntax
Signed-off-by: Daniel Gorsulowski
---
This patch requires Jens Scharsigs new SoC access patchset.
http://lists.denx.de/pipermail/u-boot/2010-February/067424.html
http://lists.denx.de/pipermail/u-boot/2010-February/067425.html
http://lists.denx.de/pipermail/u-boot/2010-February/067426.html
http://lists.denx.de/pipermail/u-boot/2010-February/067427.html
http://lists.denx.de/pipermail/u-boot/2010-February/067428.html
http://lists.denx.de/pipermail/u-boot/2010-February/067429.html
http://lists.denx.de/pipermail/u-boot/2010-February/067430.html
http://lists.denx.de/pipermail/u-boot/2010-February/067431.html
http://lists.denx.de/pipermail/u-boot/2010-February/067432.html
Apart from a tiny change, I give them an ACK. See
http://lists.denx.de/pipermail/u-boot/2010-February/067674.html
and
http://lists.denx.de/pipermail/u-boot/2010-February/067680.html
board/esd/otc570/otc570.c | 180 -
include/configs/otc570.h | 25 +++---
2 files changed, 107 insertions(+), 98 deletions(-)
diff --git a/board/esd/otc570/otc570.c b/board/esd/otc570/otc570.c
index 056df37..9883d5e 100644
--- a/board/esd/otc570/otc570.c
+++ b/board/esd/otc570/otc570.c
@@ -28,13 +28,13 @@
#include
#include
-#include
#include
#include
#include
#include
+#include
+#include
#include
-#include
#include
#include
#include
@@ -58,10 +58,10 @@ int get_hw_rev(void)
if (hw_rev >= 0)
return hw_rev;
- hw_rev = at91_get_gpio_value(AT91_PIN_PB19);
- hw_rev |= at91_get_gpio_value(AT91_PIN_PB20) << 1;
- hw_rev |= at91_get_gpio_value(AT91_PIN_PB21) << 2;
- hw_rev |= at91_get_gpio_value(AT91_PIN_PB22) << 3;
+ hw_rev = at91_get_pio_value(AT91_PIO_PORTB, 19);
+ hw_rev |= at91_get_pio_value(AT91_PIO_PORTB, 20) << 1;
+ hw_rev |= at91_get_pio_value(AT91_PIO_PORTB, 21) << 2;
+ hw_rev |= at91_get_pio_value(AT91_PIO_PORTB, 22) << 3;
if (hw_rev == 15)
hw_rev = 0;
@@ -73,40 +73,44 @@ int get_hw_rev(void)
static void otc570_nand_hw_init(void)
{
unsigned long csa;
+ at91_smc_t *smc= (at91_smc_t *) AT91_SMC0_BASE;
+ at91_matrix_t *matrix = (at91_matrix_t *) AT91_MATRIX_BASE;
/* Enable CS3 */
- csa = at91_sys_read(AT91_MATRIX_EBI0CSA);
- at91_sys_write(AT91_MATRIX_EBI0CSA,
- csa | AT91_MATRIX_EBI0_CS3A_SMC_SMARTMEDIA);
+ csa = readl(&matrix->csa[0]) | AT91_MATRIX_CSA_EBI_CS3A;
+ writel(csa, &matrix->csa[0]);
/* Configure SMC CS3 for NAND/SmartMedia */
- at91_sys_write(AT91_SMC_SETUP(3),
- AT91_SMC_NWESETUP_(1) | AT91_SMC_NCS_WRSETUP_(0) |
- AT91_SMC_NRDSETUP_(1) | AT91_SMC_NCS_RDSETUP_(0));
- at91_sys_write(AT91_SMC_PULSE(3),
- AT91_SMC_NWEPULSE_(3) | AT91_SMC_NCS_WRPULSE_(3) |
- AT91_SMC_NRDPULSE_(3) | AT91_SMC_NCS_RDPULSE_(3));
- at91_sys_write(AT91_SMC_CYCLE(3),
- AT91_SMC_NWECYCLE_(5) | AT91_SMC_NRDCYCLE_(5));
- at91_sys_write(AT91_SMC_MODE(3),
- AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
- AT91_SMC_EXNWMODE_DISABLE |
- AT91_SMC_DBW_8 |
- AT91_SMC_TDF_(2));
+ writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) |
+ AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0),
+ &smc->cs[3].setup);
+
+ writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(3) |
+ AT91_SMC_PULSE_NRD(3) | AT91_SMC_PULSE_NCS_RD(3),
+ &smc->cs[3].pulse);
+
+ writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(5),
+ &smc->cs[3].cycle);
+ writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+ AT91_SMC_MODE_EXNW_DISABLE |
+ AT91_SMC_MODE_DBW_8 |
+ AT91_SMC_MODE_TDF_CYCLE(2),
+ &smc->cs[3].mode);
/* Configure RDY/BSY */
- at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
+ at91_set_pio_input(CONFIG_SYS_NAND_READY_PIN, 1);
/* Enable NandFlash */
- at91_set_gpio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
+ at91_set_pio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
}
#endif /* CONFIG_CMD_NAND */
#ifdef CONFIG_MACB
static void otc570_macb_hw_init(void)
{
+ at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
/* Enable clock */
- at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_EMAC);
+ writel(1 << AT91SAM9263_ID_EMAC, &pmc->pcer);
at91_macb_hw_init();
}
#endif
@@ -119,26 +123,27 @@ static void otc570_macb_hw_init(void)
*/
static void otc570_ethercat_hw_init(void)
{
+ at91_smc_t *smc1 = (at91_smc_t *) AT91_SMC1_BASE;
+
/* Configure SMC EBI1_CS0 for EtherCAT */
- at91_sys_write(AT91_SMC1_SETUP(0),
- AT91_SMC_NWESETUP_(0) | AT91_SMC_NCS_
Re: [U-Boot] [PATCH v3] SPI: Fix 32 bit transfers in mxc_spi.c
Magnus Lilja wrote: > Commit f9b6a1575d9f1ca192e4cb60e547aa66f08baa3f, "i.MX31: fix SPI > driver for shorter than 32 bit" broke 32 bit transfers. This patch > makes single 32 bit transfer work again. > > Transfer lengths that are known not to work will abort and print > an error message. > > Tested on i.MX31 Litekit and i.MX31 PDK using 32 bit transfers to > the MC13783/ATLAS chip (using the 'date' command). > > Signed-off-by: Magnus Lilja Applied to u-boot-arm. Thanks Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot for Octeon CN56xx
Hi , Where can I find the U-Boot source that supports for Cavium Networks Octeon CN56xx ? Regards, Jamsheeth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MCF5235 use internal Flash as a MTD device
Wilfried, 5235 does not have internal flash. Alternative, you can use FlexBus-NAND, Or SPI-MMC. Best Regards, TsiChung -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wilfried Busalski Sent: Thursday, February 11, 2010 6:11 AM To: u-boot@lists.denx.de Subject: [U-Boot] MCF5235 use internal Flash as a MTD device Hi I want to use the internal flash , with the U-Boot Loader inside, on my M5235EVB Demo Board as a MTD Device. What do I have to do ? Regards Wilfried ___ 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] U-Boot for Octeon CN56xx
Dear Mohamed Jamsheeth H, In message <597ff2a31002111005s12c9a8e7h4e60736f99496...@mail.gmail.com> you wrote: > > Where can I find the U-Boot source that supports for Cavium Networks Octeon > CN56xx ? I'm afraid you will have to ask Cavium technical support for this. They never bothered the submit any of their work upstream. 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 Living on Earth may be expensive, but it includes an annual free trip around the Sun. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 3/3 v3] change s3c24x0 register struct members to lower case
Kevin Morfitt wrote: > Changes the names of the s3c24x0 register struct members from upper-case > to lower-case. > > Signed-off-by: Kevin Morfitt > --- > > v2 changes - re-number to be 3/3 > v3 changes - re-based to modified patch 2/3 > > checkpatch.pl reports no errors. MAKEALL ARM9 reports no new warnings > or errors. > I had problem applying v2 patch 1 to u-boot-arm and u-boot-samsung Can you check if this patchset is correctly rebased. Please also include the whole patchset when submitting so I can test it. Thanks Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot for Octeon CN56xx
Thanks . In that case, I have to go with the source that comes with Cavium SDK . Is NET_CONSOLE supported in U-boot 1.1.1 ? On Fri, Feb 12, 2010 at 12:31 AM, Wolfgang Denk wrote: > Dear Mohamed Jamsheeth H, > > In message <597ff2a31002111005s12c9a8e7h4e60736f99496...@mail.gmail.com> > you wrote: > > > > Where can I find the U-Boot source that supports for Cavium Networks > Octeon > > CN56xx ? > > I'm afraid you will have to ask Cavium technical support for this. > They never bothered the submit any of their work upstream. > > 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 > Living on Earth may be expensive, but it includes an annual free trip > around the Sun. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] enabling watchdog timer
Hi, I'm using an at91sam9260ek board. I configured a watchdog driver in my kernel only to find out that u-boot turns it off. Seaching the information in u-boot I came across some ambiguous information about keeping the watchdog ON. The big top level README files says I need to define CONFIG_WATCHDOG, but the README.at91 in /doc says to define CONFIG_AT91SAM9_WATCHDOG and CONFIG_HW_WATCHDOG. In watchdog.h it says that CONFIG_HW_WATCHDOG and CONFIG_WATCHDOG both cannot be defined at the same time. Whats magic combination? Also in 'README.at91', reference is made to make sure that the watchdog in AT91Bootstrap is not disabled. Where's 'AT91Bootstrap'? I thought I found where it's disabled in 'cpu/arm926ejs/at91/lowlevel_init.s', but this files doesn't even get compiled and I can't figure out where the watchdog is disabled. Can someone point me to where this occurs? Is there an easier approach to what I'm trying to do? Regards, /carl h. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Introduce BIT macro
Most code defines constants for bit positions by means of "(1 << n)". The Linux kernel defines the BIT macro for this purpose, providing a uniform and more readable way to define these constants. This patch adds the BIT macro to linux/bitops.h, and removes its local definitions from davinci and ixp code. Signed-off-by: Matthias Kaehlcke --- cpu/arm926ejs/davinci/cpu.c |2 -- cpu/ixp/npe/include/IxOsalOsIxp400.h |2 -- include/asm-arm/arch-ixp/ixp425.h|2 -- include/linux/bitops.h |1 + 4 files changed, 1 insertions(+), 6 deletions(-) diff --git a/cpu/arm926ejs/davinci/cpu.c b/cpu/arm926ejs/davinci/cpu.c index fc3551c..c274ddd 100644 --- a/cpu/arm926ejs/davinci/cpu.c +++ b/cpu/arm926ejs/davinci/cpu.c @@ -40,8 +40,6 @@ #define PLLC_PLLDIV8 0x170 #define PLLC_PLLDIV9 0x174 -#define BIT(x) (1 << (x)) - /* SOC-specific pll info */ #ifdef CONFIG_SOC_DM355 #define ARM_PLLDIV PLLC_PLLDIV1 diff --git a/cpu/ixp/npe/include/IxOsalOsIxp400.h b/cpu/ixp/npe/include/IxOsalOsIxp400.h index 44a94fb..5e09651 100644 --- a/cpu/ixp/npe/include/IxOsalOsIxp400.h +++ b/cpu/ixp/npe/include/IxOsalOsIxp400.h @@ -47,8 +47,6 @@ #ifndef IxOsalOsIxp400_H #define IxOsalOsIxp400_H -#define BIT(x) (1<<(x)) - #define IXP425_EthA_BASE 0xc8009000 #define IXP425_EthB_BASE 0xc800a000 diff --git a/include/asm-arm/arch-ixp/ixp425.h b/include/asm-arm/arch-ixp/ixp425.h index 2114437..689e1ac 100644 --- a/include/asm-arm/arch-ixp/ixp425.h +++ b/include/asm-arm/arch-ixp/ixp425.h @@ -14,8 +14,6 @@ #ifndef _ASM_ARM_IXP425_H_ #define _ASM_ARM_IXP425_H_ -#define BIT(x) (1<<(x)) - /* FIXME: Only this does work for u-boot... find out why... [RS] */ #define UBOOT_REG_FIX 1 #ifdef UBOOT_REG_FIX diff --git a/include/linux/bitops.h b/include/linux/bitops.h index e724310..c098c9a 100644 --- a/include/linux/bitops.h +++ b/include/linux/bitops.h @@ -104,6 +104,7 @@ static inline unsigned int generic_hweight8(unsigned int w) return (res & 0x0F) + ((res >> 4) & 0x0F); } +#define BIT(nr)(1UL << (nr)) #define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG)) #define BIT_WORD(nr) ((nr) / BITS_PER_LONG) -- 1.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot for Octeon CN56xx
Dear Mohamed Jamsheeth H, In message <597ff2a3100230le0d9e11gc7a9fd483681b...@mail.gmail.com> you wrote: > > Thanks . In that case, I have to go with the source that comes with Cavium > SDK . Ask Cavium for more recent code, and/or forward-port and submit the the patches yourself. > Is NET_CONSOLE supported in U-boot 1.1.1 ? No. It was added with 1.1.2. 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 PLEASE NOTE: Some Quantum Physics Theories Suggest That When the Con- sumer Is Not Directly Observing This Product, It May Cease to Exist or Will Exist Only in a Vague and Undetermined State. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enabling watchdog timer
> I'm using an at91sam9260ek board. I configured a watchdog driver in my > kernel only to find out that u-boot turns it off. The problem with 9260 and friends is that the watchdog can be configured once only. In my experience the best thing to do is leaving it unconfigured (it triggers in 13 seconds, more or less) so the kernel or application can configure it (either enable at a different timeout or or disable it). > The big top level README files says I need to define CONFIG_WATCHDOG, but > [...] I think you should grep around yourself. I did it with 1.1.5 and things are different now. > Also in 'README.at91', reference is made to make sure that the watchdog in > AT91Bootstrap is not disabled. Where's 'AT91Bootstrap'? It is a separate package. An initial program loader that loads the real boot loader from nand or dataflash. You may be using it or not, you have to check that on your setup. If u-boot is not programmed to offset 0 of your nand, you most likely have at91boot there. The stock sources of at91boot disable the watchdog, so you most likely want to change it. I used http://www.at91.com/repFichier/Project-209/at91bootstrap-2.3.tar.bz2 and removed line 84 of board/at91sam9260ek/at91sam9260ek.c . After that, you'll want u-boot to trigger the watchdog without configuring it, unless you need a shorter timeout since the beginning. Hope this helps. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 3/3 v3] change s3c24x0 register struct members to lower case
On 11/02/2010 19:04, Tom wrote: > Kevin Morfitt wrote: >> Changes the names of the s3c24x0 register struct members from upper-case >> to lower-case. >> >> Signed-off-by: Kevin Morfitt >> --- >> >> v2 changes - re-number to be 3/3 >> v3 changes - re-based to modified patch 2/3 >> >> checkpatch.pl reports no errors. MAKEALL ARM9 reports no new warnings >> or errors. >> > > I had problem applying v2 patch 1 to u-boot-arm and u-boot-samsung > Can you check if this patchset is correctly rebased. It's based against Monday's u-boot-master which hasn't changed since then. v1 was against u-boot-samsung but Wolfgang asked me to do it against u-boot-master: "Please adhere to posting guidelines. Patches posted ere MUST be based either on the "master" or on the "next" trees." http://lists.denx.de/pipermail/u-boot/2009-December/065420.html > Please also include the whole patchset when submitting so I can test it. > Thanks > Tom > > > > __ Information from ESET NOD32 Antivirus, version of virus signature > database 4859 (20100211) __ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot for Octeon CN56xx
Thanks .. On Fri, Feb 12, 2010 at 1:40 AM, Wolfgang Denk wrote: > Dear Mohamed Jamsheeth H, > > In message <597ff2a3100230le0d9e11gc7a9fd483681b...@mail.gmail.com> > you wrote: > > > > Thanks . In that case, I have to go with the source that comes with > Cavium > > SDK . > > Ask Cavium for more recent code, and/or forward-port and submit the > the patches yourself. > > > Is NET_CONSOLE supported in U-boot 1.1.1 ? > > No. It was added with 1.1.2. > > 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 > PLEASE NOTE: Some Quantum Physics Theories Suggest That When the Con- > sumer Is Not Directly Observing This Product, It May Cease to Exist > or Will Exist Only in a Vague and Undetermined State. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] regenerating u-boot.lds
the current u-boot.lds target in u-boot depends only on the source file (typically a u-boot.lds.S). this works fine if someone changes the u- boot.lds.S file -- it'll force a regeneration. however, if the u-boot.lds.S file includes u-boot headers such as board config options via config.h, there is no dependency expressed which will cause the file to be regenerated. looking through the build system, i'm not sure there is a way to easily express this. considering the u-boot.lds is trivial to generate (it only gets preprocessed), and every `make` forces a relink of the final u-boot binary, i wonder if we should just label the top level u-boot.lds as phony ? +.PHONY: $(obj)u-boot.lds -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] Introduce BIT macro
Dear Matthias Kaehlcke, In message <20100211200302.ge15...@darwin> you wrote: > Most code defines constants for bit positions by means of "(1 << n)". The > Linux Most code does? I disagree. Only minor parts of the code do, and I generally tend to consider this bad style. > kernel defines the BIT macro for this purpose, providing a uniform and more > readable way to define these constants. This patch adds the BIT macro to > linux/bitops.h, and removes its local definitions from davinci and ixp code. I am strongly tempted to reject this patch, as it does not improve anything. On contrary, it makes things worse. I'll try to explain why. > Signed-off-by: Matthias Kaehlcke > --- > cpu/arm926ejs/davinci/cpu.c |2 -- > cpu/ixp/npe/include/IxOsalOsIxp400.h |2 -- > include/asm-arm/arch-ixp/ixp425.h|2 -- > include/linux/bitops.h |1 + > 4 files changed, 1 insertions(+), 6 deletions(-) With the local definitions in ARM related header files you could at least make an edicated guess what the code might mean. By moving the definition into a globally valid and visible location the inherent problems of sucha definition become obvious. If you see a line of code like value |= 0x0020;or value |= (1 << 5) or vlaue &= ~0x0020; or vlaue &= ~(1 << 5) you know immediately and exactly what that means - there is not the slightest bit of doubt about the meaning of the code. You probably thing that value |= BIT(5); is easier to read. But is this really so? Why do you prefer to write (or read) "BIT(5)" instead of "1 << 5"? Because some of your user manuals talk about "bit5" etc.? Guess why there is not a single use of BIT(x) in PowerPC code in U-Boot? For the Power Architecture, bit 0 is by definition the most significant bit. What does this mean for a simple value as "(1 << 5)"? Size of object (1 << 5) is ... 8 bit bit 2 16 bit bit 10 32 bit bit 26 64 bit bit 58 You see? Even if you are aware that bit 0 is the MSB, the notation of BIT(x) makes no sense, as it at least also depends on the object size. Forget BIT(x). It's unportable and misleading at best. If you want to improve U-Boot code, then please come up with cleanup patches to remove this construct from U-Boot all together. Thanks. 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 thing is, as you progress in the Craft, you'll learn there is another rule... When you break rules, break 'em good and hard. - Terry Pratchett, _Wyrd Sisters_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] edb93xx: two patches for boot code
While working on a board similar to the EDB9315A, I had to fix two more things as my board doesn't boot without them. I already talked with Matthias Kaehlcke who gave me his ack on those patches. Alessandro Rubini (2): ep93xx leds: remove arrays in data section edb93xx sdram: fix initialization board/edb93xx/sdram_cfg.c |7 ++- cpu/arm920t/ep93xx/led.c | 29 + 2 files changed, 15 insertions(+), 21 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ep93xx leds: remove arrays in data section
This code is used at early boot, and using arrays for status
generates references to RAM addresses that are not working.
The patch avoids such structures using a preprocessor macro and
by reading status from hardware in the toggle function.
Meanwhile, inline functions are turned to static to save code space.
Signed-off-by: Alessandro Rubini
Acked-by: Matthias Kaehlcke
---
cpu/arm920t/ep93xx/led.c | 29 +
1 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/cpu/arm920t/ep93xx/led.c b/cpu/arm920t/ep93xx/led.c
index 7e2c897..8b2df04 100644
--- a/cpu/arm920t/ep93xx/led.c
+++ b/cpu/arm920t/ep93xx/led.c
@@ -25,24 +25,21 @@
#include
#include
-static uint8_t saved_state[2] = {STATUS_LED_OFF, STATUS_LED_OFF};
-static uint32_t gpio_pin[2] = {1 << STATUS_LED_GREEN,
- 1 << STATUS_LED_RED};
+/* We can't use arrays in data segment at early boot, but we know n is 0-1 */
+#define GPIO_PIN(n) (1 << (n))
-inline void switch_LED_on(uint8_t led)
+static inline void switch_LED_on(uint8_t led)
{
register struct gpio_regs *gpio = (struct gpio_regs *)GPIO_BASE;
- writel(readl(&gpio->pedr) | gpio_pin[led], &gpio->pedr);
- saved_state[led] = STATUS_LED_ON;
+ writel(readl(&gpio->pedr) | GPIO_PIN(led), &gpio->pedr);
}
-inline void switch_LED_off(uint8_t led)
+static inline void switch_LED_off(uint8_t led)
{
register struct gpio_regs *gpio = (struct gpio_regs *)GPIO_BASE;
- writel(readl(&gpio->pedr) & ~gpio_pin[led], &gpio->pedr);
- saved_state[led] = STATUS_LED_OFF;
+ writel(readl(&gpio->pedr) & ~GPIO_PIN(led), &gpio->pedr);
}
void red_LED_on(void)
@@ -72,17 +69,9 @@ void __led_init(led_id_t mask, int state)
void __led_toggle(led_id_t mask)
{
- if (STATUS_LED_RED == mask) {
- if (STATUS_LED_ON == saved_state[STATUS_LED_RED])
- red_LED_off();
- else
- red_LED_on();
- } else if (STATUS_LED_GREEN == mask) {
- if (STATUS_LED_ON == saved_state[STATUS_LED_GREEN])
- green_LED_off();
- else
- green_LED_on();
- }
+ register struct gpio_regs *gpio = (struct gpio_regs *)GPIO_BASE;
+
+ writel(readl(&gpio->pedr) ^ GPIO_PIN(mask), &gpio->pedr);
}
void __led_set(led_id_t mask, int state)
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] edb93xx sdram: fix initialization
The configuration of SDRAM needs two more writel() operations,
otherwise some boards won't be able to boot. These additional writes
are present in vendor assembly code but were forgotten during the
rewriting in C.
Signed-off-by: Alessandro Rubini
Acked-by: Matthias Kaehlcke
---
board/edb93xx/sdram_cfg.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/board/edb93xx/sdram_cfg.c b/board/edb93xx/sdram_cfg.c
index 6155f0e..418959a 100644
--- a/board/edb93xx/sdram_cfg.c
+++ b/board/edb93xx/sdram_cfg.c
@@ -59,13 +59,15 @@ void sdram_cfg(void)
static void force_precharge(void)
{
+ struct sdram_regs *sdram = (struct sdram_regs *)SDRAM_BASE;
+
+ writel(GLCONFIG_INIT | GLCONFIG_CKE, &sdram->glconfig);
/*
* Errata most EP93xx revisions say that PRECHARGE ALL isn't always
* issued.
*
* Do a read from each bank to make sure they're precharged
*/
-
PRECHARGE_BANK(0);
PRECHARGE_BANK(1);
PRECHARGE_BANK(2);
@@ -101,6 +103,9 @@ static void setup_refresh_timer(void)
static void program_mode_registers(void)
{
+ struct sdram_regs *sdram = (struct sdram_regs *)SDRAM_BASE;
+
+ writel(GLCONFIG_MRS | GLCONFIG_CKE, &sdram->glconfig);
/*
* The mode registers are programmed by performing a read from each
* SDRAM bank. The value of the address that is read defines the value
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] regenerating u-boot.lds
Dear Mike Frysinger, In message <201002110520.54552.vap...@gentoo.org> you wrote: > > the current u-boot.lds target in u-boot depends only on the source file > (typically a u-boot.lds.S). this works fine if someone changes the u- > boot.lds.S file -- it'll force a regeneration. however, if the u-boot.lds.S > file includes u-boot headers such as board config options via config.h, there > is no dependency expressed which will cause the file to be regenerated. I see. Well, this obviously means that appropriate dependeny generation and checking should be added. > looking through the build system, i'm not sure there is a way to easily > express this. considering the u-boot.lds is trivial to generate (it only > gets > preprocessed), and every `make` forces a relink of the final u-boot binary, i > wonder if we should just label the top level u-boot.lds as phony ? > +.PHONY: $(obj)u-boot.lds No, please don't. 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 Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce BIT macro
Hi Wolfgang, El Thu, Feb 11, 2010 at 09:46:22PM +0100 Wolfgang Denk ha dit: > Dear Matthias Kaehlcke, > > In message <20100211200302.ge15...@darwin> you wrote: > > Most code defines constants for bit positions by means of "(1 << n)". The > > Linux > > Most code does? I disagree. Only minor parts of the code do, and I > generally tend to consider this bad style. > > > kernel defines the BIT macro for this purpose, providing a uniform and more > > readable way to define these constants. This patch adds the BIT macro to > > linux/bitops.h, and removes its local definitions from davinci and ixp code. > > I am strongly tempted to reject this patch, as it does not improve > anything. On contrary, it makes things worse. I'll try to explain > why. > > > Signed-off-by: Matthias Kaehlcke > > --- > > cpu/arm926ejs/davinci/cpu.c |2 -- > > cpu/ixp/npe/include/IxOsalOsIxp400.h |2 -- > > include/asm-arm/arch-ixp/ixp425.h|2 -- > > include/linux/bitops.h |1 + > > 4 files changed, 1 insertions(+), 6 deletions(-) > > With the local definitions in ARM related header files you could at > least make an edicated guess what the code might mean. > > By moving the definition into a globally valid and visible location > the inherent problems of sucha definition become obvious. > > > If you see a line of code like > > value |= 0x0020;or value |= (1 << 5) > or > vlaue &= ~0x0020; or vlaue &= ~(1 << 5) > > you know immediately and exactly what that means - there is not the > slightest bit of doubt about the meaning of the code. > > You probably thing that > > value |= BIT(5); > > is easier to read. But is this really so? > > Why do you prefer to write (or read) "BIT(5)" instead of "1 << 5"? > Because some of your user manuals talk about "bit5" etc.? > > Guess why there is not a single use of BIT(x) in PowerPC code in > U-Boot? For the Power Architecture, bit 0 is by definition the most > significant bit. What does this mean for a simple value as "(1 << 5)"? > > > Size of object(1 << 5) is ... > 8 bitbit 2 > 16 bitbit 10 > 32 bitbit 26 > 64 bitbit 58 > > You see? Even if you are aware that bit 0 is the MSB, the notation of > BIT(x) makes no sense, as it at least also depends on the object size. > > > Forget BIT(x). It's unportable and misleading at best. > > If you want to improve U-Boot code, then please come up with cleanup > patches to remove this construct from U-Boot all together. thanks for your explications. i now understand that the BIT macro rather can obscure what is going on, though at the first glance it seems to improve readability. -- Matthias Kaehlcke Embedded Linux Developer Barcelona They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety (Benjamin Franklin) .''`. using free software / Debian GNU/Linux | http://debian.org : :' : `. `'` gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enabling watchdog timer
Much appreciated Alessandro. Some good info to go on. I forgot that u-boot is a second stage bootloader under the 9260 environment, and that the AT91 bootstrap program runs before it. Regards, /carl h. On Thu, Feb 11, 2010 at 3:11 PM, Alessandro Rubini wrote: > > I'm using an at91sam9260ek board. I configured a watchdog driver in my > > kernel only to find out that u-boot turns it off. > > The problem with 9260 and friends is that the watchdog can be > configured once only. In my experience the best thing to do is > leaving it unconfigured (it triggers in 13 seconds, more or less) so > the kernel or application can configure it (either enable at a > different timeout or or disable it). > > > The big top level README files says I need to define CONFIG_WATCHDOG, but > > [...] > > I think you should grep around yourself. I did it with 1.1.5 and things > are different now. > > > Also in 'README.at91', reference is made to make sure that the watchdog > in > > AT91Bootstrap is not disabled. Where's 'AT91Bootstrap'? > > It is a separate package. An initial program loader that loads the > real boot loader from nand or dataflash. You may be using it or not, > you have to check that on your setup. If u-boot is not programmed > to offset 0 of your nand, you most likely have at91boot there. > > The stock sources of at91boot disable the watchdog, so you most likely > want to change it. > > I used > http://www.at91.com/repFichier/Project-209/at91bootstrap-2.3.tar.bz2 > and removed line 84 of board/at91sam9260ek/at91sam9260ek.c . > > After that, you'll want u-boot to trigger the watchdog without > configuring it, unless you need a shorter timeout since the beginning. > > Hope this helps. > /alessandro > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] edb93xx sdram: fix initialization
Hi Alessandro, El Thu, Feb 11, 2010 at 09:46:50PM +0100 Alessandro Rubini ha dit: > The configuration of SDRAM needs two more writel() operations, > otherwise some boards won't be able to boot. These additional writes > are present in vendor assembly code but were forgotten during the > rewriting in C. > > Signed-off-by: Alessandro Rubini > Acked-by: Matthias Kaehlcke i gave my ack after a visual review of the patch, without having tested it. i just installed a patched u-boot on one of my boards and it doesn't boot :( at a first glance the offender seems to be the write to the GlConfig register in force_precharge(), after commenting this line the board comes up. comparing with the initial SDRAM initialization written in assembly i noticed that you set the INIT bit in force_precharge(), while the assembly code doesn't. according to the user manual the INIT must be set to issue PRECHARGE ALL, but if i don't get it wrong this isn't our case, as we assume that PRECHARGE ALL doesn't work (see errata), thus we precharge manually by reading from the RAM. but even after clearing the INIT bit my board refuses to boot. i hope i'll find time this weekend to track this down. if you want to have a look at the initial sequence in assembly, it can be found here: http://lists.denx.de/pipermail/u-boot/2009-December/065133.html cu -- Matthias Kaehlcke Embedded Linux Developer Barcelona We can't solve problems by using the same kind of thinking we used when we created them (Albert Einstein) .''`. using free software / Debian GNU/Linux | http://debian.org : :' : `. `'` gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - ColdFire
Dear TC Liew, In message you wrote: > Wolfgang, > > The following changes since commit 0b692dcb190655c7eb96b6b8003bee163e3b58dd: > Wolfgang Denk (1): > Merge branch 'master' of git://git.denx.de/u-boot-net > > are available in the git repository at: > > git://www.denx.de/git/u-boot-coldfire.git master > > TsiChung Liew (1): > MCF5271-only: Added a weak board_reset function to allow custom reset Hm... strange... The patch as posted (see for example here: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/70457 was submitted by Richard Retanubun; it carries an explicit From: Richard Retanubun and has a different commit message, and a different date. Please make sure to use git-am to apply patches from the mailing list, so dates and attribution is correct. It seems you many > Wolfgang Wegner (3): > add include/asm-m68k/unaligned.h > allow MCF532x to use CONFIG_MONITOR_IS_IN_RAM This patch adds a too long line. Sorry for not noticing this before. > MCF532x: make icache_enable use CONFIG_SYS_SDRAM_SIZE > > cpu/mcf52x2/cpu.c|6 ++ > cpu/mcf52x2/cpu.h| 33 + > cpu/mcf532x/speed.c |3 +++ > cpu/mcf532x/start.S |6 +- > drivers/mtd/cfi_flash.c |2 +- > include/asm-m68k/unaligned.h | 15 +++ > 6 files changed, 63 insertions(+), 2 deletions(-) > create mode 100644 cpu/mcf52x2/cpu.h > create mode 100644 include/asm-m68k/unaligned.h Sorry, not pulled. The long line is a nuisance only, but the wrong attribution should really be fixed. Thanks. 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 An age is called Dark not because the light fails to shine, but because people refuse to see it. -- James Michener, "Space" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - ColdFire
Dear Wolfgang, TsiChung, On Thu, Feb 11, 2010 at 11:55:11PM +0100, Wolfgang Denk wrote: [...] > > Wolfgang Wegner (3): > > add include/asm-m68k/unaligned.h > > allow MCF532x to use CONFIG_MONITOR_IS_IN_RAM > > This patch adds a too long line. Sorry for not noticing this before. sorry for that - it was posted before I found out about checkpatch.pl I can send a corrected patch on tuesday because I do not have that stuff set up here and company is closed until then... :-( Regards, Wolfgang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] add explicit bbt creation to commandline
Hi,
I know this message is about 18 months old. I am using Uboot 2008.10, which
seems to not include support for creating the Nand BBT (bad block table).
Was this patch released and if so when? Forgive me as I don't know how to
find out.
How best to add BBT support to Uboot? I need to have a BBT created such that
Linux can use it when it loads.
I hope you can help.
Thanks in advance,
Steve
P.S.: I snipped out portions of this code to save space in this reply.
Harald Welte wrote:
>
> [PATCH] add explicit bbt creation to commandline ("nand createbbt"
> command)
>
> This patch adds user-requested BBT creation. It includes the following
> changes:
>
> - common/cmd_nand.c: move yes/no decision to separate function
> - do_nand: ask for confirmation for "nand erase"
> - do_nand: add command "nand createbbt" to erase NAND and create a new BBT
>
> Signed-off-by: Werner Almesberger
> Signed-off-by: Harald Welte
>
> ---
>
> diff --git a/common/cmd_nand.c b/common/cmd_nand.c
> index bb46f34..2f41157 100644
> --- a/common/cmd_nand.c
> +++ b/common/cmd_nand.c
> @@ -162,6 +162,17 @@ out:
> return 0;
> }
>
> +static int yes(void)
> +{
> + char c;
> +
> + c = getc();
> + if (c != 'y' && c != 'Y')
> + return 0;
> + c = getc();
> + return c == '\r' || c == '\n';
> +}
> +
> int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
> {
> int i, dev, ret;
> @@ -231,7 +242,8 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc,
> char *argv[])
> strncmp(cmd, "read", 4) != 0 && strncmp(cmd, "write", 5) != 0 &&
> strcmp(cmd, "scrub") != 0 && strcmp(cmd, "markbad") != 0 &&
> strcmp(cmd, "biterr") != 0 &&
> - strcmp(cmd, "lock") != 0 && strcmp(cmd, "unlock") != 0 )
> + strcmp(cmd, "lock") != 0 && strcmp(cmd, "unlock") != 0 &&
> + strcmp(cmd, "createbbt") != 0 )
> goto usage;
>
> /* the following commands operate on the current device */
> @@ -286,13 +298,23 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc,
> char *argv[])
>"are sure of what you are doing!\n"
>"\nReally scrub this NAND flash? \n");
>
> - if (getc() == 'y' && getc() == '\r') {
> + if (yes()) {
> opts.scrub = 1;
> } else {
> puts("scrub aborted\n");
> return -1;
> }
> }
> + else {
> + if (opts.length == nand->size) {
> + puts("Really erase everything ? \n");
> + if (!yes()) {
> + puts("erase aborted\n");
> + return -1;
> + }
> + }
> + }
> +
> ret = nand_erase_opts(nand, &opts);
> printf("%s\n", ret ? "ERROR" : "OK");
>
> @@ -461,6 +483,33 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc,
> char *argv[])
> return 0;
> }
>
> + if (strcmp(cmd, "createbbt") == 0) {
> + struct nand_chip *nand_chip = nand->priv;
> + nand_erase_options_t opts;
> +
> + puts("Create BBT and erase everything ? \n");
> + if (!yes()) {
> + puts("createbbt aborted\n");
> + return -1;
> + }
> + memset(&opts, 0, sizeof(opts));
> + opts.length = nand->size;
> + if (nand_erase_opts(nand, &opts)) {
> + puts("Erase failed\n");
> + return 1;
> +.
> .
> .
> snip
> .
> .
> .
>
>
>
--
View this message in context:
http://old.nabble.com/-PATCH--add-explicit-bbt-creation-to-commandline-tp18299804p27558231.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net/eth.c: bug-fix
--- u-boot-2009.11.1.orig/net/eth.c 2010-01-25 16:35:12.0 +0800 +++ u-boot-2009.11.1/net/eth.c 2010-02-12 11:18:23.558229895 +0800 @@ -199,7 +199,7 @@ #endif /* Try board-specific initialization first. If it fails or isn't * present, try the cpu-specific initialization */ - if (board_eth_init(bis) < 0) + if (board_eth_init(bis) <= 0) cpu_eth_init(bis); #if defined(CONFIG_DB64360) || defined(CONFIG_CPCI750) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 3/3 v3] change s3c24x0 register struct members to lower case
Dear Kevin, On 12 February 2010 05:29, kevin.morf...@fearnside-systems.co.uk wrote: > > > On 11/02/2010 19:04, Tom wrote: >> Kevin Morfitt wrote: >>> Changes the names of the s3c24x0 register struct members from upper-case >>> to lower-case. >>> >>> Signed-off-by: Kevin Morfitt >>> --- >>> >>> v2 changes - re-number to be 3/3 >>> v3 changes - re-based to modified patch 2/3 >>> >>> checkpatch.pl reports no errors. MAKEALL ARM9 reports no new warnings >>> or errors. >>> >> >> I had problem applying v2 patch 1 to u-boot-arm and u-boot-samsung >> Can you check if this patchset is correctly rebased. > > It's based against Monday's u-boot-master which hasn't changed since > then. v1 was against u-boot-samsung but Wolfgang asked me to do it > against u-boot-master: > > "Please adhere to posting guidelines. Patches posted ere MUST be based > either on the "master" or on the "next" trees." > > http://lists.denx.de/pipermail/u-boot/2009-December/065420.html If so, who can apply this patchset? I think need to rebase for u-boot-arm or u-boot-samsung. > >> Please also include the whole patchset when submitting so I can test it. >> Thanks >> Tom >> >> >> >> __ Information from ESET NOD32 Antivirus, version of virus signature >> database 4859 (20100211) __ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> >> > ___ > 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] [PATCH] net/eth.c: bug-fix
On 2/11/2010 8:08 PM, Teh Kok How wrote: > --- u-boot-2009.11.1.orig/net/eth.c 2010-01-25 16:35:12.0 +0800 > > +++ u-boot-2009.11.1/net/eth.c 2010-02-12 11:18:23.558229895 +0800 > > @@ -199,7 +199,7 @@ > > #endif > > /* Try board-specific initialization first. If it fails or isn't > > * present, try the cpu-specific initialization */ > > - if (board_eth_init(bis)< 0) > > + if (board_eth_init(bis)<= 0) > > cpu_eth_init(bis); > > That's not a bug. The check is meant to indicate whether the weak board_eth_init() function has been overridden, not whether there was an error. I have a clarification patch that hasn't been submitted yet. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/eth.c: bug-fix
No, it is a bug. Board_eth_init() calls pci_eth_init() (include/netdev.h) and if ethernet is soc, CONFIG_PCI is not defined, pci_eth_init() returns 0. This patch allows cpu_eth_init() to be called. -Original Message- From: Ben Warren [mailto:biggerbadder...@gmail.com] Sent: Friday, February 12, 2010 1:54 PM To: Teh Kok How Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] net/eth.c: bug-fix On 2/11/2010 8:08 PM, Teh Kok How wrote: > --- u-boot-2009.11.1.orig/net/eth.c 2010-01-25 16:35:12.0 +0800 > > +++ u-boot-2009.11.1/net/eth.c 2010-02-12 11:18:23.558229895 +0800 > > @@ -199,7 +199,7 @@ > > #endif > > /* Try board-specific initialization first. If it fails or isn't > > * present, try the cpu-specific initialization */ > > - if (board_eth_init(bis)< 0) > > + if (board_eth_init(bis)<= 0) > > cpu_eth_init(bis); > > That's not a bug. The check is meant to indicate whether the weak board_eth_init() function has been overridden, not whether there was an error. I have a clarification patch that hasn't been submitted yet. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9 V4] add new CONFIG_AT91_LEGACY
Tom wrote: > Daniel Gorsulowski wrote: >> Hello Tom, >> >> Tom wrote: >>> Jens Scharsig wrote: * add's the new temporary CONFIG_AT91_LEGACY to all board configs This will need for backward compatiblity, while change the SoC access to c structures. If CONFIG_AT91_LEGACY is defined, the deprecated SoC is used. Signed-off-by: Jens Scharsig >>> This looks good. >>> The only problem is the new at91 target otc570 is breaking. >>> >>> Please take a look at errors in otc570 >>> >>> otc570 : >>> >>> at91sam9263_devices.c: In function 'at91_serial0_hw_init': >>> at91sam9263_devices.c:40: warning: implicit declaration of function >>> 'at91_set_a_periph' >>> at91sam9263_devices.c: In function 'at91_spi0_hw_init': >>> at91sam9263_devices.c:96: warning: implicit declaration of function >>> 'at91_set_b_periph' >>> at91sam9263_devices.c:116: warning: implicit declaration of function >>> 'at91_set_pio_output' >>> clock.c: In function 'at91_clock_init': >>> clock.c:160: warning: implicit declaration of function 'at91_sys_read' >>> clock.c:160: error: 'AT91_CKGR_MCFR' undeclared (first use in this function) >>> clock.c:160: error: (Each undeclared identifier is reported only once >>> clock.c:160: error: for each function it appears in.) >>> >>> Tom >> >> This is caused by missing defines in include\configs\otc570.h: >> #define CONFIG_AT91_LEGACY >> and >> #define CONFIG_AT91_GPIO 1 >> >> Should I send a patch to fix this, or should I wait for Jens patches coming >> mainline? >> > > Please send a patch. > It should be a 2-3 liner. > I will combine it with Jens' patchset and push them together. > Tom > You probably recognized that I did not sent a patch with CONFIG_AT91_LEGACY support but I updated the otc570 board to new SoC access. http://lists.denx.de/pipermail/u-boot/2010-February/067691.html I guess, this is the best solution. Best regards, Daniel Gorsulowski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] edb93xx sdram: fix initialization
> i gave my ack after a visual review of the patch, without having > tested it. i just installed a patched u-boot on one of my boards and > it doesn't boot :( Oh. The opposite of my board. Then, since I don't have a 9315A but only a similar one, it's better to drop the patch. I'll have a different sdram_cfg file for mine, then. Thanks for testing, Matthias /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
