Hi All,
I am trying to build U-boot:2013-04.But running into this error: mips64-nlm-elf-ld: arch/mips/cpu/mips64/start.o: relocation (null) against `board_init_f' can not be used when making a shared object; recompile with -fPIC arch/mips/cpu/mips64/start.o: could not read symbols: Bad value. Can ayone please provide me pointer what could be issue here. Regards, krishna On Wed, Jun 26, 2013 at 11:52 AM, krishna dwivedi < krishna.dwived...@gmail.com> wrote: > Hi All, > > Hope everyone is doing great:) > > I am trying to build U-boot:2013-04.But running into this error: > mips64-nlm-elf-ld: arch/mips/cpu/mips64/start.o: relocation (null) against > `board_init_f' can not be used when making a shared object; recompile with > -fPIC > arch/mips/cpu/mips64/start.o: could not read symbols: Bad value. > > > Initially,In file arch/mips/config.mk,I commented the flag: > #LDFLAGS_FINAL += -pie > This error resolved.But after relocation of u-boot code,we need this > flag.So i need to uncomment this flag.and again i am running into this > error agian. > > Anyone faced this issue earlier.Anyone please provide pointers to resolve > this. > > Thanks in advance!! > > Regards, > Krishna > > > > > > On Tue, Jun 25, 2013 at 3:30 PM, <u-boot-requ...@lists.denx.de> wrote: > >> Send U-Boot mailing list submissions to >> u-boot@lists.denx.de >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.denx.de/mailman/listinfo/u-boot >> or, via email, send a message with subject or body 'help' to >> u-boot-requ...@lists.denx.de >> >> You can reach the person managing the list at >> u-boot-ow...@lists.denx.de >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of U-Boot digest..." >> >> >> Today's Topics: >> >> 1. Re: [PATCH v2 6/7] ARM: extend non-secure switch to also go >> into HYP mode (Andre Przywara) >> 2. Re: dfu: using dfu-util -l shows different output >> (Lukasz Majewski) >> 3. Re: dfu: using dfu-util -l shows different output (Heiko Schocher) >> 4. Re: [PATCH] OpenRD: relocate environment to 640kB (Sascha Silbe) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 25 Jun 2013 10:27:30 +0200 >> From: Andre Przywara <andre.przyw...@linaro.org> >> Subject: Re: [U-Boot] [PATCH v2 6/7] ARM: extend non-secure switch to >> also go into HYP mode >> To: Nikolay Nikolaev <nicknickol...@gmail.com> >> Cc: geoff.lev...@linaro.org, u-boot@lists.denx.de, tr...@ti.com, >> kvm...@lists.cs.columbia.edu >> Message-ID: <51c95472.9030...@linaro.org> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 06/21/2013 04:38 PM, Nikolay Nikolaev wrote: >> > Hello, >> > >> > >> > On Thu, Jun 13, 2013 at 2:01 PM, Andre Przywara >> > <andre.przyw...@linaro.org <mailto:andre.przyw...@linaro.org>> wrote: >> > >> > For the KVM and XEN hypervisors to be usable, we need to enter the >> > kernel in HYP mode. Now that we already are in non-secure state, >> > HYP mode switching is within short reach. >> > >> > While doing the non-secure switch, we have to enable the HVC >> > instruction and setup the HYP mode HVBAR (while still secure). >> > >> > The actual switch is done by dropping back from a HYP mode handler >> > without actually leaving HYP mode, so we introduce a new handler >> > routine in our new secure exception vector table. >> > >> > In the assembly switching routine we save and restore the banked LR >> > and SP registers around the hypercall to do the actual HYP mode >> > switch. >> > >> > The C routine first checks whether we are in HYP mode already and >> > also whether the virtualization extensions are available. It also >> > checks whether the HYP mode switch was finally successful. >> > The bootm command part only adds and adjusts some error reporting. >> > >> > Signed-off-by: Andre Przywara <andre.przyw...@linaro.org >> > <mailto:andre.przyw...@linaro.org>> >> > --- >> > arch/arm/cpu/armv7/nonsec_virt.S | 31 >> ++++++++++++++++++++++++++++--- >> > arch/arm/include/asm/armv7.h | 7 +++++-- >> > arch/arm/lib/bootm.c | 14 ++++++++++---- >> > arch/arm/lib/virt-v7.c | 27 ++++++++++++++++++++++----- >> > 4 files changed, 65 insertions(+), 14 deletions(-) >> > >> > diff --git a/arch/arm/cpu/armv7/nonsec_virt.S >> > b/arch/arm/cpu/armv7/nonsec_virt.S >> > index 919f6e9..950da6f 100644 >> > --- a/arch/arm/cpu/armv7/nonsec_virt.S >> > +++ b/arch/arm/cpu/armv7/nonsec_virt.S >> > @@ -1,5 +1,5 @@ >> > /* >> > - * code for switching cores into non-secure state >> > + * code for switching cores into non-secure state and into HYP mode >> > * >> > * Copyright (c) 2013 Andre Przywara <andre.przyw...@linaro.org >> > <mailto:andre.przyw...@linaro.org>> >> > * >> > @@ -26,14 +26,14 @@ >> > #include <asm/gic.h> >> > #include <asm/armv7.h> >> > >> > -/* the vector table for secure state */ >> > +/* the vector table for secure state and HYP mode */ >> > _secure_vectors: >> > .word 0 /* reset */ >> > .word 0 /* undef */ >> > adr pc, _secure_monitor >> > .word 0 >> > .word 0 >> > - .word 0 >> > + adr pc, _hyp_trap >> > .word 0 >> > .word 0 >> > .word 0 /* pad */ >> > @@ -50,10 +50,23 @@ _secure_monitor: >> > bic r1, r1, #0x4e @ clear IRQ, FIQ, >> > EA, nET bits >> > orr r1, r1, #0x31 @ enable NS, AW, FW >> > bits >> > >> > + mrc p15, 0, r0, c0, c1, 1 @ read ID_PFR1 >> > + and r0, r0, #CPUID_ARM_VIRT_MASK @ mask >> > virtualization bits >> > + cmp r0, #(1 << CPUID_ARM_VIRT_SHIFT) >> > + orreq r1, r1, #0x100 @ allow HVC >> instruction >> > + >> > mcr p15, 0, r1, c1, c1, 0 @ write SCR (with >> > NS bit set) >> > >> > + mrceq p15, 0, r0, c12, c0, 1 @ get MVBAR value >> > + mcreq p15, 4, r0, c12, c0, 0 @ write HVBAR >> > + >> > movs pc, lr @ return to >> > non-secure SVC >> > >> > +_hyp_trap: >> > + .byte 0x00, 0xe3, 0x0e, 0xe1 @ mrs lr, elr_hyp >> > + mov pc, lr @ do no switch >> > modes, but >> > + @ return to caller >> > + >> > /* >> > * Secondary CPUs start here and call the code for the core >> > specific parts >> > * of the non-secure and HYP mode transition. The GIC distributor >> > specific >> > @@ -69,6 +82,7 @@ _smp_pen: >> > mcr p15, 0, r1, c12, c0, 0 @ set VBAR >> > >> > bl _nonsec_init >> > + bl _hyp_init >> > >> > >> > If I get it right, _nonsec_init stores the GICC address. Adding >> > _hyp_init here overwrites r3. >> > In effect the following lines do something on the stack (sp). >> >> Eek. Good catch. Thanks for spotting. The fix will be included in the >> next round. >> Which kind of hints that acknowledging the wakeup IPI is not really >> necessary, as it was suspected earlier already. >> >> > >> > ldr r1, [r3, #0x0c] @ read GICD >> acknowledge >> > str r1, [r3, #0x10] @ write GICD EOI >> > >> > >> > can you add these 0x0c and 0x10 constants to gic.h. >> >> Sure. And I will fix the wrong comments on the way ;-) >> >> Thanks for the review! >> Andre >> >> > >> > @@ -145,3 +159,14 @@ _nonsec_init: >> > str r1, [r2] @ allow private >> > interrupts >> > >> > bx lr >> > + >> > +.globl _hyp_init >> > +_hyp_init: >> > + mov r2, lr >> > + mov r3, sp @ save SVC copy of >> > LR and SP >> > + isb >> > + .byte 0x70, 0x00, 0x40, 0xe1 @ hvc #0 >> > + mov sp, r3 >> > + mov lr, r2 @ fix HYP mode >> > banked LR and SP >> > + >> > + bx lr >> > diff --git a/arch/arm/include/asm/armv7.h >> b/arch/arm/include/asm/armv7.h >> > index 04545b9..8c3a85e 100644 >> > --- a/arch/arm/include/asm/armv7.h >> > +++ b/arch/arm/include/asm/armv7.h >> > @@ -89,15 +89,18 @@ void v7_outer_cache_inval_range(u32 start, u32 >> end); >> > >> > #ifdef CONFIG_ARMV7_VIRT >> > >> > -#define HYP_ERR_NO_SEC_EXT 2 >> > +#define HYP_ERR_ALREADY_HYP_MODE 1 >> > +#define HYP_ERR_NO_VIRT_EXT 2 >> > #define HYP_ERR_NO_GIC_ADDRESS 3 >> > #define HYP_ERR_GIC_ADDRESS_ABOVE_4GB 4 >> > +#define HYP_ERR_NOT_HYP_MODE 5 >> > >> > -int armv7_switch_nonsec(void); >> > +int armv7_switch_hyp(void); >> > >> > /* defined in cpu/armv7/nonsec_virt.S */ >> > void _nonsec_init(void); >> > void _smp_pen(void); >> > +void _hyp_init(void); >> > #endif /* CONFIG_ARMV7_VIRT */ >> > >> > #endif /* ! __ASSEMBLY__ */ >> > diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c >> > index 8251a89..7edd84d 100644 >> > --- a/arch/arm/lib/bootm.c >> > +++ b/arch/arm/lib/bootm.c >> > @@ -227,12 +227,15 @@ static void boot_prep_linux(bootm_headers_t >> > *images) >> > hang(); >> > } >> > #ifdef CONFIG_ARMV7_VIRT >> > - switch (armv7_switch_nonsec()) { >> > + switch (armv7_switch_hyp()) { >> > case 0: >> > - debug("entered non-secure state\n"); >> > + debug("entered HYP mode\n"); >> > break; >> > - case HYP_ERR_NO_SEC_EXT: >> > - printf("HYP mode: Security extensions not >> > implemented.\n"); >> > + case HYP_ERR_ALREADY_HYP_MODE: >> > + debug("CPU already in HYP mode\n"); >> > + break; >> > + case HYP_ERR_NO_VIRT_EXT: >> > + printf("HYP mode: Virtualization extensions not >> > implemented.\n"); >> > break; >> > case HYP_ERR_NO_GIC_ADDRESS: >> > printf("HYP mode: could not determine GIC >> address.\n"); >> > @@ -240,6 +243,9 @@ static void boot_prep_linux(bootm_headers_t >> *images) >> > case HYP_ERR_GIC_ADDRESS_ABOVE_4GB: >> > printf("HYP mode: PERIPHBASE is above 4 GB, cannot >> > access this.\n"); >> > break; >> > + case HYP_ERR_NOT_HYP_MODE: >> > + printf("HYP mode: switch not successful.\n"); >> > + break; >> > } >> > #endif >> > } >> > diff --git a/arch/arm/lib/virt-v7.c b/arch/arm/lib/virt-v7.c >> > index 6946e4d..1e206b9 100644 >> > --- a/arch/arm/lib/virt-v7.c >> > +++ b/arch/arm/lib/virt-v7.c >> > @@ -3,6 +3,7 @@ >> > * Andre Przywara, Linaro >> > * >> > * Routines to transition ARMv7 processors from secure into >> > non-secure state >> > + * and from non-secure SVC into HYP mode >> > * needed to enable ARMv7 virtualization for current hypervisors >> > * >> > * See file CREDITS for list of people who contributed to this >> > @@ -29,6 +30,14 @@ >> > #include <asm/gic.h> >> > #include <asm/io.h> >> > >> > +static unsigned int read_cpsr(void) >> > +{ >> > + unsigned int reg; >> > + >> > + asm volatile ("mrs %0, cpsr\n" : "=r" (reg)); >> > + return reg; >> > +} >> > + >> > static unsigned int read_id_pfr1(void) >> > { >> > unsigned int reg; >> > @@ -110,16 +119,20 @@ static void kick_secondary_cpus(char *gicdptr) >> > writel(1U << 24, &gicdptr[GICD_SGIR]); >> > } >> > >> > -int armv7_switch_nonsec(void) >> > +int armv7_switch_hyp(void) >> > { >> > unsigned int reg, ret; >> > char *gicdptr; >> > unsigned itlinesnr, i; >> > >> > - /* check whether the CPU supports the security extensions */ >> > + /* check whether we are in HYP mode already */ >> > + if ((read_cpsr() & 0x1f) == 0x1a) >> > + return HYP_ERR_ALREADY_HYP_MODE; >> > + >> > + /* check whether the CPU supports the virtualization >> > extensions */ >> > reg = read_id_pfr1(); >> > - if ((reg & 0xF0) == 0) >> > - return HYP_ERR_NO_SEC_EXT; >> > + if ((reg & CPUID_ARM_VIRT_MASK) != 1 << >> CPUID_ARM_VIRT_SHIFT) >> > + return HYP_ERR_NO_VIRT_EXT; >> > >> > set_generic_timer_frequency(); >> > >> > @@ -147,8 +160,12 @@ int armv7_switch_nonsec(void) >> > >> > kick_secondary_cpus(gicdptr); >> > >> > - /* call the non-sec switching code on this CPU also */ >> > + /* call the HYP switching code on this CPU also */ >> > _nonsec_init(); >> > + _hyp_init(); >> > + >> > + if ((read_cpsr() & 0x1F) != 0x1a) >> > + return HYP_ERR_NOT_HYP_MODE; >> > >> > return 0; >> > } >> > -- >> > 1.7.12.1 >> > >> > _______________________________________________ >> > kvmarm mailing list >> > kvm...@lists.cs.columbia.edu <mailto:kvm...@lists.cs.columbia.edu> >> > https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm >> > >> > >> > regards, >> > Nikolay Nikolaev >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 25 Jun 2013 10:44:38 +0200 >> From: Lukasz Majewski <l.majew...@samsung.com> >> Subject: Re: [U-Boot] dfu: using dfu-util -l shows different output >> To: Heiko Schocher <h...@denx.de> >> Cc: Marek Vasut <ma...@denx.de>, "u-boot@lists.denx.de" >> <u-boot@lists.denx.de>, Kyungmin Park <kyungmin.p...@samsung.com >> >, >> Pantelis Antoniou <pa...@antoniou-consulting.com>, "Egli, >> Samuel" >> <samuel.e...@siemens.com> >> Message-ID: <20130625104438.2538a880@amdc308.digital.local> >> Content-Type: text/plain; charset=US-ASCII >> >> Hi Heiko, >> >> > Hello Pantelis, >> > >> > Am 25.06.2013 10:16, schrieb Pantelis Antoniou: >> > > Heiko, >> > > >> > > I don't think the gadget is initialized before you issue >> > > a dfu call. >> > > >> > > So that makes sense. >> > >> > ? >> > >> > I call from the host "dfu-util -l" so the gadget on the board >> > should do the answer ... or? >> >> The gadget is not initialized here (so the dfu-util -l shows no >> output). >> >> After transfer it shows information about proper alt settings. >> >> This is correct behaviour, but I had discussion about this with Tom and >> we agreed, that it would be nice to have "dfu-util -l" exporting from >> very beginning the alt setting information. >> >> Frankly, I had too much other work to implement it. >> >> However, I think, that it would be a very useful feature (e.g. to get >> alt settings layout at HOST to facilitate automated flashing). >> >> >> > >> > > Let's wait until Tom wakes up and have an authoritative answer. >> > >> > Ok! >> > >> > bye, >> > Heiko >> > >> > > >> > > Regards >> > > >> > > -- Pantelis >> > > >> > > On Jun 25, 2013, at 11:08 AM, Heiko Schocher wrote: >> > > >> > >> Hello, >> > >> >> > >> using "dfu-util -l" shows different output connecting to >> > >> an am335x based board and using dfu_nand.c with current >> > >> u-boot: >> > >> >> > >> after resetting the board I get: >> > >> >> > >> # dfu-util -l >> > >> dfu-util 0.5 >> > >> >> > >> (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. >> > >> (C) 2010-2011 Tormod Volden (DfuSe support) >> > >> This program is Free Software and has ABSOLUTELY NO WARRANTY >> > >> >> > >> dfu-util does currently only support DFU version 1.0 >> > >> >> > >> Found Runtime: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, >> > >> name="Device Firmware Upgrade" # >> > >> >> > >> after a dfu transfer I see: >> > >> >> > >> # dfu-util -l >> > >> dfu-util 0.5 >> > >> >> > >> (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. >> > >> (C) 2010-2011 Tormod Volden (DfuSe support) >> > >> This program is Free Software and has ABSOLUTELY NO WARRANTY >> > >> >> > >> dfu-util does currently only support DFU version 1.0 >> > >> >> > >> Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="SPL" >> > >> Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=1, >> > >> name="SPL.backup1" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, >> > >> alt=2, name="SPL.backup2" Found DFU: [0525:bd00] devnum=0, cfg=2, >> > >> intf=0, alt=3, name="SPL.backup3" Found DFU: [0525:bd00] devnum=0, >> > >> cfg=2, intf=0, alt=4, name="u-boot" Found DFU: [0525:bd00] >> > >> devnum=0, cfg=2, intf=0, alt=5, name="kernel_a" Found DFU: >> > >> [0525:bd00] devnum=0, cfg=2, intf=0, alt=6, name="kernel_b" Found >> > >> DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=7, name="rootfs" # >> > >> >> > >> Which I expected ... >> > >> >> > >> U-Boot environment variable: >> > >> >> > >> U-Boot# print dfu_alt_info >> > >> dfu_alt_info=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0 >> > >> 3;SPL.backup3 part 0 4;u-boot part 0 5;kernel_a part 0 7;kernel_b >> > >> part 0 8;rootfs part 0 10 U-Boot# >> > >> >> > >> Is this a bug or a feature? >> > >> >> > >> bye, >> > >> Heiko >> > >> -- >> > >> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev >> > >> Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 >> > >> Groebenzell, Germany >> > > >> > > >> > > >> > >> > >> >> >> >> -- >> Best regards, >> >> Lukasz Majewski >> >> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group >> >> >> ------------------------------ >> >> Message: 3 >> Date: Tue, 25 Jun 2013 10:55:14 +0200 >> From: Heiko Schocher <h...@denx.de> >> Subject: Re: [U-Boot] dfu: using dfu-util -l shows different output >> To: Lukasz Majewski <l.majew...@samsung.com> >> Cc: Marek Vasut <ma...@denx.de>, "u-boot@lists.denx.de" >> <u-boot@lists.denx.de>, Kyungmin Park <kyungmin.p...@samsung.com >> >, >> Pantelis Antoniou <pa...@antoniou-consulting.com>, "Egli, >> Samuel" >> <samuel.e...@siemens.com> >> Message-ID: <51c95af2.6030...@denx.de> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hello Lukasz, >> >> Am 25.06.2013 10:44, schrieb Lukasz Majewski: >> > Hi Heiko, >> > >> >> Hello Pantelis, >> >> >> >> Am 25.06.2013 10:16, schrieb Pantelis Antoniou: >> >>> Heiko, >> >>> >> >>> I don't think the gadget is initialized before you issue >> >>> a dfu call. >> >>> >> >>> So that makes sense. >> >> >> >> ? >> >> >> >> I call from the host "dfu-util -l" so the gadget on the board >> >> should do the answer ... or? >> > >> > The gadget is not initialized here (so the dfu-util -l shows no >> > output). >> > >> > After transfer it shows information about proper alt settings. >> > >> > This is correct behaviour, but I had discussion about this with Tom and >> > we agreed, that it would be nice to have "dfu-util -l" exporting from >> > very beginning the alt setting information. >> >> Yes, I vote for this too. Connecting to a board, I first >> would do a "dfu-util -l" to look, what is possible to >> update here ... >> >> > Frankly, I had too much other work to implement it. >> > >> > However, I think, that it would be a very useful feature (e.g. to get >> > alt settings layout at HOST to facilitate automated flashing). >> >> Hmm... I digged into the code, but not really found a place >> where I have to start. Can you give me a hint where to start? >> So maybe, I can do it? >> >> Thanks! >> >> bye, >> Heiko >> >>> Let's wait until Tom wakes up and have an authoritative answer. >> >> >> >> Ok! >> >> >> >> bye, >> >> Heiko >> >> >> >>> >> >>> Regards >> >>> >> >>> -- Pantelis >> >>> >> >>> On Jun 25, 2013, at 11:08 AM, Heiko Schocher wrote: >> >>> >> >>>> Hello, >> >>>> >> >>>> using "dfu-util -l" shows different output connecting to >> >>>> an am335x based board and using dfu_nand.c with current >> >>>> u-boot: >> >>>> >> >>>> after resetting the board I get: >> >>>> >> >>>> # dfu-util -l >> >>>> dfu-util 0.5 >> >>>> >> >>>> (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. >> >>>> (C) 2010-2011 Tormod Volden (DfuSe support) >> >>>> This program is Free Software and has ABSOLUTELY NO WARRANTY >> >>>> >> >>>> dfu-util does currently only support DFU version 1.0 >> >>>> >> >>>> Found Runtime: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, >> >>>> name="Device Firmware Upgrade" # >> >>>> >> >>>> after a dfu transfer I see: >> >>>> >> >>>> # dfu-util -l >> >>>> dfu-util 0.5 >> >>>> >> >>>> (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. >> >>>> (C) 2010-2011 Tormod Volden (DfuSe support) >> >>>> This program is Free Software and has ABSOLUTELY NO WARRANTY >> >>>> >> >>>> dfu-util does currently only support DFU version 1.0 >> >>>> >> >>>> Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="SPL" >> >>>> Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=1, >> >>>> name="SPL.backup1" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, >> >>>> alt=2, name="SPL.backup2" Found DFU: [0525:bd00] devnum=0, cfg=2, >> >>>> intf=0, alt=3, name="SPL.backup3" Found DFU: [0525:bd00] devnum=0, >> >>>> cfg=2, intf=0, alt=4, name="u-boot" Found DFU: [0525:bd00] >> >>>> devnum=0, cfg=2, intf=0, alt=5, name="kernel_a" Found DFU: >> >>>> [0525:bd00] devnum=0, cfg=2, intf=0, alt=6, name="kernel_b" Found >> >>>> DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=7, name="rootfs" # >> >>>> >> >>>> Which I expected ... >> >>>> >> >>>> U-Boot environment variable: >> >>>> >> >>>> U-Boot# print dfu_alt_info >> >>>> dfu_alt_info=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0 >> >>>> 3;SPL.backup3 part 0 4;u-boot part 0 5;kernel_a part 0 7;kernel_b >> >>>> part 0 8;rootfs part 0 10 U-Boot# >> >>>> >> >>>> Is this a bug or a feature? >> >>>> >> >>>> bye, >> >>>> Heiko >> >>>> -- >> >>>> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev >> >>>> Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 >> >>>> Groebenzell, Germany >> >>> >> >>> >> >>> >> >> >> >> >> > >> > >> > >> >> >> -- >> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel >> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany >> >> >> ------------------------------ >> >> Message: 4 >> Date: Tue, 25 Jun 2013 11:42:53 +0200 >> From: Sascha Silbe <t-ub...@infra-silbe.de> >> Subject: Re: [U-Boot] [PATCH] OpenRD: relocate environment to 640kB >> To: Albert ARIBAUD <albert.u.b...@aribaud.net> >> Cc: Tom Rini <tr...@ti.com>, u-boot@lists.denx.de >> Message-ID: <toeppvail0i....@twin.sascha.silbe.org> >> Content-Type: text/plain; charset="us-ascii" >> >> Hello Albert, hello Tom, >> >> Albert ARIBAUD <albert.u.b...@aribaud.net> writes: >> >> [Move environment to account for increase in U-Boot size] >> > This patch is for 2013.10, not 2013.07, but I prefer raising the issue >> > as early as possible. >> > >> > If there is no way to make things smoother, then I think the 2013.10 >> > release notes should contain a red, blinking, paragraph about this. I >> > would *hate* it if people were not warned and given a method to port >> > their current environment setting over. >> > >> > Possibly even, the 2013.07 could have a warning about the change to >> > come, so that people have a better chance yet to prepare for the >> > change. >> >> The situation has gotten better recently and U-Boot fits into the >> previous partition size of 384KiB again. So it isn't broken on OpenRD >> anymore and the above would seem like a good approach. >> >> Where are the U-Boot Release Notes located? Who is responsible for >> editing them? >> >> Sascha >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: not available >> Type: application/pgp-signature >> Size: 489 bytes >> Desc: not available >> URL: < >> http://lists.denx.de/pipermail/u-boot/attachments/20130625/0dfd227e/attachment-0001.pgp >> > >> >> ------------------------------ >> >> _______________________________________________ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >> >> >> End of U-Boot Digest, Vol 61, Issue 36 >> ************************************** >> > >
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot