[U-Boot] U-Boot Digest, Vol 61, Issue 36
krishna dwivedi
krishna.dwivedi01 at gmail.com
Wed Jun 26 14:41:15 CEST 2013
Hi All,
Can anyone please provide me poinet on this.
Regards,
Krishna
On Wed, Jun 26, 2013 at 12:54 PM, krishna dwivedi <
krishna.dwivedi01 at 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.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