Hi All, Can anyone please provide me poinet on this.
Regards, Krishna On Wed, Jun 26, 2013 at 12:54 PM, krishna dwivedi < krishna.dwived...@gmail.com> wrote: > Hi All, > > > > 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. > Can ayone please provide me pointer what could be issue here. > > Regards, > krishna > > > On Wed, Jun 26, 2013 at 11:52 AM, krishna dwivedi < > krishna.dwived...@gmail.com> wrote: > >> 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
