[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