Hi All, Hope everyone is doing great:)
I am trying to build U-boot:2013-04.But running into this error: mips64-nlm-elf-ld: arch/mips/cpu/mips64/start.o: relocation (null) against `board_init_f' can not be used when making a shared object; recompile with -fPIC arch/mips/cpu/mips64/start.o: could not read symbols: Bad value. Initially,In file arch/mips/config.mk,I commented the flag: #LDFLAGS_FINAL += -pie This error resolved.But after relocation of u-boot code,we need this flag.So i need to uncomment this flag.and again i am running into this error agian. Anyone faced this issue earlier.Anyone please provide pointers to resolve this. Thanks in advance!! Regards, Krishna On Tue, Jun 25, 2013 at 3:30 PM, <u-boot-requ...@lists.denx.de> wrote: > Send U-Boot mailing list submissions to > u-boot@lists.denx.de > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.denx.de/mailman/listinfo/u-boot > or, via email, send a message with subject or body 'help' to > u-boot-requ...@lists.denx.de > > You can reach the person managing the list at > u-boot-ow...@lists.denx.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of U-Boot digest..." > > > Today's Topics: > > 1. Re: [PATCH v2 6/7] ARM: extend non-secure switch to also go > into HYP mode (Andre Przywara) > 2. Re: dfu: using dfu-util -l shows different output > (Lukasz Majewski) > 3. Re: dfu: using dfu-util -l shows different output (Heiko Schocher) > 4. Re: [PATCH] OpenRD: relocate environment to 640kB (Sascha Silbe) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 25 Jun 2013 10:27:30 +0200 > From: Andre Przywara <andre.przyw...@linaro.org> > Subject: Re: [U-Boot] [PATCH v2 6/7] ARM: extend non-secure switch to > also go into HYP mode > To: Nikolay Nikolaev <nicknickol...@gmail.com> > Cc: geoff.lev...@linaro.org, u-boot@lists.denx.de, tr...@ti.com, > kvm...@lists.cs.columbia.edu > Message-ID: <51c95472.9030...@linaro.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 06/21/2013 04:38 PM, Nikolay Nikolaev wrote: > > Hello, > > > > > > On Thu, Jun 13, 2013 at 2:01 PM, Andre Przywara > > <andre.przyw...@linaro.org <mailto:andre.przyw...@linaro.org>> wrote: > > > > For the KVM and XEN hypervisors to be usable, we need to enter the > > kernel in HYP mode. Now that we already are in non-secure state, > > HYP mode switching is within short reach. > > > > While doing the non-secure switch, we have to enable the HVC > > instruction and setup the HYP mode HVBAR (while still secure). > > > > The actual switch is done by dropping back from a HYP mode handler > > without actually leaving HYP mode, so we introduce a new handler > > routine in our new secure exception vector table. > > > > In the assembly switching routine we save and restore the banked LR > > and SP registers around the hypercall to do the actual HYP mode > > switch. > > > > The C routine first checks whether we are in HYP mode already and > > also whether the virtualization extensions are available. It also > > checks whether the HYP mode switch was finally successful. > > The bootm command part only adds and adjusts some error reporting. > > > > Signed-off-by: Andre Przywara <andre.przyw...@linaro.org > > <mailto:andre.przyw...@linaro.org>> > > --- > > arch/arm/cpu/armv7/nonsec_virt.S | 31 > ++++++++++++++++++++++++++++--- > > arch/arm/include/asm/armv7.h | 7 +++++-- > > arch/arm/lib/bootm.c | 14 ++++++++++---- > > arch/arm/lib/virt-v7.c | 27 ++++++++++++++++++++++----- > > 4 files changed, 65 insertions(+), 14 deletions(-) > > > > diff --git a/arch/arm/cpu/armv7/nonsec_virt.S > > b/arch/arm/cpu/armv7/nonsec_virt.S > > index 919f6e9..950da6f 100644 > > --- a/arch/arm/cpu/armv7/nonsec_virt.S > > +++ b/arch/arm/cpu/armv7/nonsec_virt.S > > @@ -1,5 +1,5 @@ > > /* > > - * code for switching cores into non-secure state > > + * code for switching cores into non-secure state and into HYP mode > > * > > * Copyright (c) 2013 Andre Przywara <andre.przyw...@linaro.org > > <mailto:andre.przyw...@linaro.org>> > > * > > @@ -26,14 +26,14 @@ > > #include <asm/gic.h> > > #include <asm/armv7.h> > > > > -/* the vector table for secure state */ > > +/* the vector table for secure state and HYP mode */ > > _secure_vectors: > > .word 0 /* reset */ > > .word 0 /* undef */ > > adr pc, _secure_monitor > > .word 0 > > .word 0 > > - .word 0 > > + adr pc, _hyp_trap > > .word 0 > > .word 0 > > .word 0 /* pad */ > > @@ -50,10 +50,23 @@ _secure_monitor: > > bic r1, r1, #0x4e @ clear IRQ, FIQ, > > EA, nET bits > > orr r1, r1, #0x31 @ enable NS, AW, FW > > bits > > > > + mrc p15, 0, r0, c0, c1, 1 @ read ID_PFR1 > > + and r0, r0, #CPUID_ARM_VIRT_MASK @ mask > > virtualization bits > > + cmp r0, #(1 << CPUID_ARM_VIRT_SHIFT) > > + orreq r1, r1, #0x100 @ allow HVC > instruction > > + > > mcr p15, 0, r1, c1, c1, 0 @ write SCR (with > > NS bit set) > > > > + mrceq p15, 0, r0, c12, c0, 1 @ get MVBAR value > > + mcreq p15, 4, r0, c12, c0, 0 @ write HVBAR > > + > > movs pc, lr @ return to > > non-secure SVC > > > > +_hyp_trap: > > + .byte 0x00, 0xe3, 0x0e, 0xe1 @ mrs lr, elr_hyp > > + mov pc, lr @ do no switch > > modes, but > > + @ return to caller > > + > > /* > > * Secondary CPUs start here and call the code for the core > > specific parts > > * of the non-secure and HYP mode transition. The GIC distributor > > specific > > @@ -69,6 +82,7 @@ _smp_pen: > > mcr p15, 0, r1, c12, c0, 0 @ set VBAR > > > > bl _nonsec_init > > + bl _hyp_init > > > > > > If I get it right, _nonsec_init stores the GICC address. Adding > > _hyp_init here overwrites r3. > > In effect the following lines do something on the stack (sp). > > Eek. Good catch. Thanks for spotting. The fix will be included in the > next round. > Which kind of hints that acknowledging the wakeup IPI is not really > necessary, as it was suspected earlier already. > > > > > ldr r1, [r3, #0x0c] @ read GICD > acknowledge > > str r1, [r3, #0x10] @ write GICD EOI > > > > > > can you add these 0x0c and 0x10 constants to gic.h. > > Sure. And I will fix the wrong comments on the way ;-) > > Thanks for the review! > Andre > > > > > @@ -145,3 +159,14 @@ _nonsec_init: > > str r1, [r2] @ allow private > > interrupts > > > > bx lr > > + > > +.globl _hyp_init > > +_hyp_init: > > + mov r2, lr > > + mov r3, sp @ save SVC copy of > > LR and SP > > + isb > > + .byte 0x70, 0x00, 0x40, 0xe1 @ hvc #0 > > + mov sp, r3 > > + mov lr, r2 @ fix HYP mode > > banked LR and SP > > + > > + bx lr > > diff --git a/arch/arm/include/asm/armv7.h > b/arch/arm/include/asm/armv7.h > > index 04545b9..8c3a85e 100644 > > --- a/arch/arm/include/asm/armv7.h > > +++ b/arch/arm/include/asm/armv7.h > > @@ -89,15 +89,18 @@ void v7_outer_cache_inval_range(u32 start, u32 > end); > > > > #ifdef CONFIG_ARMV7_VIRT > > > > -#define HYP_ERR_NO_SEC_EXT 2 > > +#define HYP_ERR_ALREADY_HYP_MODE 1 > > +#define HYP_ERR_NO_VIRT_EXT 2 > > #define HYP_ERR_NO_GIC_ADDRESS 3 > > #define HYP_ERR_GIC_ADDRESS_ABOVE_4GB 4 > > +#define HYP_ERR_NOT_HYP_MODE 5 > > > > -int armv7_switch_nonsec(void); > > +int armv7_switch_hyp(void); > > > > /* defined in cpu/armv7/nonsec_virt.S */ > > void _nonsec_init(void); > > void _smp_pen(void); > > +void _hyp_init(void); > > #endif /* CONFIG_ARMV7_VIRT */ > > > > #endif /* ! __ASSEMBLY__ */ > > diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c > > index 8251a89..7edd84d 100644 > > --- a/arch/arm/lib/bootm.c > > +++ b/arch/arm/lib/bootm.c > > @@ -227,12 +227,15 @@ static void boot_prep_linux(bootm_headers_t > > *images) > > hang(); > > } > > #ifdef CONFIG_ARMV7_VIRT > > - switch (armv7_switch_nonsec()) { > > + switch (armv7_switch_hyp()) { > > case 0: > > - debug("entered non-secure state\n"); > > + debug("entered HYP mode\n"); > > break; > > - case HYP_ERR_NO_SEC_EXT: > > - printf("HYP mode: Security extensions not > > implemented.\n"); > > + case HYP_ERR_ALREADY_HYP_MODE: > > + debug("CPU already in HYP mode\n"); > > + break; > > + case HYP_ERR_NO_VIRT_EXT: > > + printf("HYP mode: Virtualization extensions not > > implemented.\n"); > > break; > > case HYP_ERR_NO_GIC_ADDRESS: > > printf("HYP mode: could not determine GIC > address.\n"); > > @@ -240,6 +243,9 @@ static void boot_prep_linux(bootm_headers_t > *images) > > case HYP_ERR_GIC_ADDRESS_ABOVE_4GB: > > printf("HYP mode: PERIPHBASE is above 4 GB, cannot > > access this.\n"); > > break; > > + case HYP_ERR_NOT_HYP_MODE: > > + printf("HYP mode: switch not successful.\n"); > > + break; > > } > > #endif > > } > > diff --git a/arch/arm/lib/virt-v7.c b/arch/arm/lib/virt-v7.c > > index 6946e4d..1e206b9 100644 > > --- a/arch/arm/lib/virt-v7.c > > +++ b/arch/arm/lib/virt-v7.c > > @@ -3,6 +3,7 @@ > > * Andre Przywara, Linaro > > * > > * Routines to transition ARMv7 processors from secure into > > non-secure state > > + * and from non-secure SVC into HYP mode > > * needed to enable ARMv7 virtualization for current hypervisors > > * > > * See file CREDITS for list of people who contributed to this > > @@ -29,6 +30,14 @@ > > #include <asm/gic.h> > > #include <asm/io.h> > > > > +static unsigned int read_cpsr(void) > > +{ > > + unsigned int reg; > > + > > + asm volatile ("mrs %0, cpsr\n" : "=r" (reg)); > > + return reg; > > +} > > + > > static unsigned int read_id_pfr1(void) > > { > > unsigned int reg; > > @@ -110,16 +119,20 @@ static void kick_secondary_cpus(char *gicdptr) > > writel(1U << 24, &gicdptr[GICD_SGIR]); > > } > > > > -int armv7_switch_nonsec(void) > > +int armv7_switch_hyp(void) > > { > > unsigned int reg, ret; > > char *gicdptr; > > unsigned itlinesnr, i; > > > > - /* check whether the CPU supports the security extensions */ > > + /* check whether we are in HYP mode already */ > > + if ((read_cpsr() & 0x1f) == 0x1a) > > + return HYP_ERR_ALREADY_HYP_MODE; > > + > > + /* check whether the CPU supports the virtualization > > extensions */ > > reg = read_id_pfr1(); > > - if ((reg & 0xF0) == 0) > > - return HYP_ERR_NO_SEC_EXT; > > + if ((reg & CPUID_ARM_VIRT_MASK) != 1 << CPUID_ARM_VIRT_SHIFT) > > + return HYP_ERR_NO_VIRT_EXT; > > > > set_generic_timer_frequency(); > > > > @@ -147,8 +160,12 @@ int armv7_switch_nonsec(void) > > > > kick_secondary_cpus(gicdptr); > > > > - /* call the non-sec switching code on this CPU also */ > > + /* call the HYP switching code on this CPU also */ > > _nonsec_init(); > > + _hyp_init(); > > + > > + if ((read_cpsr() & 0x1F) != 0x1a) > > + return HYP_ERR_NOT_HYP_MODE; > > > > return 0; > > } > > -- > > 1.7.12.1 > > > > _______________________________________________ > > kvmarm mailing list > > kvm...@lists.cs.columbia.edu <mailto:kvm...@lists.cs.columbia.edu> > > https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm > > > > > > regards, > > Nikolay Nikolaev > > > > ------------------------------ > > Message: 2 > Date: Tue, 25 Jun 2013 10:44:38 +0200 > From: Lukasz Majewski <l.majew...@samsung.com> > Subject: Re: [U-Boot] dfu: using dfu-util -l shows different output > To: Heiko Schocher <h...@denx.de> > Cc: Marek Vasut <ma...@denx.de>, "u-boot@lists.denx.de" > <u-boot@lists.denx.de>, Kyungmin Park <kyungmin.p...@samsung.com>, > Pantelis Antoniou <pa...@antoniou-consulting.com>, "Egli, > Samuel" > <samuel.e...@siemens.com> > Message-ID: <20130625104438.2538a880@amdc308.digital.local> > Content-Type: text/plain; charset=US-ASCII > > Hi Heiko, > > > Hello Pantelis, > > > > Am 25.06.2013 10:16, schrieb Pantelis Antoniou: > > > Heiko, > > > > > > I don't think the gadget is initialized before you issue > > > a dfu call. > > > > > > So that makes sense. > > > > ? > > > > I call from the host "dfu-util -l" so the gadget on the board > > should do the answer ... or? > > The gadget is not initialized here (so the dfu-util -l shows no > output). > > After transfer it shows information about proper alt settings. > > This is correct behaviour, but I had discussion about this with Tom and > we agreed, that it would be nice to have "dfu-util -l" exporting from > very beginning the alt setting information. > > Frankly, I had too much other work to implement it. > > However, I think, that it would be a very useful feature (e.g. to get > alt settings layout at HOST to facilitate automated flashing). > > > > > > > Let's wait until Tom wakes up and have an authoritative answer. > > > > Ok! > > > > bye, > > Heiko > > > > > > > > Regards > > > > > > -- Pantelis > > > > > > On Jun 25, 2013, at 11:08 AM, Heiko Schocher wrote: > > > > > >> Hello, > > >> > > >> using "dfu-util -l" shows different output connecting to > > >> an am335x based board and using dfu_nand.c with current > > >> u-boot: > > >> > > >> after resetting the board I get: > > >> > > >> # dfu-util -l > > >> dfu-util 0.5 > > >> > > >> (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. > > >> (C) 2010-2011 Tormod Volden (DfuSe support) > > >> This program is Free Software and has ABSOLUTELY NO WARRANTY > > >> > > >> dfu-util does currently only support DFU version 1.0 > > >> > > >> Found Runtime: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, > > >> name="Device Firmware Upgrade" # > > >> > > >> after a dfu transfer I see: > > >> > > >> # dfu-util -l > > >> dfu-util 0.5 > > >> > > >> (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. > > >> (C) 2010-2011 Tormod Volden (DfuSe support) > > >> This program is Free Software and has ABSOLUTELY NO WARRANTY > > >> > > >> dfu-util does currently only support DFU version 1.0 > > >> > > >> Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="SPL" > > >> Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=1, > > >> name="SPL.backup1" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, > > >> alt=2, name="SPL.backup2" Found DFU: [0525:bd00] devnum=0, cfg=2, > > >> intf=0, alt=3, name="SPL.backup3" Found DFU: [0525:bd00] devnum=0, > > >> cfg=2, intf=0, alt=4, name="u-boot" Found DFU: [0525:bd00] > > >> devnum=0, cfg=2, intf=0, alt=5, name="kernel_a" Found DFU: > > >> [0525:bd00] devnum=0, cfg=2, intf=0, alt=6, name="kernel_b" Found > > >> DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=7, name="rootfs" # > > >> > > >> Which I expected ... > > >> > > >> U-Boot environment variable: > > >> > > >> U-Boot# print dfu_alt_info > > >> dfu_alt_info=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0 > > >> 3;SPL.backup3 part 0 4;u-boot part 0 5;kernel_a part 0 7;kernel_b > > >> part 0 8;rootfs part 0 10 U-Boot# > > >> > > >> Is this a bug or a feature? > > >> > > >> bye, > > >> Heiko > > >> -- > > >> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev > > >> Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 > > >> Groebenzell, Germany > > > > > > > > > > > > > > > > > -- > Best regards, > > Lukasz Majewski > > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group > > > ------------------------------ > > Message: 3 > Date: Tue, 25 Jun 2013 10:55:14 +0200 > From: Heiko Schocher <h...@denx.de> > Subject: Re: [U-Boot] dfu: using dfu-util -l shows different output > To: Lukasz Majewski <l.majew...@samsung.com> > Cc: Marek Vasut <ma...@denx.de>, "u-boot@lists.denx.de" > <u-boot@lists.denx.de>, Kyungmin Park <kyungmin.p...@samsung.com>, > Pantelis Antoniou <pa...@antoniou-consulting.com>, "Egli, > Samuel" > <samuel.e...@siemens.com> > Message-ID: <51c95af2.6030...@denx.de> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello Lukasz, > > Am 25.06.2013 10:44, schrieb Lukasz Majewski: > > Hi Heiko, > > > >> Hello Pantelis, > >> > >> Am 25.06.2013 10:16, schrieb Pantelis Antoniou: > >>> Heiko, > >>> > >>> I don't think the gadget is initialized before you issue > >>> a dfu call. > >>> > >>> So that makes sense. > >> > >> ? > >> > >> I call from the host "dfu-util -l" so the gadget on the board > >> should do the answer ... or? > > > > The gadget is not initialized here (so the dfu-util -l shows no > > output). > > > > After transfer it shows information about proper alt settings. > > > > This is correct behaviour, but I had discussion about this with Tom and > > we agreed, that it would be nice to have "dfu-util -l" exporting from > > very beginning the alt setting information. > > Yes, I vote for this too. Connecting to a board, I first > would do a "dfu-util -l" to look, what is possible to > update here ... > > > Frankly, I had too much other work to implement it. > > > > However, I think, that it would be a very useful feature (e.g. to get > > alt settings layout at HOST to facilitate automated flashing). > > Hmm... I digged into the code, but not really found a place > where I have to start. Can you give me a hint where to start? > So maybe, I can do it? > > Thanks! > > bye, > Heiko > >>> Let's wait until Tom wakes up and have an authoritative answer. > >> > >> Ok! > >> > >> bye, > >> Heiko > >> > >>> > >>> Regards > >>> > >>> -- Pantelis > >>> > >>> On Jun 25, 2013, at 11:08 AM, Heiko Schocher wrote: > >>> > >>>> Hello, > >>>> > >>>> using "dfu-util -l" shows different output connecting to > >>>> an am335x based board and using dfu_nand.c with current > >>>> u-boot: > >>>> > >>>> after resetting the board I get: > >>>> > >>>> # dfu-util -l > >>>> dfu-util 0.5 > >>>> > >>>> (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. > >>>> (C) 2010-2011 Tormod Volden (DfuSe support) > >>>> This program is Free Software and has ABSOLUTELY NO WARRANTY > >>>> > >>>> dfu-util does currently only support DFU version 1.0 > >>>> > >>>> Found Runtime: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, > >>>> name="Device Firmware Upgrade" # > >>>> > >>>> after a dfu transfer I see: > >>>> > >>>> # dfu-util -l > >>>> dfu-util 0.5 > >>>> > >>>> (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. > >>>> (C) 2010-2011 Tormod Volden (DfuSe support) > >>>> This program is Free Software and has ABSOLUTELY NO WARRANTY > >>>> > >>>> dfu-util does currently only support DFU version 1.0 > >>>> > >>>> Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="SPL" > >>>> Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=1, > >>>> name="SPL.backup1" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, > >>>> alt=2, name="SPL.backup2" Found DFU: [0525:bd00] devnum=0, cfg=2, > >>>> intf=0, alt=3, name="SPL.backup3" Found DFU: [0525:bd00] devnum=0, > >>>> cfg=2, intf=0, alt=4, name="u-boot" Found DFU: [0525:bd00] > >>>> devnum=0, cfg=2, intf=0, alt=5, name="kernel_a" Found DFU: > >>>> [0525:bd00] devnum=0, cfg=2, intf=0, alt=6, name="kernel_b" Found > >>>> DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=7, name="rootfs" # > >>>> > >>>> Which I expected ... > >>>> > >>>> U-Boot environment variable: > >>>> > >>>> U-Boot# print dfu_alt_info > >>>> dfu_alt_info=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0 > >>>> 3;SPL.backup3 part 0 4;u-boot part 0 5;kernel_a part 0 7;kernel_b > >>>> part 0 8;rootfs part 0 10 U-Boot# > >>>> > >>>> Is this a bug or a feature? > >>>> > >>>> bye, > >>>> Heiko > >>>> -- > >>>> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev > >>>> Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 > >>>> Groebenzell, Germany > >>> > >>> > >>> > >> > >> > > > > > > > > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > > > ------------------------------ > > Message: 4 > Date: Tue, 25 Jun 2013 11:42:53 +0200 > From: Sascha Silbe <t-ub...@infra-silbe.de> > Subject: Re: [U-Boot] [PATCH] OpenRD: relocate environment to 640kB > To: Albert ARIBAUD <albert.u.b...@aribaud.net> > Cc: Tom Rini <tr...@ti.com>, u-boot@lists.denx.de > Message-ID: <toeppvail0i....@twin.sascha.silbe.org> > Content-Type: text/plain; charset="us-ascii" > > Hello Albert, hello Tom, > > Albert ARIBAUD <albert.u.b...@aribaud.net> writes: > > [Move environment to account for increase in U-Boot size] > > This patch is for 2013.10, not 2013.07, but I prefer raising the issue > > as early as possible. > > > > If there is no way to make things smoother, then I think the 2013.10 > > release notes should contain a red, blinking, paragraph about this. I > > would *hate* it if people were not warned and given a method to port > > their current environment setting over. > > > > Possibly even, the 2013.07 could have a warning about the change to > > come, so that people have a better chance yet to prepare for the > > change. > > The situation has gotten better recently and U-Boot fits into the > previous partition size of 384KiB again. So it isn't broken on OpenRD > anymore and the above would seem like a good approach. > > Where are the U-Boot Release Notes located? Who is responsible for > editing them? > > Sascha > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 489 bytes > Desc: not available > URL: < > http://lists.denx.de/pipermail/u-boot/attachments/20130625/0dfd227e/attachment-0001.pgp > > > > ------------------------------ > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > > End of U-Boot Digest, Vol 61, Issue 36 > ************************************** >
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot