[U-Boot] U-Boot Digest, Vol 61, Issue 36
krishna dwivedi
krishna.dwivedi01 at gmail.com
Wed Jun 26 08:22:41 CEST 2013
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