[U-Boot] U-Boot Digest, Vol 61, Issue 36
krishna dwivedi
krishna.dwivedi01 at gmail.com
Wed Jun 26 09:24:14 CEST 2013
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.dwivedi01 at 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-request at lists.denx.de> wrote:
>
>> Send U-Boot mailing list submissions to
>> u-boot at 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-request at lists.denx.de
>>
>> You can reach the person managing the list at
>> u-boot-owner at 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.przywara at linaro.org>
>> Subject: Re: [U-Boot] [PATCH v2 6/7] ARM: extend non-secure switch to
>> also go into HYP mode
>> To: Nikolay Nikolaev <nicknickolaev at gmail.com>
>> Cc: geoff.levand at linaro.org, u-boot at lists.denx.de, trini at ti.com,
>> kvmarm at lists.cs.columbia.edu
>> Message-ID: <51C95472.9030000 at 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.przywara at linaro.org <mailto:andre.przywara at 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.przywara at linaro.org
>> > <mailto:andre.przywara at 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.przywara at linaro.org
>> > <mailto:andre.przywara at 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
>> > kvmarm at lists.cs.columbia.edu <mailto:kvmarm at 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.majewski at samsung.com>
>> Subject: Re: [U-Boot] dfu: using dfu-util -l shows different output
>> To: Heiko Schocher <hs at denx.de>
>> Cc: Marek Vasut <marex at denx.de>, "u-boot at lists.denx.de"
>> <u-boot at lists.denx.de>, Kyungmin Park <kyungmin.park at samsung.com
>> >,
>> Pantelis Antoniou <panto at antoniou-consulting.com>, "Egli,
>> Samuel"
>> <samuel.egli at siemens.com>
>> Message-ID: <20130625104438.2538a880 at 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 <hs at denx.de>
>> Subject: Re: [U-Boot] dfu: using dfu-util -l shows different output
>> To: Lukasz Majewski <l.majewski at samsung.com>
>> Cc: Marek Vasut <marex at denx.de>, "u-boot at lists.denx.de"
>> <u-boot at lists.denx.de>, Kyungmin Park <kyungmin.park at samsung.com
>> >,
>> Pantelis Antoniou <panto at antoniou-consulting.com>, "Egli,
>> Samuel"
>> <samuel.egli at siemens.com>
>> Message-ID: <51C95AF2.6030201 at 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-uboot at infra-silbe.de>
>> Subject: Re: [U-Boot] [PATCH] OpenRD: relocate environment to 640kB
>> To: Albert ARIBAUD <albert.u.boot at aribaud.net>
>> Cc: Tom Rini <trini at ti.com>, u-boot at lists.denx.de
>> Message-ID: <toeppvail0i.fsf at twin.sascha.silbe.org>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hello Albert, hello Tom,
>>
>> Albert ARIBAUD <albert.u.boot at 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 at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>>
>> End of U-Boot Digest, Vol 61, Issue 36
>> **************************************
>>
>
>
More information about the U-Boot
mailing list