[U-Boot] confirmación
Usted tiene una transferencia de dinero de $85.000.Por favor confirmar la recepción con su nombre y su país. Enviar por correo electrónico: wu.lary...@w.cn___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: Aligning arch initialisation sequences
On 13.11.2010 07:31, Reinhard Meyer wrote:
> Dear Graeme Russ, Dear All,
>> On 10/11/10 10:35, Mike Frysinger wrote:
>>> On Sunday, November 07, 2010 05:06:26 Graeme Russ wrote:
Should all architectures strive to look as much like one another as
possible? Should we accept that maybe this particular issue be thrown in
the too hard basket?
>>>
>>> imo, we should strive to have these things in one common place and not just
>>> have the different files look the sam
>>
>> I was afraid someone would say that. I've been having a look and a think
>> about the situation for x86, and I cannot come up with a sane way to
>> emulate the way the global data pointer is handled by the other arches.
>>
>> I essence, the gd pointer is a unique global variable available prior to
>> relocation. On all other arches, this is achieved by using a reserved
>> register which I do not have the luxury of on x86 :(
>>
>> Unless I can resolve this, I cannot move x86 in line with the other arches
>> (i.e. init functions can only be done after relocation).
>
>
> I *personally* prefer code without tool-chain specific, out of "C"
> constructs. So I would be fine with passing gd as a parameter to all
> pre-relocation functions. The way they are called with a function array
> that would probably only marginally increase code size. And instead of
> all the funky stack calculations to get the space for gd, it could be
> achieved in a much simpler way:
>
> in asm: set stack to end (or begin) of SRAM (or whatever)
>
> in c:
> board_early_init(void)
> {
> gd_tauto_gd;
> ...
> call all pre-relocation functions with&auto_gd as parameter
> ...
> relocate and fixup (preferably in C) - would probably
> have arch-specific parts in the ELF fix-up
> ...
> memcpy (&static_gd,&auto_gd, sizeof auto_gd);
> ...
> setup final stack and jump to relocated code...
> that should be a *small* assembly helper function
> }
>
> You get the idea ;)
>
>
Ok, ok, I forgot the hitch that some functions called from
the pre-relocation functions also would need the auto_gd passed on,
*if* they need to use gd. That might become ugly, but x86 has solved
that somehow?
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: Aligning arch initialisation sequences
Dear Graeme Russ, Dear All,
> On 10/11/10 10:35, Mike Frysinger wrote:
>> On Sunday, November 07, 2010 05:06:26 Graeme Russ wrote:
>>> Should all architectures strive to look as much like one another as
>>> possible? Should we accept that maybe this particular issue be thrown in
>>> the too hard basket?
>>
>> imo, we should strive to have these things in one common place and not just
>> have the different files look the sam
>
> I was afraid someone would say that. I've been having a look and a think
> about the situation for x86, and I cannot come up with a sane way to
> emulate the way the global data pointer is handled by the other arches.
>
> I essence, the gd pointer is a unique global variable available prior to
> relocation. On all other arches, this is achieved by using a reserved
> register which I do not have the luxury of on x86 :(
>
> Unless I can resolve this, I cannot move x86 in line with the other arches
> (i.e. init functions can only be done after relocation).
I *personally* prefer code without tool-chain specific, out of "C"
constructs. So I would be fine with passing gd as a parameter to all
pre-relocation functions. The way they are called with a function array
that would probably only marginally increase code size. And instead of
all the funky stack calculations to get the space for gd, it could be
achieved in a much simpler way:
in asm: set stack to end (or begin) of SRAM (or whatever)
in c:
board_early_init(void)
{
gd_tauto_gd;
...
call all pre-relocation functions with &auto_gd as parameter
...
relocate and fixup (preferably in C) - would probably
have arch-specific parts in the ELF fix-up
...
memcpy (&static_gd, &auto_gd, sizeof auto_gd);
...
setup final stack and jump to relocated code...
that should be a *small* assembly helper function
}
You get the idea ;)
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
On Friday, November 12, 2010 05:22:31 Wolfgang Denk wrote: > For now, I would like to ask all CUSTODIANS to register as users at > patchwork.ozlabs.org, so we can arrange that the appropriate > privileges will be granted to you. vapier -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] Commit ecee9... (Program net device MAC addresses after initializing) breakage
On Friday, November 12, 2010 20:51:12 Graeme Russ wrote: > On 13/11/10 12:11, Mike Frysinger wrote: > > On Friday, November 12, 2010 05:55:55 Graeme Russ wrote: > >> On 10/11/10 14:36, Mike Frysinger wrote: > >>> On Saturday, November 06, 2010 18:13:08 Graeme Russ wrote: > I saw discussion a little while ago regarding implementing a version > of malloc that returns cleared memory - did this gain any traction? > >>> > >>> i dont think anyone posted a patch. it would make sense though to > >>> generalize the zalloc() code since some places are already doing it. > >> > >> Actually, I think we should be using calloc() more than we are > > > > if we want to define zalloc() to calloc(), then sure. but forcing people > > to use calloc() with a size=1 is silly. the API is not nearly as > > obvious to passing observers as zalloc(). > > Hmm, U-Boot has a zalloc in lib/gunzip.c which does not zero memory yes, that's why i said we should generalize things -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] RFC: Aligning arch initialisation sequences
On Friday, November 12, 2010 23:16:07 Graeme Russ wrote: > On 10/11/10 10:35, Mike Frysinger wrote: > > On Sunday, November 07, 2010 05:06:26 Graeme Russ wrote: > >> Should all architectures strive to look as much like one another as > >> possible? Should we accept that maybe this particular issue be thrown in > >> the too hard basket? > > > > imo, we should strive to have these things in one common place and not > > just have the different files look the sam > > I was afraid someone would say that. I've been having a look and a think > about the situation for x86, and I cannot come up with a sane way to > emulate the way the global data pointer is handled by the other arches. > > I essence, the gd pointer is a unique global variable available prior to > relocation. On all other arches, this is achieved by using a reserved > register which I do not have the luxury of on x86 :( > > Unless I can resolve this, I cannot move x86 in line with the other arches > (i.e. init functions can only be done after relocation). > > I'll keep thinking about a possible solution i dont think the first cut needs to go all the way. if you want to start small with unifying post-reloc, that's OK too. and probably a lot easier to git bisect in case things go wrong. -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] RFC: Aligning arch initialisation sequences
On 10/11/10 10:35, Mike Frysinger wrote: > On Sunday, November 07, 2010 05:06:26 Graeme Russ wrote: >> Should all architectures strive to look as much like one another as >> possible? Should we accept that maybe this particular issue be thrown in >> the too hard basket? > > imo, we should strive to have these things in one common place and not just > have the different files look the sam I was afraid someone would say that. I've been having a look and a think about the situation for x86, and I cannot come up with a sane way to emulate the way the global data pointer is handled by the other arches. I essence, the gd pointer is a unique global variable available prior to relocation. On all other arches, this is achieved by using a reserved register which I do not have the luxury of on x86 :( Unless I can resolve this, I cannot move x86 in line with the other arches (i.e. init functions can only be done after relocation). I'll keep thinking about a possible solution Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hanging in kmalloc of nand_scan_tail() function
在 2010-11-12五的 11:19 -0600，Scott Wood写道：
> On Fri, 12 Nov 2010 20:45:18 +0800
> terry wrote:
>
> > Dear Scott,
> > I have disassemble the nand_base.o file,because i know the problem
> > happened here.
>
> Why not disassemble the whole u-boot?
>
> Then you'll get malloc as well, and the addresses will be closer to
> what shows up in the dump.
>
> > Do you think it's useful for your analysis?
>
> Can you disassemble malloc? That's where it actually crashed.
following is part of result that I disassemble the whole u-boot.
33f85f50 :
6487 33f85f50: e92d4070push{r4, r5, r6, lr}
6488 33f85f54: e590509cldr r5, [r0, #156]
6489 33f85f58: e595304cldr r3, [r5, #76]
6490 33f85f5c: e3130701tst r3, #262144 ; 0x4
6491 33f85f60: e1a06000mov r6, r0
6492 33f85f64: 1a02bne 33f85f74
6493 33f85f68: e59f04ecldr r0, [pc, #1260] ; 33f8645c
// value seen below.
6494 33f85f6c: eb0026ccbl 33f8faa4
6495 33f85f70: e58500dcstr r0, [r5, #220]
6496 33f85f74: e59510dcldr r1, [r5, #220]
6497 33f85f78: e351cmp r1, #0 ; 0x0
6498 33f85f7c: 03ebmvneq r0, #11 ; 0xb
6499 33f85f80: 08bd8070popeq {r4, r5, r6, pc}
value of pc + 1260:
33f8645c: 128e.word 0x128e
and the following is part of malloc after disassembled, you can find the
detailed content of malloc in the attachment malloc.dis file(I'm not
sure which part could be useful,so I attached whole malloc).
61 33f8fb84: 9a04bls 33f8fb9c
62 33f8fb88: e59f352cldr r3, [pc, #1324] ; 33f900bc
63 33f8fb8c: e1520003cmp r2, r3
64 33f8fb90: 91a0392alsrls r3, sl, #18
65 33f8fb94: 83a0207emovhi r2, #126; 0x7e
66 33f8fb98: 9283207caddls r2, r3, #124; 0x7c
67 33f8fb9c: e59f3514ldr r3, [pc, #1300] ; 33f900b8
68 33f8fba0: e0834182add r4, r3, r2, lsl #3
69 33f8fba4: e594000cldr r0, [r4, #12]
70 33f8fba8: ea12b 33f8fbf8
71 33f8fbac: e5903004ldr r3, [r0, #4]
72 33f8fbb0: e3c33003bic r3, r3, #3 ; 0x3 //it seems that
exception occurs here
73 33f8fbb4: e06a1003rsb r1, sl, r3
74 33f8fbb8: e351000fcmp r1, #15 ; 0xf
75 33f8fbbc: c2422001subgt r2, r2, #1 ; 0x1
76 33f8fbc0: ca0ebgt 33f8fc00
77 33f8fbc4: e351cmp r1, #0 ; 0x0
78 33f8fbc8: e590c00cldr ip, [r0, #12]
79 33f8fbcc: ba08blt 33f8fbf4
80 33f8fbd0: e0803003add r3, r0, r3
81 33f8fbd4: e5932004ldr r2, [r3, #4]
82 33f8fbd8: e5901008ldr r1, [r0, #8]
> > 1a4c :
> > 1749 1a4c: e92d4070push{r4, r5, r6, lr}
> > 1750 1a50: e590509cldr r5, [r0, #156]
> > 1751 1a54: e595304cldr r3, [r5, #76]
> > 1752 1a58: e3130701tst r3, #262144 ; 0x4
> > 1753 1a5c: e1a06000mov r6, r0
> > 1754 1a60: 1a02bne 1a70
> > 1755 1a64: e59f04ecldr r0, [pc, #1260] ; 1f58 > +0x50c>
> > 1756 1a68: ebfebl 0
>
> What's the value at PC+1260?
It's "1f58: 128e.word 0x128e"
>
> > by the way,I cann't find the prototype of malloc in the whole project,it
> > seems that it is encapsulated in some libs.
>
> It's in common/malloc.c. There's weird preprocessor renaming going on,
> so it's called mALLOc in that file, but it shows up as malloc in the
> binary.
Thanks very much for your carefully instruction.
>
> -Scott
>
--
Best regards,
terry
33f8faa0 :
33f8faa0: ea6fb 33f8f864
33f8faa4 :
33f8faa4: e59f2608ldr r2, [pc, #1544] ; 33f900b4
33f8faa8: e5923004ldr r3, [r2, #4]
33f8faac: e353cmp r3, #0 ; 0x0
33f8fab0: e92d47f0push{r4, r5, r6, r7, r8, r9, sl, lr}
33f8fab4: 1a02bne 33f8fac4
33f8fab8: e5923008ldr r3, [r2, #8]
33f8fabc: e353cmp r3, #0 ; 0x0
33f8fac0: 0a000178beq 33f900a8
33f8fac4: e350cmp r0, #0 ; 0x0
33f8fac8: ba000176blt 33f900a8
33f8facc: e28badd r0, r0, #11 ; 0xb
33f8fad0: e3500016cmp r0, #22 ; 0x16
33f8fad4: d3a0a010movle sl, #16 ; 0x10
33f8fad8: da02ble 33f8fae8
33f8fadc: e3c0a007bic sl, r0, #7 ; 0x7
33f8fae0: e35a0f7ecmp sl, #504; 0x1f8
33f8fae4: 2a15bcs 33f8fb40
33f8fae8: e59f35c8ldr r3, [pc, #1480] ; 33f900b8
33f8faec: e1a021aalsr r2, sl, #3
33f8faf0: e0833182add r3, r3, r2, lsl #3
33f8faf4: e593c00cldr ip, [r3, #12]
33f8faf8: e15c0003cmp ip, r3
33f8fafc: 1a04bne 33f8fb14
33f8fb00: e28c3008add r3, ip, #8 ; 0x8
33f8fb04: e593c00cldr ip, [r3, #12]
33f8fb08: e15c0003c
Re: [U-Boot] Commit ecee9... (Program net device MAC addresses after initializing) breakage
On 13/11/10 12:11, Mike Frysinger wrote:
> On Friday, November 12, 2010 05:55:55 Graeme Russ wrote:
>> On 10/11/10 14:36, Mike Frysinger wrote:
>>> On Saturday, November 06, 2010 18:13:08 Graeme Russ wrote:
I saw discussion a little while ago regarding implementing a version of
malloc that returns cleared memory - did this gain any traction?
>>>
>>> i dont think anyone posted a patch. it would make sense though to
>>> generalize the zalloc() code since some places are already doing it.
>>
>> Actually, I think we should be using calloc() more than we are
>
> if we want to define zalloc() to calloc(), then sure. but forcing people to
> use calloc() with a size=1 is silly. the API is not nearly as obvious to
> passing observers as zalloc().
Hmm, U-Boot has a zalloc in lib/gunzip.c which does not zero memory
void *zalloc(void *x, unsigned items, unsigned size)
{
void *p;
size *= items;
size = (size + ZALLOC_ALIGNMENT - 1) & ~(ZALLOC_ALIGNMENT - 1);
p = malloc (size);
return (p);
}
and mtd has kzalloc defined thus:
#define kzalloc(size, flags)calloc(size, 1)
So there is some confusion surrounding 'zalloc' anyway ;)
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Commit ecee9... (Program net device MAC addresses after initializing) breakage
On Friday, November 12, 2010 05:55:55 Graeme Russ wrote: > On 10/11/10 14:36, Mike Frysinger wrote: > > On Saturday, November 06, 2010 18:13:08 Graeme Russ wrote: > >> I saw discussion a little while ago regarding implementing a version of > >> malloc that returns cleared memory - did this gain any traction? > > > > i dont think anyone posted a patch. it would make sense though to > > generalize the zalloc() code since some places are already doing it. > > Actually, I think we should be using calloc() more than we are if we want to define zalloc() to calloc(), then sure. but forcing people to use calloc() with a size=1 is silly. the API is not nearly as obvious to passing observers as zalloc(). -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] Please pull u-boot-mpc85xx.git (updated)
Dear Kumar Gala, In message you wrote: > The following changes since commit 0c0892be0d93a5a892b93739c5eb3bf692fed4ff: > > Merge branch 'master' of git://git.denx.de/u-boot-marvell (2010-10-29 > 22:03:00 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-mpc85xx master > > Becky Bruce (1): > TQM85xx: Fix bug introduced by 83xx/85xx/86xx: LBC register cleanup > > Haiying Wang (3): > powerpc/85xx: Fix lds for nand build > powerpc/85xx: rename CONFIG_SYS_TEXT_BASE to CONFIG_SYS_MONITOR_BASE > powerpc/85xx: add CONFIG_SYS_TEXT_BASE_SPL for 85xx nand spl build > > Kumar Gala (5): > powerpc/8xxx: Fix merge issue with P2020DS DDR2 build config > powerpc/8xxx: Enable e1000 driver on some FSL boards > powerpc/corenet_ds: Enable DHCP suport > powerpc/corenet_ds: Move CONFIG_SYS_TEXT_BASE into corenet_ds.h > powerpc/p4080ds: Move ICS refclk define into P4080DS.h > > Priyanka Jain (1): > p1_p2_rdb: to set SQW/INT pin of RTC as INT line > > Timur Tabi (1): > powerpc/corenet_ds: display the RCW at boot > > arch/powerpc/cpu/mpc85xx/start.S | 18 +- > arch/powerpc/cpu/mpc85xx/u-boot-nand.lds | 49 > +- > arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds | 12 +++--- > board/freescale/corenet_ds/corenet_ds.c | 15 > board/freescale/p1_p2_rdb/p1_p2_rdb.c|4 ++- > board/tqc/tqm85xx/tqm85xx.c |2 +- > boards.cfg |2 +- > include/configs/MPC8536DS.h | 11 +- > include/configs/MPC8569MDS.h | 12 +- > include/configs/MPC8572DS.h |1 + > include/configs/P1022DS.h|1 + > include/configs/P1_P2_RDB.h | 14 ++-- > include/configs/P4080DS.h|6 +-- > include/configs/corenet_ds.h |6 +++- > nand_spl/board/freescale/mpc8536ds/Makefile |4 +- > nand_spl/board/freescale/mpc8569mds/Makefile |4 +- > nand_spl/board/freescale/p1_p2_rdb/Makefile |4 +- > 17 files changed, 89 insertions(+), 76 deletions(-) Applied, 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 Pain is a thing of the mind. The mind can be controlled. -- Spock, "Operation -- Annihilate!" stardate 3287.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request u-boot-blackfin.git (sf branch)
Dear Mike Frysinger, In message <1289381218-17985-1-git-send-email-vap...@gentoo.org> you wrote: > The following changes since commit 0c0892be0d93a5a892b93739c5eb3bf692fed4ff: > > Merge branch 'master' of git://git.denx.de/u-boot-marvell (2010-10-29 > 22:03:00 +0200) > > are available in the git repository at: > > git://www.denx.de/git/u-boot-blackfin.git sf > > Reinhard Meyer (1): > sf: ramtron: new spi fram driver > > drivers/mtd/spi/Makefile |1 + > drivers/mtd/spi/ramtron.c| 319 > ++ > drivers/mtd/spi/spi_flash.c |8 + > drivers/mtd/spi/spi_flash_internal.h |1 + > 4 files changed, 329 insertions(+), 0 deletions(-) > create mode 100644 drivers/mtd/spi/ramtron.c Applied, 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 Dear Lord: I just want *one* one-armed manager so I never have to hear "On the other hand", again. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Dear s-paul...@ti.com, In message <1288902932-24246-1-git-send-email-s-paul...@ti.com> you wrote: > The following changes since commit 0c0892be0d93a5a892b93739c5eb3bf692fed4ff: > Wolfgang Denk (1): > Merge branch 'master' of git://git.denx.de/u-boot-marvell > > are available in the git repository at: > > git://git.denx.de/u-boot-ti.git master > > Alagu Sankar (1): > mmc: Add multi-block read support to the generic mmc driver > > Enric Balletbo i Serra (2): > ARMV7: OMAP3: Use generic mmc driver on IGEP v2 > ARMV7: OMAP3: Use generic mmc driver on OMAP3 IGEP module > > Heiko Schocher (1): > armv7, beagle: Second SDRAM bank don;t work > > Koen Kooi (1): > ARMV7: OMAP3: Add expansion board detection for Beagle > > Sanjeev Premi (3): > omap3evm: Support relocation > omap3evm: Wrap function under CONFIG_USB_OMAP3 > omap3evm: Fix mechanism to identify board revision > > Steve Sakoman (5): > ARMV7: OMAP3: IGEP: Rename TEXT_BASE > ARMV7: Fix build for non-OMAP3 boards > ARMV7: OMAP3: Add expansion board detection for Overo > ARMV7: OMAP: Fix build after introduction of GENERATED_GBL_DATA_SIZE > mmc: Clean up generic mmc driver multi-block write functions > > arch/arm/cpu/armv7/omap3/sdrc.c |7 ++ > arch/arm/lib/cache.c|2 +- > board/isee/igep0020/config.mk |2 +- > board/isee/igep0020/igep0020.c |9 +++ > board/isee/igep0030/config.mk |3 +- > board/isee/igep0030/igep0030.c |9 +++ > board/overo/overo.c | 115 ++ > board/overo/overo.h |4 + > board/ti/beagle/beagle.c| 95 + > board/ti/beagle/beagle.h| 46 - > board/ti/evm/config.mk |2 +- > board/ti/evm/evm.c | 24 ++- > board/ti/evm/evm.h |2 + > drivers/mmc/mmc.c | 148 > ++- > include/configs/igep0020.h |9 ++- > include/configs/igep0030.h |9 ++- > include/configs/omap3_beagle.h |8 ++- > include/configs/omap3_evm.h | 11 +++ > include/configs/omap3_overo.h |7 ++- > include/configs/omap4_panda.h |6 ++- > include/configs/omap4_sdp4430.h |6 ++- > 21 files changed, 411 insertions(+), 113 deletions(-) Pulled into u-boot-arm, 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 If the odds are a million to one against something occuring, chances are 50-50 it will. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] New to U-boot development, adding Octeon support
Dear Aaron, In message <201011121345.22528.aaron.willi...@caviumnetworks.com> you wrote: > > I am rather new to U-boot development and will be working on migrating the > current Cavium Octeon U-boot code to a much more up to date version but I > first have some questions. Welcome! I really appreciate that step. > One of the first things I came across is that we need some significant > changes to some of the MIPS specific libraries and start-up code. Should I > just create separate files under arch/mips/xxx or should I create > subdirectories for the Octeon platform like how it's done for the PowerPC? We should in a first step split the current arch/mips/cpu/ into arch/mips/cpu/au1x00/ and arch/mips/cpu/incaip/; common stuff should go to arch/mips/lib/. In the second step, you could add a arch/mips/cpu/octeon/ directory. > These changes would be global across the Octeon and not board specific. A > number of the changes are required for handling multiple cores. > > Down the road we would also like to add our own replacements to some of the > functions provided by U-boot to speed it up on our platform, for example > taking advantage of the hardware CRC and decompression features. Fine. > Also, what would be a good stable starting version to work from? Top of tree. Your code will be picked up by Shinya Kuribayashi and then pulled from his u-boot-mips repository into mainline. If it should turn out that you generate a lot of commits for a longer time (i. e. more than just an initial pile) we can as well give you a separate u-boot-octeon repository. Just let me know when you feel that would help you. 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 Life is a process, not a principle, a mystery to be lived, not a problem to be solved. - Gerard Straub, television producer and author (stolen from Frank Herbert??) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-atmel/at91
Dear Reinhard Meyer, In message <4ccd346a.5030...@emk-elektronik.de> you wrote: > Dear Wolfgang, > > The following changes since commit 0c0892be0d93a5a892b93739c5eb3bf692fed4ff: > Wolfgang Denk (1): > Merge branch 'master' of git://git.denx.de/u-boot-marvell > > are available in the git repository at: > > git://git.denx.de/u-boot-atmel.git at91 > > Reinhard Meyer (2): > AT91: add 2nd SPI to 9260/9XE/9G20 > AT91: add header file for the Shutdown Controller > > arch/arm/include/asm/arch-at91/at91_shdwn.h | 38 > ++ > arch/arm/include/asm/arch-at91/at91sam9260.h |1 + > arch/arm/include/asm/arch-at91/hardware.h|1 + > arch/arm/include/asm/arch-at91/memory-map.h |1 + > 4 files changed, 41 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/include/asm/arch-at91/at91_shdwn.h Pulled into u-boot-arm, 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 As usual, this being a 1.3.x release, I haven't even compiled this kernel yet. So if it works, you should be doubly impressed. - Linus Torvalds in <199506181536.saa10...@keos.cs.helsinki.fi> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] New to U-boot development, adding Octeon support
Hi, I am rather new to U-boot development and will be working on migrating the current Cavium Octeon U-boot code to a much more up to date version but I first have some questions. My goal is to be able to hopefully submit the changes back into the main U- boot tree and do this as cleanly as possible. One of the first things I came across is that we need some significant changes to some of the MIPS specific libraries and start-up code. Should I just create separate files under arch/mips/xxx or should I create subdirectories for the Octeon platform like how it's done for the PowerPC? These changes would be global across the Octeon and not board specific. A number of the changes are required for handling multiple cores. Down the road we would also like to add our own replacements to some of the functions provided by U-boot to speed it up on our platform, for example taking advantage of the hardware CRC and decompression features. Also, what would be a good stable starting version to work from? -Thanks. -Aaron Williams ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
On Saturday, November 13, 2010, Jerry Van baren wrote: > Hi Wolfgang, > > On 11/12/2010 5:22 AM, Wolfgang Denk wrote: > > Hi all, > > here is some news about organizational changes: > > > [snip] > > > For now, I would like to ask all CUSTODIANS to register as users at > patchwork.ozlabs.org, so we can arrange that the appropriate > privileges will be granted to you. > Registered as 'gruss' Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
Hi Wolfgang, On 11/12/2010 5:22 AM, Wolfgang Denk wrote: > Hi all, > > here is some news about organizational changes: [snip] >For now, I would like to ask all CUSTODIANS to register as users at >patchwork.ozlabs.org, so we can arrange that the appropriate >privileges will be granted to you. I'm registered as "gvb". Thanks, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
Hi, 2010/11/12 Wolfgang Denk : > Several times before it has been suggested to use Patchwork for > U-Boot; in the past, I hesitated to do that for various reasons. But > in the meantime a number of features have been added to Patchwork, > and I think it now can be indeed beneficial to our workflow. > > I'm happy to announce that we now have U-Boot registered as project: > > http://patchwork.ozlabs.org/project/uboot/list/ > > The setup has just been activated; I will try to arrange to have > some more history added, but I don;t want to promise that this will > work, or when this will happen. > > > For now, I would like to ask all CUSTODIANS to register as users at > patchwork.ozlabs.org, so we can arrange that the appropriate > privileges will be granted to you. Surprise, surprise: I registered as 'rbohmer' Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TQM85xx: Fix bug introduced by 83xx/85xx/86xx: LBC register cleanup
On Nov 11, 2010, at 4:30 PM, Wolfgang Denk wrote: > Dear Becky Bruce, > > In message <1289496785-9243-1-git-send-email-bec...@kernel.crashing.org> you > wrote: >> The size of the other bank needed to be added to the br0 setting; >> this got dropped in the LBC cleanup. >> >> Signed-off-by: Becky Bruce >> --- >> This has been neither built or tested, as TQM8555 doesn't seem to build on >> the >> head of this tree, and I don't have a board to test on. > > It build just fine for me... What exactly are your problems? [And > which tool chain are you using?] Actually, that looks to be spurious - I thought i was building from a clean tree but turns out it wasn't. When I do a clean and then a build it works fine. This is what happens when you write code from your car. > > > Your patch indeed fixes the problem (and I'm a bit angry with myself > that I didn't see this problem myself.) Well, that's two of us, because I'm a bit angry at myself for causing it :) Cheers, B > > Thanks a lot! > > > Tested on TQM8555. > > Tested-by: Wolfgang Denk > Acked-by: Wolfgang Denk > > 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 > We are all agreed that your theory is crazy. The question which > divides us is whether it is crazy enough to have a chance of being > correct. My own feeling is that it is not crazy enough. - Niels Bohr ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
On Fri, 12 Nov 2010 13:26:17 -0600 Kumar Gala wrote: > > On Nov 12, 2010, at 11:22 AM, Scott Wood wrote: > > > On Fri, 12 Nov 2010 09:58:53 -0600 > > Kumar Gala wrote: > >> We only do the 'twi' for loads/in_beX not stores/out_beX. > > > > Yes, and the readback is a load. > > following the store with a load should be sufficient I dont think we need the > twi in this case. Do we ever need it, or is guarded+cache inhibited sufficient to completely hold up execution of anything beyond the load? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
On Nov 12, 2010, at 11:22 AM, Scott Wood wrote: > On Fri, 12 Nov 2010 09:58:53 -0600 > Kumar Gala wrote: > >> >> On Nov 4, 2010, at 11:47 AM, Wood Scott-B07421 wrote: >> >>> Joakim Tjernlund wrote: Trial and error suggests that map_flash_by_law1 needs an isync(padding with 4 nop's also did the trick) after updating LBLAWAR1 to make sure the the change has reached the HW before continuing with the code that depends on it. Add an isync to remap_flash_by_law0 for good measure too. >>> >>> To be totally safe, we probably want to do a readback plus twi (to turn a >>> data dependency into a flow dependency) before the isync. >> >> We only do the 'twi' for loads/in_beX not stores/out_beX. > > Yes, and the readback is a load. following the store with a load should be sufficient I dont think we need the twi in this case. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: S3C64XX: fix timer broken by relocation
Le 12/11/2010 19:18, Darius Augulis a écrit :
> Dear Minkyu Kang,
>
> On 11/12/2010 05:10 AM, Minkyu Kang wrote:
>> Dear Darius Augulis,
>>
>> On 2 November 2010 05:49, Darius Augulis wrote:
>>> S3C64XX timer uses static variables which
>>> are initialized before relocation and used after it.
>>> Move them to global data structure.
>>>
>>> Signed-off-by: Darius Augulis
>>> ---
>>>arch/arm/cpu/arm1176/s3c64xx/timer.c | 36
>>> ++
>>>arch/arm/include/asm/global_data.h |6 ++
>>>2 files changed, 21 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/arm1176/s3c64xx/timer.c
>>> b/arch/arm/cpu/arm1176/s3c64xx/timer.c
>>> index 9768319..4e420cb 100644
>>> --- a/arch/arm/cpu/arm1176/s3c64xx/timer.c
>>> +++ b/arch/arm/cpu/arm1176/s3c64xx/timer.c
>>> @@ -43,7 +43,7 @@
>>>#include
>>>#include
>>>
>>> -static ulong timer_load_val;
>>> +DECLARE_GLOBAL_DATA_PTR;
>>>
>>>#define PRESCALER 167
>>>
>>> @@ -60,12 +60,6 @@ static inline ulong read_timer(void)
>>> return timers->TCNTO4;
>>>}
>>>
>>> -/* Internal tick units */
>>> -/* Last decremneter snapshot */
>>> -static unsigned long lastdec;
>>> -/* Monotonic incrementing timer */
>>> -static unsigned long long timestamp;
>>> -
>>>int timer_init(void)
>>>{
>>> s3c64xx_timers *const timers = s3c64xx_get_base_timers();
>>> @@ -83,20 +77,20 @@ int timer_init(void)
>>> * the prescaler automatically for other PCLK frequencies.
>>> */
>>> timers->TCFG0 = PRESCALER<< 8;
>>> - if (timer_load_val == 0) {
>>> - timer_load_val = get_PCLK() / PRESCALER * (100 / 4); /*
>>> 100s */
>>> + if (gd->timer_load_val == 0) {
>>> + gd->timer_load_val = get_PCLK() / PRESCALER * (100 / 4); /*
>>> 100s */
>>> timers->TCFG1 = (timers->TCFG1& ~0xf) | 0x2;
>>> }
>>>
>>> /* load value for 10 ms timeout */
>>> - lastdec = timers->TCNTB4 = timer_load_val;
>>> + gd->lastdec = timers->TCNTB4 = gd->timer_load_val;
>>> /* auto load, manual update of Timer 4 */
>>> timers->TCON = (timers->TCON& ~0x0070) | TCON_4_AUTO |
>>> TCON_4_UPDATE;
>>>
>>> /* auto load, start Timer 4 */
>>> timers->TCON = (timers->TCON& ~0x0070) | TCON_4_AUTO |
>>> COUNT_4_ON;
>>> - timestamp = 0;
>>> + gd->timestamp = 0;
>>>
>>> return 0;
>>>}
>>> @@ -113,16 +107,16 @@ unsigned long long get_ticks(void)
>>>{
>>> ulong now = read_timer();
>>>
>>> - if (lastdec>= now) {
>>> + if (gd->lastdec>= now) {
>>> /* normal mode */
>>> - timestamp += lastdec - now;
>>> + gd->timestamp += gd->lastdec - now;
>>> } else {
>>> /* we have an overflow ... */
>>> - timestamp += lastdec + timer_load_val - now;
>>> + gd->timestamp += gd->lastdec + gd->timer_load_val - now;
>>> }
>>> - lastdec = now;
>>> + gd->lastdec = now;
>>>
>>> - return timestamp;
>>> + return gd->timestamp;
>>>}
>>>
>>>/*
>>> @@ -132,14 +126,14 @@ unsigned long long get_ticks(void)
>>>ulong get_tbclk(void)
>>>{
>>> /* We overrun in 100s */
>>> - return (ulong)(timer_load_val / 100);
>>> + return (ulong)(gd->timer_load_val / 100);
>>>}
>>>
>>>void reset_timer_masked(void)
>>>{
>>> /* reset time */
>>> - lastdec = read_timer();
>>> - timestamp = 0;
>>> + gd->lastdec = read_timer();
>>> + gd->timestamp = 0;
>>>}
>>>
>>>void reset_timer(void)
>>> @@ -150,7 +144,7 @@ void reset_timer(void)
>>>ulong get_timer_masked(void)
>>>{
>>> unsigned long long res = get_ticks();
>>> - do_div (res, (timer_load_val / (100 * CONFIG_SYS_HZ)));
>>> + do_div (res, (gd->timer_load_val / (100 * CONFIG_SYS_HZ)));
>>> return res;
>>>}
>>>
>>> @@ -161,7 +155,7 @@ ulong get_timer(ulong base)
>>>
>>>void set_timer(ulong t)
>>>{
>>> - timestamp = t * (timer_load_val / (100 * CONFIG_SYS_HZ));
>>> + gd->timestamp = t * (gd->timer_load_val / (100 * CONFIG_SYS_HZ));
>>>}
>>>
>>>void __udelay(unsigned long usec)
>>> diff --git a/arch/arm/include/asm/global_data.h
>>> b/arch/arm/include/asm/global_data.h
>>> index ada3fbb..69fb7b6 100644
>>> --- a/arch/arm/include/asm/global_data.h
>>> +++ b/arch/arm/include/asm/global_data.h
>>> @@ -61,6 +61,12 @@ typedef struct global_data {
>>> unsigned long tbu;
>>> unsigned long long timer_reset_value;
>>>#endif
>>> +#ifdef CONFIG_S3C64XX
>>> + /* "static data" needed by s3c64xx's timer.c */
>>> + unsigned long timer_load_val;
>>> + unsigned long lastdec;
>>> + unsigned long long timestamp;
>>> +#endif
>>> unsigned long relocaddr; /* Sta
Re: [U-Boot] [PATCH] ARM: S3C64XX: fix timer broken by relocation
Dear Minkyu Kang,
On 11/12/2010 05:10 AM, Minkyu Kang wrote:
> Dear Darius Augulis,
>
> On 2 November 2010 05:49, Darius Augulis wrote:
>> S3C64XX timer uses static variables which
>> are initialized before relocation and used after it.
>> Move them to global data structure.
>>
>> Signed-off-by: Darius Augulis
>> ---
>> arch/arm/cpu/arm1176/s3c64xx/timer.c | 36
>> ++
>> arch/arm/include/asm/global_data.h |6 ++
>> 2 files changed, 21 insertions(+), 21 deletions(-)
>>
>> diff --git a/arch/arm/cpu/arm1176/s3c64xx/timer.c
>> b/arch/arm/cpu/arm1176/s3c64xx/timer.c
>> index 9768319..4e420cb 100644
>> --- a/arch/arm/cpu/arm1176/s3c64xx/timer.c
>> +++ b/arch/arm/cpu/arm1176/s3c64xx/timer.c
>> @@ -43,7 +43,7 @@
>> #include
>> #include
>>
>> -static ulong timer_load_val;
>> +DECLARE_GLOBAL_DATA_PTR;
>>
>> #define PRESCALER 167
>>
>> @@ -60,12 +60,6 @@ static inline ulong read_timer(void)
>> return timers->TCNTO4;
>> }
>>
>> -/* Internal tick units */
>> -/* Last decremneter snapshot */
>> -static unsigned long lastdec;
>> -/* Monotonic incrementing timer */
>> -static unsigned long long timestamp;
>> -
>> int timer_init(void)
>> {
>> s3c64xx_timers *const timers = s3c64xx_get_base_timers();
>> @@ -83,20 +77,20 @@ int timer_init(void)
>> * the prescaler automatically for other PCLK frequencies.
>> */
>> timers->TCFG0 = PRESCALER<< 8;
>> - if (timer_load_val == 0) {
>> - timer_load_val = get_PCLK() / PRESCALER * (100 / 4); /* 100s
>> */
>> + if (gd->timer_load_val == 0) {
>> + gd->timer_load_val = get_PCLK() / PRESCALER * (100 / 4); /*
>> 100s */
>> timers->TCFG1 = (timers->TCFG1& ~0xf) | 0x2;
>> }
>>
>> /* load value for 10 ms timeout */
>> - lastdec = timers->TCNTB4 = timer_load_val;
>> + gd->lastdec = timers->TCNTB4 = gd->timer_load_val;
>> /* auto load, manual update of Timer 4 */
>> timers->TCON = (timers->TCON& ~0x0070) | TCON_4_AUTO |
>> TCON_4_UPDATE;
>>
>> /* auto load, start Timer 4 */
>> timers->TCON = (timers->TCON& ~0x0070) | TCON_4_AUTO |
>> COUNT_4_ON;
>> - timestamp = 0;
>> + gd->timestamp = 0;
>>
>> return 0;
>> }
>> @@ -113,16 +107,16 @@ unsigned long long get_ticks(void)
>> {
>> ulong now = read_timer();
>>
>> - if (lastdec>= now) {
>> + if (gd->lastdec>= now) {
>> /* normal mode */
>> - timestamp += lastdec - now;
>> + gd->timestamp += gd->lastdec - now;
>> } else {
>> /* we have an overflow ... */
>> - timestamp += lastdec + timer_load_val - now;
>> + gd->timestamp += gd->lastdec + gd->timer_load_val - now;
>> }
>> - lastdec = now;
>> + gd->lastdec = now;
>>
>> - return timestamp;
>> + return gd->timestamp;
>> }
>>
>> /*
>> @@ -132,14 +126,14 @@ unsigned long long get_ticks(void)
>> ulong get_tbclk(void)
>> {
>> /* We overrun in 100s */
>> - return (ulong)(timer_load_val / 100);
>> + return (ulong)(gd->timer_load_val / 100);
>> }
>>
>> void reset_timer_masked(void)
>> {
>> /* reset time */
>> - lastdec = read_timer();
>> - timestamp = 0;
>> + gd->lastdec = read_timer();
>> + gd->timestamp = 0;
>> }
>>
>> void reset_timer(void)
>> @@ -150,7 +144,7 @@ void reset_timer(void)
>> ulong get_timer_masked(void)
>> {
>> unsigned long long res = get_ticks();
>> - do_div (res, (timer_load_val / (100 * CONFIG_SYS_HZ)));
>> + do_div (res, (gd->timer_load_val / (100 * CONFIG_SYS_HZ)));
>> return res;
>> }
>>
>> @@ -161,7 +155,7 @@ ulong get_timer(ulong base)
>>
>> void set_timer(ulong t)
>> {
>> - timestamp = t * (timer_load_val / (100 * CONFIG_SYS_HZ));
>> + gd->timestamp = t * (gd->timer_load_val / (100 * CONFIG_SYS_HZ));
>> }
>>
>> void __udelay(unsigned long usec)
>> diff --git a/arch/arm/include/asm/global_data.h
>> b/arch/arm/include/asm/global_data.h
>> index ada3fbb..69fb7b6 100644
>> --- a/arch/arm/include/asm/global_data.h
>> +++ b/arch/arm/include/asm/global_data.h
>> @@ -61,6 +61,12 @@ typedef struct global_data {
>> unsigned long tbu;
>> unsigned long long timer_reset_value;
>> #endif
>> +#ifdef CONFIG_S3C64XX
>> + /* "static data" needed by s3c64xx's timer.c */
>> + unsigned long timer_load_val;
>> + unsigned long lastdec;
>> + unsigned long long timestamp;
>> +#endif
>> unsigned long relocaddr; /* Start address of U-Boot in RAM */
>> phys_size_t ram_size; /* RAM size */
>> unsigned long mon_len;/* monitor len */
>>
>
> I think it's not good way.
> We just need to fix the timer_init function.
> Because we can use t
[U-Boot] [PATCH] ARM: S3C64XX: fix clock setup
Fix pll divider values to standard ones described in "S3C6410X RISC Microprocessor User's Manual, Revision 1.20", p. 3-21. Signed-off-by: Darius Augulis --- arch/arm/include/asm/arch-s3c64xx/s3c6400.h | 17 ++--- 1 files changed, 6 insertions(+), 11 deletions(-) diff --git a/arch/arm/include/asm/arch-s3c64xx/s3c6400.h b/arch/arm/include/asm/arch-s3c64xx/s3c6400.h index 10b3324..a197b4e 100644 --- a/arch/arm/include/asm/arch-s3c64xx/s3c6400.h +++ b/arch/arm/include/asm/arch-s3c64xx/s3c6400.h @@ -762,24 +762,19 @@ #define TIMER3_ON (TCON_3_ONOFF * 1) #define TIMER3_OFF (FClrBit(TCON, TCON_3_ONOFF)) -#if defined(CONFIG_CLK_400_100_50) +#if defined(CONFIG_CLK_400_133_66) #define STARTUP_AMDIV 400 #define STARTUP_MDIV 400 -#define STARTUP_PDIV 6 -#define STARTUP_SDIV 1 -#elif defined(CONFIG_CLK_400_133_66) -#define STARTUP_AMDIV 400 -#define STARTUP_MDIV 533 -#define STARTUP_PDIV 6 -#define STARTUP_SDIV 1 +#define STARTUP_PDIV 3 +#define STARTUP_SDIV 2 #elif defined(CONFIG_CLK_533_133_66) #define STARTUP_AMDIV 533 -#define STARTUP_MDIV 533 -#define STARTUP_PDIV 6 +#define STARTUP_MDIV 266 +#define STARTUP_PDIV 3 #define STARTUP_SDIV 1 #elif defined(CONFIG_CLK_667_133_66) #define STARTUP_AMDIV 667 -#define STARTUP_MDIV 533 +#define STARTUP_MDIV 333 #define STARTUP_PDIV 6 #define STARTUP_SDIV 1 #endif ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: e1000: Add initialized eth_device & e1000_hw structure
On Fri, Nov 12, 2010 at 5:13 AM, Kumar Gala wrote:
> nic and hw structures are allocated via malloc i.e. return memory
> is not zero initialized. Because of this few structure member like
> "function pointers" are initialized with garbage values.
>
> It may cause problem. for eg. during eth_initialize, dev->write_hwaddr
> is used.
>
> Signed-off-by: Kumar Gala
> ---
> drivers/net/e1000.c | 14 ++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
> index 2825342..911eb2c 100644
> --- a/drivers/net/e1000.c
> +++ b/drivers/net/e1000.c
> @@ -5177,7 +5177,21 @@ e1000_initialize(bd_t * bis)
> }
>
> nic = (struct eth_device *) malloc(sizeof (*nic));
> + if (!nic) {
> + printf("Error: e1000 - Can not alloc memory\n");
> + return 0;
> + }
> +
> hw = (struct e1000_hw *) malloc(sizeof (*hw));
> + if (!nic) {
Copy and paste error, I think you want "if (!hw)"
Paul.
> + free(nic);
> + printf("Error: e1000 - Can not alloc memory\n");
> + return 0;
> + }
> +
> + memset(nic, 0, sizeof(*dev));
> + memset(hw, 0, sizeof(*hw));
> +
> hw->pdev = devno;
> nic->priv = hw;
>
> --
> 1.7.2.3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
On Fri, 12 Nov 2010 11:22:31 +0100 Wolfgang Denk wrote: > - General: > -- > > Several times before it has been suggested to use Patchwork for > U-Boot; in the past, I hesitated to do that for various reasons. But > in the meantime a number of features have been added to Patchwork, > and I think it now can be indeed beneficial to our workflow. > > I'm happy to announce that we now have U-Boot registered as project: > > http://patchwork.ozlabs.org/project/uboot/list/ > > The setup has just been activated; I will try to arrange to have > some more history added, but I don;t want to promise that this will > work, or when this will happen. > > > For now, I would like to ask all CUSTODIANS to register as users at > patchwork.ozlabs.org, so we can arrange that the appropriate > privileges will be granted to you. Registered as scottwood -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] da850: Enable SPI Flash
On Fri, Nov 12, 2010 at 11:38 AM, Stefano Babic wrote: > The patch was already posted to the arago project, > but not yet to mainline, with the following message: > > da850: Enable SPI in configuration file > > It allows to save environment into the spi flash. > Tested on LogiPD tmdxl138 board. > > Signed-off-by: Sudhakar Rajashekhara > Signed-off-by: Stefano Babic > CC: Detlev Zundev > Tested-by: Ben Gardiner > --- > Changed since V1: > - commit message contains original message from Arago project > (Detlev Zundev) > - protect SPI definitions with #CONFIG_USE_SPIFLASH > (Ben Gardiner) Thanks, Stefano. This version is still good for me. Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
On Fri, 12 Nov 2010 09:58:53 -0600 Kumar Gala wrote: > > On Nov 4, 2010, at 11:47 AM, Wood Scott-B07421 wrote: > > > Joakim Tjernlund wrote: > >> Trial and error suggests that map_flash_by_law1 needs > >> an isync(padding with 4 nop's also did the trick) > >> after updating LBLAWAR1 to make sure the the change has > >> reached the HW before continuing with the code that depends on it. > >> Add an isync to remap_flash_by_law0 for good measure too. > > > > To be totally safe, we probably want to do a readback plus twi (to turn a > > data dependency into a flow dependency) before the isync. > > We only do the 'twi' for loads/in_beX not stores/out_beX. Yes, and the readback is a load. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hanging in kmalloc of nand_scan_tail() function
On Fri, 12 Nov 2010 20:45:18 +0800
terry wrote:
> Dear Scott,
> I have disassemble the nand_base.o file,because i know the problem
> happened here.
Why not disassemble the whole u-boot?
Then you'll get malloc as well, and the addresses will be closer to
what shows up in the dump.
> Do you think it's useful for your analysis?
Can you disassemble malloc? That's where it actually crashed.
> 1a4c :
> 1749 1a4c: e92d4070push{r4, r5, r6, lr}
> 1750 1a50: e590509cldr r5, [r0, #156]
> 1751 1a54: e595304cldr r3, [r5, #76]
> 1752 1a58: e3130701tst r3, #262144 ; 0x4
> 1753 1a5c: e1a06000mov r6, r0
> 1754 1a60: 1a02bne 1a70
> 1755 1a64: e59f04ecldr r0, [pc, #1260] ; 1f58 +0x50c>
> 1756 1a68: ebfebl 0
What's the value at PC+1260?
> by the way,I cann't find the prototype of malloc in the whole project,it
> seems that it is encapsulated in some libs.
It's in common/malloc.c. There's weird preprocessor renaming going on,
so it's called mALLOc in that file, but it shows up as malloc in the
binary.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/2] da850: Enable SPI Flash
The patch was already posted to the arago project,
but not yet to mainline, with the following message:
da850: Enable SPI in configuration file
It allows to save environment into the spi flash.
Tested on LogiPD tmdxl138 board.
Signed-off-by: Sudhakar Rajashekhara
Signed-off-by: Stefano Babic
CC: Detlev Zundev
Tested-by: Ben Gardiner
---
Changed since V1:
- commit message contains original message from Arago project
(Detlev Zundev)
- protect SPI definitions with #CONFIG_USE_SPIFLASH
(Ben Gardiner)
arch/arm/include/asm/arch-davinci/hardware.h | 12 +-
include/configs/da850evm.h | 30 ++
2 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h
b/arch/arm/include/asm/arch-davinci/hardware.h
index 2a460b5..21b2076 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -133,7 +133,8 @@ typedef volatile unsigned int * dv_reg_p;
#define DAVINCI_PSC1_BASE 0x01e27000
#define DAVINCI_SPI0_BASE 0x01c41000
#define DAVINCI_USB_OTG_BASE 0x01e0
-#define DAVINCI_SPI1_BASE 0x01e12000
+#define DAVINCI_SPI1_BASE (cpu_is_da830() ? \
+ 0x01e12000 : 0x01f0e000)
#define DAVINCI_GPIO_BASE 0x01e26000
#define DAVINCI_EMAC_CNTRL_REGS_BASE 0x01e23000
#define DAVINCI_EMAC_WRAPPER_CNTRL_REGS_BASE 0x01e22000
@@ -364,6 +365,9 @@ struct davinci_pllc_regs {
#define davinci_pllc_regs ((struct davinci_pllc_regs *)DAVINCI_PLL_CNTRL0_BASE)
#define DAVINCI_PLLC_DIV_MASK 0x1f
+#define ASYNC3 get_async3_src()
+#define PLL1_SYSCLK2 ((1 << 16) | 0x2)
+#define DAVINCI_SPI1_CLKID (cpu_is_da830() ? 2 : ASYNC3)
/* Clock IDs */
enum davinci_clk_ids {
DAVINCI_SPI0_CLKID = 2,
@@ -458,6 +462,12 @@ static inline int cpu_is_da850(void)
return ((part_no == 0xb7d1) ? 1 : 0);
}
+static inline int get_async3_src(void)
+{
+ return (REG(&davinci_syscfg_regs->cfgchip3) & 0x10) ?
+ PLL1_SYSCLK2 : 2;
+}
+
#endif /* CONFIG_SOC_DA8XX */
#endif /* __ASM_ARCH_HARDWARE_H */
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 7b04be0..80cae34 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -27,6 +27,7 @@
* Board
*/
#define CONFIG_DRIVER_TI_EMAC
+#define CONFIG_USE_SPIFLASH
/*
* SoC Configuration
@@ -71,6 +72,17 @@
#define CONFIG_BAUDRATE115200 /* Default baud rate */
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
+#ifdef CONFIG_USE_SPIFLASH
+#define CONFIG_SPI
+#define CONFIG_SPI_FLASH
+#define CONFIG_SPI_FLASH_STMICRO
+#define CONFIG_DAVINCI_SPI
+#define CONFIG_SYS_SPI_BASEDAVINCI_SPI1_BASE
+#define CONFIG_SYS_SPI_CLK clk_get(DAVINCI_SPI1_CLKID)
+#define CONFIG_SF_DEFAULT_SPEED3000
+#define CONFIG_ENV_SPI_MAX_HZ CONFIG_SF_DEFAULT_SPEED
+#endif
+
/*
* I2C Configuration
*/
@@ -116,6 +128,16 @@
#define CONFIG_NET_MULTI
#endif
+#ifdef CONFIG_USE_SPIFLASH
+#undef CONFIG_ENV_IS_IN_FLASH
+#undef CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_IS_IN_SPI_FLASH
+#define CONFIG_ENV_SIZE(64 << 10)
+#define CONFIG_ENV_OFFSET (256 << 10)
+#define CONFIG_ENV_SECT_SIZE (64 << 10)
+#define CONFIG_SYS_NO_FLASH
+#endif
+
/*
* U-Boot general configuration
*/
@@ -179,6 +201,14 @@
#define CONFIG_CMD_UBIFS
#endif
+#ifdef CONFIG_USE_SPIFLASH
+#undef CONFIG_CMD_IMLS
+#undef CONFIG_CMD_FLASH
+#define CONFIG_CMD_SPI
+#define CONFIG_CMD_SF
+#define CONFIG_CMD_SAVEENV
+#endif
+
#if !defined(CONFIG_USE_NAND) && \
!defined(CONFIG_USE_NOR) && \
!defined(CONFIG_USE_SPIFLASH)
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
Kumar Gala wrote on 2010/11/12 16:58:48: > > > On Nov 4, 2010, at 9:45 AM, Joakim Tjernlund wrote: > > > After the removal of COLD/WARM start flags my mpc8321 > > board didn't boot anymore. > > Trial and error suggests that map_flash_by_law1 needs > > an isync(padding with 4 nop's also did the trick) > > after updating LBLAWAR1 to make sure the the change has > > reached the HW before continuing with the code that depends on it. > > Add an isync to remap_flash_by_law0 for good measure too. > > > > Signed-off-by: Joakim Tjernlund > > --- > > arch/powerpc/cpu/mpc83xx/start.S |2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/arch/powerpc/cpu/mpc83xx/start.S > > b/arch/powerpc/cpu/mpc83xx/start.S > > index e8b1ebc..d3ec580 100644 > > --- a/arch/powerpc/cpu/mpc83xx/start.S > > +++ b/arch/powerpc/cpu/mpc83xx/start.S > > @@ -1191,6 +1191,7 @@ map_flash_by_law1: > >bne 1b > > > >stw r4, LBLAWAR1(r3) /* LBLAWAR1 <= 8MB Flash Size */ > > I think what you want is: >lwz r4, LBLAWAR1(r3) > > > + isync /* Wait for HW to catch up */ > > I dont think this is needed (unless the manual says otherwise about updates > to *LAWAR* I can confirm that replacing isync with lwz r4, LBLAWAR1(r3) also works. I really don't know this stuff well so I hope you can sort this out. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git (updated)
On Nov 12, 2010, at 9:55 AM, Timur Tabi wrote: > On Fri, Nov 12, 2010 at 9:49 AM, Kumar Gala wrote: > >> powerpc/8xxx: Enable e1000 driver on some FSL boards > > I have an objection to this patch that I asked you about earlier, and > you never answered my question. I'm enabling it so we can use e1000 cards to test PCI. I hear your objection and overrule it as maintainer. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
On Nov 4, 2010, at 11:47 AM, Wood Scott-B07421 wrote: > Joakim Tjernlund wrote: >> Trial and error suggests that map_flash_by_law1 needs >> an isync(padding with 4 nop's also did the trick) >> after updating LBLAWAR1 to make sure the the change has >> reached the HW before continuing with the code that depends on it. >> Add an isync to remap_flash_by_law0 for good measure too. > > To be totally safe, we probably want to do a readback plus twi (to turn a > data dependency into a flow dependency) before the isync. We only do the 'twi' for loads/in_beX not stores/out_beX. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
On Nov 4, 2010, at 9:45 AM, Joakim Tjernlund wrote: > After the removal of COLD/WARM start flags my mpc8321 > board didn't boot anymore. > Trial and error suggests that map_flash_by_law1 needs > an isync(padding with 4 nop's also did the trick) > after updating LBLAWAR1 to make sure the the change has > reached the HW before continuing with the code that depends on it. > Add an isync to remap_flash_by_law0 for good measure too. > > Signed-off-by: Joakim Tjernlund > --- > arch/powerpc/cpu/mpc83xx/start.S |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/powerpc/cpu/mpc83xx/start.S > b/arch/powerpc/cpu/mpc83xx/start.S > index e8b1ebc..d3ec580 100644 > --- a/arch/powerpc/cpu/mpc83xx/start.S > +++ b/arch/powerpc/cpu/mpc83xx/start.S > @@ -1191,6 +1191,7 @@ map_flash_by_law1: > bne 1b > > stw r4, LBLAWAR1(r3) /* LBLAWAR1 <= 8MB Flash Size */ I think what you want is: lwz r4, LBLAWAR1(r3) > + isync /* Wait for HW to catch up */ I dont think this is needed (unless the manual says otherwise about updates to *LAWAR* > blr > > /* Though all the LBIU Local Access Windows and LBC Banks will be > @@ -1229,5 +1230,6 @@ remap_flash_by_law0: > xor r4, r4, r4 > stw r4, LBLAWBAR1(r3) > stw r4, LBLAWAR1(r3) /* Off LBIU LAW1 */ > + isync /* Wait for HW to catch up */ same here. > blr > #endif /* CONFIG_SYS_FLASHBOOT */ > -- > 1.7.2.2 > > ___ > 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] Please pull u-boot-mpc85xx.git (updated)
On Fri, Nov 12, 2010 at 9:49 AM, Kumar Gala wrote: > powerpc/8xxx: Enable e1000 driver on some FSL boards I have an objection to this patch that I asked you about earlier, and you never answered my question. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx.git (updated)
The following changes since commit 0c0892be0d93a5a892b93739c5eb3bf692fed4ff: Merge branch 'master' of git://git.denx.de/u-boot-marvell (2010-10-29 22:03:00 +0200) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx master Becky Bruce (1): TQM85xx: Fix bug introduced by 83xx/85xx/86xx: LBC register cleanup Haiying Wang (3): powerpc/85xx: Fix lds for nand build powerpc/85xx: rename CONFIG_SYS_TEXT_BASE to CONFIG_SYS_MONITOR_BASE powerpc/85xx: add CONFIG_SYS_TEXT_BASE_SPL for 85xx nand spl build Kumar Gala (5): powerpc/8xxx: Fix merge issue with P2020DS DDR2 build config powerpc/8xxx: Enable e1000 driver on some FSL boards powerpc/corenet_ds: Enable DHCP suport powerpc/corenet_ds: Move CONFIG_SYS_TEXT_BASE into corenet_ds.h powerpc/p4080ds: Move ICS refclk define into P4080DS.h Priyanka Jain (1): p1_p2_rdb: to set SQW/INT pin of RTC as INT line Timur Tabi (1): powerpc/corenet_ds: display the RCW at boot arch/powerpc/cpu/mpc85xx/start.S | 18 +- arch/powerpc/cpu/mpc85xx/u-boot-nand.lds | 49 +- arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds | 12 +++--- board/freescale/corenet_ds/corenet_ds.c | 15 board/freescale/p1_p2_rdb/p1_p2_rdb.c|4 ++- board/tqc/tqm85xx/tqm85xx.c |2 +- boards.cfg |2 +- include/configs/MPC8536DS.h | 11 +- include/configs/MPC8569MDS.h | 12 +- include/configs/MPC8572DS.h |1 + include/configs/P1022DS.h|1 + include/configs/P1_P2_RDB.h | 14 ++-- include/configs/P4080DS.h|6 +-- include/configs/corenet_ds.h |6 +++- nand_spl/board/freescale/mpc8536ds/Makefile |4 +- nand_spl/board/freescale/mpc8569mds/Makefile |4 +- nand_spl/board/freescale/p1_p2_rdb/Makefile |4 +- 17 files changed, 89 insertions(+), 76 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/corenet_ds: display the RCW at boot
On Nov 11, 2010, at 2:23 AM, Kumar Gala wrote: > From: Timur Tabi > > Display the 64-byte Reset Configuration Word (RCW) during boot, so that > there's > no confusion as to what RCW U-boot is using. > > Reset Configuration Word (RCW): > : 4a50 18181818 > 0010: 28402400 2000 fe80 0120 > 0020: 000b > 0030: > > Signed-off-by: Timur Tabi > Signed-off-by: Roy Zang > Signed-off-by: Kumar Gala > --- > board/freescale/corenet_ds/corenet_ds.c | 15 +++ > 1 files changed, 15 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/corenet_ds: Move CONFIG_SYS_TEXT_BASE into corenet_ds.h
On Nov 11, 2010, at 1:44 AM, Kumar Gala wrote: > CONFIG_SYS_TEXT_BASE setting is common across the 'corenet_ds' board > family so move it out of P4080DS.h and into corenet_ds.h > > Signed-off-by: Kumar Gala > --- > include/configs/P4080DS.h|4 > include/configs/corenet_ds.h |4 > 2 files changed, 4 insertions(+), 4 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/corenet_ds: Enable DHCP suport
On Nov 11, 2010, at 1:40 AM, Kumar Gala wrote: > Signed-off-by: Kumar Gala > --- > include/configs/corenet_ds.h |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/p4080ds: Move ICS refclk define into P4080DS.h
On Nov 11, 2010, at 1:44 AM, Kumar Gala wrote: > We appear to have different refclk's on the different corenet DS boards > so move the define out of the common header. > > Signed-off-by: Kumar Gala > --- > include/configs/P4080DS.h|2 ++ > include/configs/corenet_ds.h |1 - > 2 files changed, 2 insertions(+), 1 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v0]p1_p2_rdb: to set SQW/INT pin of RTC as INT line
On Nov 11, 2010, at 6:20 AM, Kumar Gala wrote: > > On Oct 25, 2010, at 4:22 AM, Priyanka Jain wrote: > >> p1_p2_rdb : SQW/INT pin in RTC can be used for >> generating square wave(by default) or as interrupt line. >> U-boot is registering this pin for interrupts. >> Configuring SQW/INT bit as interrupt line during board initialization >> to avoid spurious interrupts generated by square wave. >> >> Signed-off-by: Priyanka Jain >> --- >> board/freescale/p1_p2_rdb/p1_p2_rdb.c |1 + >> include/configs/P1_P2_RDB.h |1 + >> 2 files changed, 2 insertions(+), 0 deletions(-) > > applied to 85xx Added #include that was missing and thus we got compiler warnings. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
> > > > > Timur Tabi wrote: > > > Wood Scott-B07421 wrote: > > > > To be totally safe, we probably want to do a readback plus twi (to turn > > > > a data dependency into a flow dependency) before the isync. > > > > > > twi == trap word immediate? > > > > Yes. > > > > > If so, I don't see how that will turn a data dependency into a flow > > > dependency. > > > Is that some sort of side effect of twi? > > > > It decides based on the input register (data dependency) whether to cause a > > trap (flow dependency). We never want it to actually trap, so we set a > > condition that says never trap, but the dependency is still there -- the > > hardware doesn't decode it as a no-op. > > > > See arch/powerpc/include/asm/io.h, it's used in the I/O read accessors. > > Guys, unless you will do the twi stuff now I suggest you ACK this > patch so 83xx works again. Ping? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
On Friday 12 November 2010 11:22:31 Wolfgang Denk wrote: > Hi all, [SNIP] > For now, I would like to ask all CUSTODIANS to register as users at > patchwork.ozlabs.org, so we can arrange that the appropriate > privileges will be granted to you. > Registered as "marex" Cheers ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
On 11/12/2010 02:32 PM, Scott McNutt wrote: > Wolfgang Denk wrote: >> For now, I would like to ask all CUSTODIANS to register as users at >> patchwork.ozlabs.org, so we can arrange that the appropriate >> privileges will be granted to you. > Registered as "sbabic" Best 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] [RFC] Add 'led' command
Mike,
Thanks for the feedback (ack to all of it). I didn't fix-up the style
from the original patch given that I figured there'd be enough
comments to deal with regarding the overall architecture of it, but it
seems there is a need for such a generic command and this really is
the easiest way to move along the process of getting something. It
isn't like this is the calling of my career to fix the LED command,
but I need it and maybe I can provide some better ideas along the way
without this taking an eternity...
On Tue, Nov 9, 2010 at 8:52 AM, Mike Frysinger wrote:
> On Friday, November 05, 2010 01:50:36 Jason Kridner wrote:
>> +int do_led ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[] )
>
> much of the style of this code is broken. and i cant imagine this code
> compiling warning free with current master.
>
> no spaces around the paren, and the argv has been constified.
>
> also, this should be marked static
>
>> + if ((argc != 3)){
>
> space before the brace and useless set of paren here
>
>> + printf("Usage:\n%s\n", cmdtp->usage);
>> + return 1;
>
> return cmd_usage(cmdtp);
>
>> + if (strcmp(argv[2], "off") == 0) {
>> + state = 0;
>> + } else if (strcmp(argv[2], "on") == 0) {
>> + state = 1;
>
> i could have sworn we had a helper somewhere to handle "boolean strings" ...
common/cmd_cache.c has an internal on_off function. All other places
seem to do individual strcmp. Let me know if you find such a helper.
Is there value to putting this in a function like the one in
cmd_cache.c?
static int on_off (const char *s)
{
if (strcmp(s, "on") == 0) {
return (1);
} else if (strcmp(s, "off") == 0) {
return (0);
}
return (-1);
}
>
>> + printf ("Usage:\n%s\n", cmdtp->usage);
>> + return 1;
>
> return cmd_usage(cmdtp);
>
>> +#if defined(STATUS_LED_BIT) && defined(CONFIG_BOARD_SPECIFIC_LED)
>> + if (strcmp(argv[1], "0") == 0) {
>> + mask = STATUS_LED_BIT;
>> + __led_set(mask, state);
>> + }
>> + else
>> +#endif
>> +#if defined(STATUS_LED_BIT1) && defined(CONFIG_BOARD_SPECIFIC_LED)
>> + if (strcmp(argv[1], "1") == 0) {
>> + mask = STATUS_LED_BIT1;
>> + __led_set(mask, state);
>> + }
>> + else
>> +#endif
>> +#if defined(STATUS_LED_BIT2) && defined(CONFIG_BOARD_SPECIFIC_LED)
>> + if (strcmp(argv[1], "2") == 0) {
>> + mask = STATUS_LED_BIT2;
>> + __led_set(mask, state);
>> + }
>> + else
>> +#endif
>> +#if defined(STATUS_LED_BIT3) && defined(CONFIG_BOARD_SPECIFIC_LED)
>> + if (strcmp(argv[1], "3") == 0) {
>> + mask = STATUS_LED_BIT3;
>> + __led_set(mask, state);
>> + }
>> + else
>> +#endif
>
> i dont know why you need the mask variable here at all
It is an ugly hack at avoiding definition of the bit pattern to be
passed into __led_set(), to keep that function lean as defined by the
platform. I think a more practical approach would be to define an
led_set(led_no, state) function that only ever set the state of a
single LED at a time (with LEDs having an integral state, in case they
want to encode color or brightness in the integer) and then to create
query functions:
int led_get_state(led_no) - to return the current LED state
const char * led_get_description(led_no) - to return the pointer to
a constant character string that could be used in prompts and a looped
strcmp <--- or maybe just have a single constant string with a known
separator, |, that can be reused in the usage output.
int led_last_no() - to return the index number of the last LED on
the board (I could stand to have it be a LED_LAST_NO definition)
In the led command, "on" would always be the value 1 and 0 would
always be off, but passing an integer would be fine. I'm sure most
implementations will simply be a GPIO, but I can imagine someone using
the command to adjust the state of a back-light.
I'm sure a better scheme could be dreamed, but that is my simple
attempt with a minimal set of functions. I think such a change would
require some good cooperation with many maintainers to make sure I'm
not breaking their systems.
>
> also, these #ifdef trees scream for some sort of unification
It impacts performance, but what do you think if I just put them into
a data structure and loop, like what I'm suggesting above with my
functions?
It would be possible to simply create something like
const char * char my_leds = "red|yellow|green|top|bottom|backlight";
For legacy purposes, in status_led.h I could have something like I've
done for the usage command today and create a "generic" driver using
the existing function definitions (blue_LED_*, red_LED_*, etc.). It
would mean that a structure of ifdefs would still be there, but that
most implementors wouldn't need to use them and I'd replace this
particular set of ifdefs with a for loop that incremente
[U-Boot] Reply Back
ATM Card Number(5438400123456789) Of $6.8MILLIONUSD has been accredited in your favor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TQM85xx: Fix bug introduced by 83xx/85xx/86xx: LBC register cleanup
On Nov 11, 2010, at 11:33 AM, Becky Bruce wrote: > The size of the other bank needed to be added to the br0 setting; > this got dropped in the LBC cleanup. > > Signed-off-by: Becky Bruce > --- > This has been neither built or tested, as TQM8555 doesn't seem to build on the > head of this tree, and I don't have a board to test on. > > board/tqc/tqm85xx/tqm85xx.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
Hi Wolfgang, [...] > For now, I would like to ask all CUSTODIANS to register as users at > patchwork.ozlabs.org, so we can arrange that the appropriate > privileges will be granted to you. Registered as - surprise, surprise - dzu. Cheers Detlev -- The belief in a supernatural source of evil is not necessary; men alone are quite capable of every wickedness. -- Joseph Conrad -- 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] Custodian changes, using Patchwork
Wolfgang Denk wrote: > For now, I would like to ask all CUSTODIANS to register as users at > patchwork.ozlabs.org, so we can arrange that the appropriate > privileges will be granted to you. Registered as "smcnutt" Regards, --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
> > For now, I would like to ask all CUSTODIANS to register as users at > patchwork.ozlabs.org, so we can arrange that the appropriate > privileges will be granted to you. I've registered as user "monstr". Best regards, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
Hello Wolfgang, On Fri, 12 Nov 2010 11:22:31 +0100 Wolfgang Denk wrote: ... > For now, I would like to ask all CUSTODIANS to register as users at > patchwork.ozlabs.org, so we can arrange that the appropriate > privileges will be granted to you. I've registered as user "ag". Best regards, Anatolij -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zlib: updated to v.1.2.3
This is the developer's reply. -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Friday, November 12, 2010 2:17 PM To: Asokan, Shyama Trikkadeeri Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] zlib: updated to v.1.2.3 Dear "Asokan, Shyama Trikkadeeri", In message <575ed9d63b7e244bbb3786a299acbba08e7...@ie10ev813.global.ds.honeywell.co m> you wrote: > > As you had suggested I tried build u-boot with one of the 2010.09v. But > I observe the same failures in them. The configuration step of u-boot > for the boards works fine but the cross-compiling shows the same crc32 > error. > > $ make at91sam9263ek_config > Configuring for at91sam9263ek board... > > $ make CROSS_COMPILE=arm-linux- I cannot reproduce that problem here: -> git checkout v2010.09 -> ./MAKEALL at91sam9263ek Configuring for at91sam9263ek board... atmel_dataflash_spi.c:25:2: warning: #warning Please update to use C structur SoC access ! atmel_usart.c:21:2: warning: #warning Please update to use C structur SoC access ! textdata bss dec hex filename 189494 34359 268312 492165 78285 ./u-boot - SUMMARY Boards compiled: 1 Boards with warnings or errors: 1 ( at91sam9263ek ) -- Maybe you have old cruft laying around from previous builds? Make sure to run "make mrproper" before the "make at91sam9263ek_config" Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What is mind? No matter. What is matter? Never mind. -- Thomas Hewitt Key, 1799-1875 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
Hello Wolfgang, Wolfgang Denk wrote: [...] > For now, I would like to ask all CUSTODIANS to register as users at > patchwork.ozlabs.org, so we can arrange that the appropriate > privileges will be granted to you. registered as user: hs bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hanging in kmalloc of nand_scan_tail() function
Dear Scott,
I have disassemble the nand_base.o file,because i know the problem
happened here. Do you think it's useful for your analysis?
1a4c :
1749 1a4c: e92d4070push{r4, r5, r6, lr}
1750 1a50: e590509cldr r5, [r0, #156]
1751 1a54: e595304cldr r3, [r5, #76]
1752 1a58: e3130701tst r3, #262144 ; 0x4
1753 1a5c: e1a06000mov r6, r0
1754 1a60: 1a02bne 1a70
1755 1a64: e59f04ecldr r0, [pc, #1260] ; 1f58
1756 1a68: ebfebl 0
1757 1a6c: e58500dcstr r0, [r5, #220]
1758 1a70: e59510dcldr r1, [r5, #220]
1759 1a74: e351cmp r1, #0 ; 0x0
1760 1a78: 03ebmvneq r0, #11 ; 0xb
1761 1a7c: 08bd8070popeq {r4, r5, r6, pc}
1762 1a80: e5963014ldr r3, [r6, #20]
1763 1a84: e59520b0ldr r2, [r5, #176]
1764 1a88: e0813003add r3, r1, r3
by the way,I cann't find the prototype of malloc in the whole project,it
seems that it is encapsulated in some libs.
--
Best regards,
Terry.
在 2010-11-11四的 13:49 -0600，Scott Wood写道：
> On Thu, 11 Nov 2010 23:06:01 +0800
> terry wrote:
>
> > Dear everyone,
> > I'm using u-boot-2010.09. After I download u-boot.bin to my boards(cpu
> > is s3c2410),the output from serial shows that cpu has exception, the
> > information list as following:
> > U-Boot 2010.09 (Nov 11 2010 - 21:55:07)
> >
> > U-Boot code: 33F8 -> 33FA0BDC BSS: -> 33FA45EC
> > RAM Configuration:
> > Bank #0: 3000 64 MiB
> > NAND: data abort
> > pc : [<33f8fbb4>] lr : [<33f85f70>]
> > sp : 33f07fac ip : fp :
> > r10: 1298 r9 : ff7f r8 : 33f4ffe0
> > r7 : r6 : 33fa3b50 r5 : 33fa3c00 r4 : 33fa0274
> > r3 : 33f9ff54 r2 : 0064 r1 : 0001 r0 : cc33cc33
> > Flags: NzCv IRQs off FIQs off Mode SVC_32
> > Resetting CPU ...
> >
> > value of pc locate at function, value of lr locate at
> > (/drivers/mtd/nand/nand_base.c).
>
> Could you look up the specific line numbers of
> 0x33f8fbb4 and 0x33f85f6c, and show a few lines of disassembly around
> those addresses?
>
> -Scott
>
--
Best regards,
terry
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
Dear Michal Simek, In message <4cdd20ee.2040...@monstr.eu> you wrote: > > > - Network: > > -- > > > > Ben Warren has informed me that he has to give up Network > > custodianship. > > Thanks for your work. Thanks for that! Indeed Ben: many thanks for all the work you've done in the past, and sincere apologies that I forgot this in my initial mail. 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 Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
> - General: > -- > > Several times before it has been suggested to use Patchwork for > U-Boot; in the past, I hesitated to do that for various reasons. But > in the meantime a number of features have been added to Patchwork, > and I think it now can be indeed beneficial to our workflow. > > I'm happy to announce that we now have U-Boot registered as project: > > http://patchwork.ozlabs.org/project/uboot/list/ > > The setup has just been activated; I will try to arrange to have > some more history added, but I don;t want to promise that this will > work, or when this will happen. > > > For now, I would like to ask all CUSTODIANS to register as users at > patchwork.ozlabs.org, so we can arrange that the appropriate > privileges will be granted to you. > > > Kumar - you already had a Patchwork user ID, so you don't have to do > this again. Yeah!! now I can use the same tool for all my work :) - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
Dear Wolfgang, > For now, I would like to ask all CUSTODIANS to register as users at > patchwork.ozlabs.org, so we can arrange that the appropriate > privileges will be granted to you. --> reinhardm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
Hi Wolfgang, On Friday 12 November 2010 11:22:31 Wolfgang Denk wrote: > For now, I would like to ask all CUSTODIANS to register as users at > patchwork.ozlabs.org, so we can arrange that the appropriate > privileges will be granted to you. I've registered as user "stroese". Thanks. Cheers, Stefan -- 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] [STATUS] Custodian changes, using Patchwork
Le 12/11/2010 11:22, Wolfgang Denk a écrit : > - ARM: > -- > >I have tried my best to stand in for Tom Rix as ARM custodian, but >both my time and my experience with this architecture is way too >limited to do this job well. Fortunaltey Albert Aribaud has agreed >to take over this job, starting after the release of v2010.12. > >So welcome aboard, Albert. Thanks. >For now, I would like to ask all CUSTODIANS to register as users at >patchwork.ozlabs.org, so we can arrange that the appropriate >privileges will be granted to you. I have registered as user aaribaud. > Best regards, > > Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] PBL: add support for boot from SPI flash.
> -Original Message- > From: Gala Kumar-B11780 > Sent: Friday, November 12, 2010 17:50 PM > To: Xie Shaohui-B21989 > Cc: u-boot@lists.denx.de; Zang Roy-R61911; Lan Chunhe-B25806; Hu Mingkai- > B21284 > Subject: Re: [PATCH 1/2] PBL: add support for boot from SPI flash. > > > On Nov 12, 2010, at 12:36 AM, Shaohui Xie wrote: > > > PBL: SPI flash used as RCW and PBI source, CPC1 used as 1M SRAM > > where PBL will copy whole U-BOOT image to, U-boot can boot from CPC1 > > after PBL completes RCW and PBI phases. > > > > To produces the U-boot image which can used by PBL, pbl_image_tool.html > > is a necessary tool. > > (drop this bit about pbl_image_tool.html, I assume this is the RCW tool??) > > > > > Signed-off-by: Chunhe Lan > > Signed-off-by: Mingkai Hu > > Signed-off-by: Shaohui Xie > > --- > > arch/powerpc/cpu/mpc85xx/cpu_init.c | 25 + > > board/freescale/corenet_ds/config.mk | 6 ++ > > board/freescale/corenet_ds/tlb.c |9 + > > boards.cfg |1 + > > include/configs/corenet_ds.h | 31 +-- > > 5 files changed, 70 insertions(+), 2 deletions(-) > > Let's use CONFIG_SPIFLASH like we do on all other boards instead of > CONFIG_PBLSPI This patch is for PBL boot and is not dedicated to SPI. SD/MMC boot can also use it. CONFIG_SPIFLASH can't reflect the boot information. How about CONFIG_PBL_BOOT? Thanks. Roy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] PBL: add support for boot from SPI flash.
On Nov 12, 2010, at 5:12 AM, Zang Roy-R61911 wrote: > > >> -Original Message- >> From: Gala Kumar-B11780 >> Sent: Friday, November 12, 2010 17:50 PM >> To: Xie Shaohui-B21989 >> Cc: u-boot@lists.denx.de; Zang Roy-R61911; Lan Chunhe-B25806; Hu > Mingkai- >> B21284 >> Subject: Re: [PATCH 1/2] PBL: add support for boot from SPI flash. >> >> >> On Nov 12, 2010, at 12:36 AM, Shaohui Xie wrote: >> >>> PBL: SPI flash used as RCW and PBI source, CPC1 used as 1M SRAM >>> where PBL will copy whole U-BOOT image to, U-boot can boot from CPC1 >>> after PBL completes RCW and PBI phases. >>> >>> To produces the U-boot image which can used by PBL, > pbl_image_tool.html >>> is a necessary tool. >> >> (drop this bit about pbl_image_tool.html, I assume this is the RCW > tool??) >> >>> >>> Signed-off-by: Chunhe Lan >>> Signed-off-by: Mingkai Hu >>> Signed-off-by: Shaohui Xie >>> --- >>> arch/powerpc/cpu/mpc85xx/cpu_init.c | 25 > + >>> board/freescale/corenet_ds/config.mk | 6 ++ >>> board/freescale/corenet_ds/tlb.c |9 + >>> boards.cfg |1 + >>> include/configs/corenet_ds.h | 31 > +-- >>> 5 files changed, 70 insertions(+), 2 deletions(-) >> >> Let's use CONFIG_SPIFLASH like we do on all other boards instead of >> CONFIG_PBLSPI > > This patch is for PBL boot and is not dedicated to SPI. SD/MMC boot can > also use it. in theory NAND as well? > CONFIG_SPIFLASH can't reflect the boot information. > How about CONFIG_PBL_BOOT? hmm, that's better but not quite right. Since we use PBL even on NOR boot. Maybe something like CONFIG_PBL_BOOT_INDIRECT?? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
> - Network: > -- > > Ben Warren has informed me that he has to give up Network > custodianship. Thanks for your work. Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Commit ecee9... (Program net device MAC addresses after initializing) breakage
On 10/11/10 14:36, Mike Frysinger wrote: > On Saturday, November 06, 2010 18:13:08 Graeme Russ wrote: >> I saw discussion a little while ago regarding implementing a version of >> malloc that returns cleared memory - did this gain any traction? > > i dont think anyone posted a patch. it would make sense though to generalize > the zalloc() code since some places are already doing it. Actually, I think we should be using calloc() more than we are Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] Custodian changes, using Patchwork
Hi all, here is some news about organizational changes: - ColdFire: --- Liew Tsi Chun has announced that he has to give up ColdFire custodianship. Thanks a lot for all work done to TsiChung! He proposes that Jason (Jin Zhengxiong) will pick up his work. So welcome aboard, Jason! - ARM: -- I have tried my best to stand in for Tom Rix as ARM custodian, but both my time and my experience with this architecture is way too limited to do this job well. Fortunaltey Albert Aribaud has agreed to take over this job, starting after the release of v2010.12. So welcome aboard, Albert. - Network: -- Ben Warren has informed me that he has to give up Network custodianship. Currently we have not found a replacement yet. Volunteers welcome!! - General: -- Several times before it has been suggested to use Patchwork for U-Boot; in the past, I hesitated to do that for various reasons. But in the meantime a number of features have been added to Patchwork, and I think it now can be indeed beneficial to our workflow. I'm happy to announce that we now have U-Boot registered as project: http://patchwork.ozlabs.org/project/uboot/list/ The setup has just been activated; I will try to arrange to have some more history added, but I don;t want to promise that this will work, or when this will happen. For now, I would like to ask all CUSTODIANS to register as users at patchwork.ozlabs.org, so we can arrange that the appropriate privileges will be granted to you. Kumar - you already had a Patchwork user ID, so you don't have to do this 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 Ninety-Ninety Rule of Project Schedules: The first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] keep on resetting my imx51 board.
Hi, Here i have query that it keep on resetting my board. without getting console. Regards Mrurugan. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: e1000: Add initialized eth_device & e1000_hw structure
nic and hw structures are allocated via malloc i.e. return memory
is not zero initialized. Because of this few structure member like
"function pointers" are initialized with garbage values.
It may cause problem. for eg. during eth_initialize, dev->write_hwaddr
is used.
Signed-off-by: Kumar Gala
---
drivers/net/e1000.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 2825342..911eb2c 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -5177,7 +5177,21 @@ e1000_initialize(bd_t * bis)
}
nic = (struct eth_device *) malloc(sizeof (*nic));
+ if (!nic) {
+ printf("Error: e1000 - Can not alloc memory\n");
+ return 0;
+ }
+
hw = (struct e1000_hw *) malloc(sizeof (*hw));
+ if (!nic) {
+ free(nic);
+ printf("Error: e1000 - Can not alloc memory\n");
+ return 0;
+ }
+
+ memset(nic, 0, sizeof(*dev));
+ memset(hw, 0, sizeof(*hw));
+
hw->pdev = devno;
nic->priv = hw;
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: add 8-byte alignment for ABI compliance before board_init_f
Dear Graeme Russ, In message <4cdd0d1f.7010...@gmail.com> you wrote: > > > Passing gd as parameter makes no sense, thoug, as it's global data and > > we reserve a register to store it's address, so it can always be used > > with minimal overhead. > > Which is a really nice idea if you have a register to spare. Unfortunately, > x86 does not have this luxury, and the only way I can get gd (and as a > consequence upper memory bound for relocation) is to allocate it in > assembler and pass to C as a function argument Agreed - x86 has always it's own set of limitations. 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 In the pitiful, multipage, connection-boxed form to which the flow- chart has today been elaborated, it has proved to be useless as a design tool -- programmers draw flowcharts after, not before, writing the programs they describe.- Fred Brooks, Jr. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] PBL: add support for boot from SPI flash.
On Nov 12, 2010, at 12:36 AM, Shaohui Xie wrote:
> PBL: SPI flash used as RCW and PBI source, CPC1 used as 1M SRAM
> where PBL will copy whole U-BOOT image to, U-boot can boot from CPC1
> after PBL completes RCW and PBI phases.
>
> To produces the U-boot image which can used by PBL, pbl_image_tool.html
> is a necessary tool.
(drop this bit about pbl_image_tool.html, I assume this is the RCW tool??)
>
> Signed-off-by: Chunhe Lan
> Signed-off-by: Mingkai Hu
> Signed-off-by: Shaohui Xie
> ---
> arch/powerpc/cpu/mpc85xx/cpu_init.c | 25 +
> board/freescale/corenet_ds/config.mk | 6 ++
> board/freescale/corenet_ds/tlb.c |9 +
> boards.cfg |1 +
> include/configs/corenet_ds.h | 31 +--
> 5 files changed, 70 insertions(+), 2 deletions(-)
Let's use CONFIG_SPIFLASH like we do on all other boards instead of
CONFIG_PBLSPI
>
> diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> index 27236a0..b5a90fb 100644
> --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> @@ -136,6 +136,26 @@ static void enable_cpc(void)
>
> cpc_corenet_t *cpc = (cpc_corenet_t *)CONFIG_SYS_FSL_CPC_ADDR;
>
> +#if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L3_ADDR)
> + if (in_be32(&cpc->cpccsr0) & CPC_CSR0_CE) {
> + /* find and disable LAW of SRAM */
> + struct law_entry law = find_law(CONFIG_SYS_INIT_L3_ADDR);
> +
> + if (law.index == -1) {
> + printf("\nFatal error happened\n");
> + return;
> + } else
> + disable_law(law.index);
> +
> +#ifdef CONFIG_SYS_P4080_ERRATUM_CPC4
> + /* Disable workaround - only needed in all SRAM mode */
> + clrbits_be32(&cpc->cpchdbcr0, CPC_HDBCR0_CDQ_SPEC_DIS);
made the comment before about a separate patch for this.
> +#endif
> + out_be32(&cpc->cpccsr0, 0);
> + out_be32(&cpc->cpcsrcr0, 0);
> + }
> +#endif
> +
> for (i = 0; i < CONFIG_SYS_NUM_CPC; i++, cpc++) {
> u32 cpccfg0 = in_be32(&cpc->cpccfg0);
> size += CPC_CFG0_SZ_K(cpccfg0);
> @@ -155,6 +175,11 @@ void invalidate_cpc(void)
> cpc_corenet_t *cpc = (cpc_corenet_t *)CONFIG_SYS_FSL_CPC_ADDR;
>
> for (i = 0; i < CONFIG_SYS_NUM_CPC; i++, cpc++) {
Why dont we do something like:
/* assume if SRAM mode is enabled we are using it to boot from so don't
invalidate it */
if (in_be32(&cpc->cpcsrcr0) & CPC_SRCR0_SRAMEN)
continue;
instead of the ifdef foo & assuming its CPC1.
> +#if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L3_ADDR)
> + /* skip CPC1 when it used as all SRAM */
> + if (i == 0)
> + continue;
> +#endif
> /* Flash invalidate the CPC and clear all the locks */
> out_be32(&cpc->cpccsr0, CPC_CSR0_FI | CPC_CSR0_LFC);
> while (in_be32(&cpc->cpccsr0) & (CPC_CSR0_FI | CPC_CSR0_LFC))
> diff --git a/board/freescale/corenet_ds/config.mk
> b/board/freescale/corenet_ds/config.mk
> index 15bbf20..ece4578 100644
> --- a/board/freescale/corenet_ds/config.mk
> +++ b/board/freescale/corenet_ds/config.mk
> @@ -24,4 +24,10 @@
> # P4080DS board
> #
>
> +ifeq ($(CONFIG_PBLSPI), y)
> +RESET_VECTOR_ADDRESS = 0xfffc
> +endif
> +
> +ifndef RESET_VECTOR_ADDRESS
> RESET_VECTOR_ADDRESS = 0xeffc
> +endif
> diff --git a/board/freescale/corenet_ds/tlb.c
> b/board/freescale/corenet_ds/tlb.c
> index 1ae0416..08f91a7 100644
> --- a/board/freescale/corenet_ds/tlb.c
> +++ b/board/freescale/corenet_ds/tlb.c
> @@ -51,9 +51,18 @@ struct fsl_e_tlb_entry tlb_table[] = {
>
> /* TLB 1 */
> /* *I*** - Covers boot page */
> +#if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L3_ADDR)
> + /* *I*G - L3SRAM. When L3 is used as 1M SRAM, the address of the
> + * SRAM is at 0xfff0, it covered the 0xf000.
> + * */
> + SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L3_ADDR, CONFIG_SYS_INIT_L3_ADDR,
> + MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> + 0, 0, BOOKE_PAGESZ_1M, 1),
> +#else
> SET_TLB_ENTRY(1, 0xf000, 0xf000,
> MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> 0, 0, BOOKE_PAGESZ_4K, 1),
> +#endif
>
> /* *I*G* - CCSRBAR */
> SET_TLB_ENTRY(1, CONFIG_SYS_CCSRBAR, CONFIG_SYS_CCSRBAR_PHYS,
> diff --git a/boards.cfg b/boards.cfg
> index 6c2a667..562721f 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -195,6 +195,7 @@ P1022DS powerpc mpc85xx p1022ds
> freescale
> P2020DS powerpc mpc85xx p2020ds freescale
> stxgp3powerpc mpc85xx stxgp3 stx
> P4080DS powerpc mpc85xx corenet_ds freescale
> +P4080D
Re: [U-Boot] [PATCH] arm: add 8-byte alignment for ABI compliance before board_init_f
On 12/11/10 19:50, Wolfgang Denk wrote: > Dear Reinhard Meyer, > > In message <4cdce769.8080...@emk-elektronik.de> you wrote: >> >> Is bootflag ever used? If not, why not change the parameter to >> give the gd address to board_init_f? > > No, bootflag is never used and could / should be removed. > > Passing gd as parameter makes no sense, thoug, as it's global data and > we reserve a register to store it's address, so it can always be used > with minimal overhead. Which is a really nice idea if you have a register to spare. Unfortunately, x86 does not have this luxury, and the only way I can get gd (and as a consequence upper memory bound for relocation) is to allocate it in assembler and pass to C as a function argument Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: add 8-byte alignment for ABI compliance before board_init_f
On 12/11/10 18:19, Heiko Schocher wrote:
> Hello Reinhard,
>
> Reinhard Meyer wrote:
>> Dear Heiko Schocher,
>>> diff --git a/arch/arm/cpu/sa1100/start.S b/arch/arm/cpu/sa1100/start.S
>> Is bootflag ever used? If not, why not change the parameter to
>
> No.
>
>> give the gd address to board_init_f?
>>
>> ld r0, sp (whatever the exact assembly syntax for that would be)
>>
>> void board_init_f (gd_t *gd_addr)
>> ...
>> gd = gd_addr;
>
> I thought this too, but in arch/powerpc/lib/board.c it is used as bootflag,
> so I didn;t want to touch this ... but looking in arch/*/lib/board.c
> this first parameter is not always used as bootflag ... so I think
> that would be good ... opinions?
>
For x86, I use the parameter as a pointer to gd and put boot flags in gd:
void board_init_f (ulong gdp)
{
The memory layout for x86 is:
+--Top of Memory-+
||
| Stack |
||
++
||
| Global Data |
||
++
||
| U-Boot Code |
|+ Data |
||
++ <-- dest_addr (see below)
||
| BSS |
||
++
||
| malloc area |
||
++
||
| Free Memory |
//
So passing the pointer to gd also serves to calculate the relocation address:
/* Calculate destination RAM Address and relocation offset */
dest_addr = (void *)gdp - (bss_end - text_start);
rel_offset = dest_addr - text_start;
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: add 8-byte alignment for ABI compliance before board_init_f
Dear Reinhard Meyer, In message <4cdce769.8080...@emk-elektronik.de> you wrote: > > Is bootflag ever used? If not, why not change the parameter to > give the gd address to board_init_f? No, bootflag is never used and could / should be removed. Passing gd as parameter makes no sense, thoug, as it's global data and we reserve a register to store it's address, so it can always be used with minimal overhead. > One further thought, why not init the reserved register in assembly and > remove the gd relevant code in C? But that bears some risk if the register > is changed and the assembly is forgotten to adapt.. We try to do as much as pssible in C, and only what really cannot be avoided in assembly. 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 last thing one knows in constructing a work is what to put first. - Blaise Pascal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zlib: updated to v.1.2.3
Dear "Asokan, Shyama Trikkadeeri", In message <575ed9d63b7e244bbb3786a299acbba08e7...@ie10ev813.global.ds.honeywell.com> you wrote: > > As you had suggested I tried build u-boot with one of the 2010.09v. But > I observe the same failures in them. The configuration step of u-boot > for the boards works fine but the cross-compiling shows the same crc32 > error. > > $ make at91sam9263ek_config > Configuring for at91sam9263ek board... > > $ make CROSS_COMPILE=arm-linux- I cannot reproduce that problem here: -> git checkout v2010.09 -> ./MAKEALL at91sam9263ek Configuring for at91sam9263ek board... atmel_dataflash_spi.c:25:2: warning: #warning Please update to use C structur SoC access ! atmel_usart.c:21:2: warning: #warning Please update to use C structur SoC access ! textdata bss dec hex filename 189494 34359 268312 492165 78285 ./u-boot - SUMMARY Boards compiled: 1 Boards with warnings or errors: 1 ( at91sam9263ek ) -- Maybe you have old cruft laying around from previous builds? Make sure to run "make mrproper" before the "make at91sam9263ek_config" Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What is mind? No matter. What is matter? Never mind. -- Thomas Hewitt Key, 1799-1875 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: add 8-byte alignment for ABI compliance before board_init_f
Hello Albert, Albert ARIBAUD wrote: > Le 12/11/2010 07:53, Heiko Schocher a écrit : >> suggested from Daniel Hobi >> >> Tested on following boards: >> arm1136: qong >> armv7: omap3_beagle >> arm926ejs: magnesium, tx25 >> >> Signed-off-by: Heiko Schocher >> cc: Daniel Hobi >> cc: Albert ARIBAUD > > I'm a bit uneasy about having the symbol unaligned and the aligning done > by the code (and in different places): ok. >> ldrsp, =(CONFIG_SYS_INIT_SP_ADDR) >> +bicsp, sp, #7 /* 8-byte alignment for ABI compliance */ > >> -gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR); >> +gd = (gd_t *) ((CONFIG_SYS_INIT_SP_ADDR)& ~0x07); >> > > There is always a risk that overhauls of the code, or new uses elsewhere > in the code, forget about the alignment constraint and use the symbol > straight away, which could cause all sorts of hard to debug issues. Ok. > Could we not align the symbol value itself so that the code simply uses > the symbol? Hmm.. but users can forgot to align the symbol ... and I think, code should not change that often in this place ... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: add 8-byte alignment for ABI compliance before board_init_f
Le 12/11/2010 08:19, Heiko Schocher a écrit : >> One further thought, why not init the reserved register in assembly and >> remove the gd relevant code in C? But that bears some risk if the register >> is changed and the assembly is forgotten to adapt.. > > No, I think this is to risky ... It is absolutely not risky. It is simply infeasible. :) Different ARM toolchains use registers in different ways. Go from one toolchain to another, or from one *version* of a toolchain to another, and your "reserved" register is not any more. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
