Dear Marek Vasut,
In message <201010040136.27940.marek.va...@gmail.com> you wrote:
> Dne Po 20. zá#í 2010 03:57:25 Marek Vasut napsal(a):
> > This fixes TIMEOUT with my Kingston 32GB USB3.0 flashdrive, which I
> > experienced on my PXA270 (USB 1.1) Vpac270 board.
>
> CC Remy
How do you expoect t
Hi Wolfgang,
> Well, please keep in mind that all this code is working find on
> PowerPC, which has been using relocation right from the beginning.
>
> It is my understanding that we don't suffer from this issue any more
> on PPC - Peter Tyser posted relocation fixup patches for PPC about a
> y
u-boot.bin can be loaded at any 4-byte aligned memory location and directly
'jumped' to using the 'go' command using the load address as the start
address. Doing so performs a 'warm boot' which skips memory initialisation
and other low-level initialisations, relocates U-Boot to upper memory and
sta
Provides a small speed increase and prepares for fully relocatable image.
Downside is the TEXT_BASE, bss, load address etc must ALL be aligned on a
a 4-byte boundary which is not such a terrible restriction as everything
is already 4-byte aligned anyway
Signed-off-by: Graeme Russ
---
arch/i386/l
Tidy up the linker script and discard some sections to save space
Signed-off-by: Graeme Russ
---
arch/i386/lib/board.c |5 +++--
board/eNET/u-boot.lds | 39 ++-
2 files changed, 21 insertions(+), 23 deletions(-)
diff --git a/arch/i386/lib/board.c b/arch
Create more generic names for the symbols exported from the linker script
Signed-off-by: Graeme Russ
---
arch/i386/lib/bios_setup.c | 14 +++---
arch/i386/lib/board.c | 20 ++--
arch/i386/lib/realmode.c | 14 +++---
board/eNET/u-boot.lds | 21 +
Signed-off-by: Graeme Russ
---
arch/i386/cpu/start.S | 19 ++-
arch/i386/cpu/start16.S |7 ---
arch/i386/include/asm/global_data.h |3 +++
3 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/arch/i386/cpu/start.S b/arch/i386/cp
By reserving space for the Global Data immediately below the stack during
assembly level initialisation, the C declaration of the static global data
can be removed, along with the 'RAM Bootstrap' function. This results in
cleaner code, and the ability to pass boot-up flags from assembler into C
Si
%ebx will hold low-level boot flags and must be preserved
Signed-off-by: Graeme Russ
---
arch/i386/cpu/sc520/sc520_asm.S | 15 ++-
arch/i386/cpu/start.S |4 ++--
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/i386/cpu/sc520/sc520_asm.S b/arch/i38
By using another register, reduce code size by one instruction
Signed-off-by: Graeme Russ
---
arch/i386/cpu/start.S |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/i386/cpu/start.S b/arch/i386/cpu/start.S
index 247b120..045b51e 100644
--- a/arch/i386/cpu/start.S
Using %ebp as a return pointer prevents creating 'load anywhere' images
Signed-off-by: Graeme Russ
---
arch/i386/cpu/sc520/sc520_asm.S |6 +++---
arch/i386/cpu/start.S | 10 +-
arch/i386/cpu/start16.S |2 +-
board/eNET/eNET_start.S |2 +-
board/eNE
To allow for 'load anywhere' images, the %ebp return pointer 'hack' must
be removed, so we cannot have two 'calls' to get_mem_size
Signed-off-by: Graeme Russ
---
arch/i386/cpu/sc520/sc520_asm.S | 17 +++--
arch/i386/cpu/start.S | 11 +++
2 files changed, 14 inse
Progress indication is not relocation friendly so remove it in
preperation for full relocatability support
Signed-off-by: Graeme Russ
---
arch/i386/cpu/start.S | 44 ++--
board/eNET/eNET_start.S | 12
2 files changed, 2 insertions(+), 54
Perform some basic code cleanups of the x86 files
Signed-off-by: Graeme Russ
---
arch/i386/cpu/sc520/sc520.c | 54 ++--
arch/i386/cpu/sc520/sc520_asm.S | 642 +++
arch/i386/cpu/start.S | 30 +-
arch/i386/cpu/start16.S |9 +-
4 fi
Signed-off-by: Graeme Russ
---
arch/i386/cpu/interrupts.c| 23 +++
arch/i386/include/asm/interrupt.h |2 ++
arch/i386/include/asm/ptrace.h| 24
3 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/arch/i386/cpu/interrupt
Change to:
- reparam=3
- no-from-pointer
- no-stack-protector
- preferred-stack-boundary=2
- no-top-level-reorder
These options make the code a little smaller and faster
Signed-off-by: Graeme Russ
---
arch/i386/config.mk |8
arch/i386/cpu/interrupts.c|
Linux has C macros and code to load the GTD after switching to Protected
Mode. Using these greatly simplifies the assembler code
Signed-off-by: Graeme Russ
---
arch/i386/cpu/cpu.c | 57 +
arch/i386/cpu/start.S | 96 ---
Follow the discussion of Charles Manning and Mike Frysinger.
Using gc_sections helps reduce image size.
Signed-off-by: Graeme Russ
---
arch/i386/config.mk |3 +++
board/eNET/u-boot.lds | 10 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/i386/config.mk b/a
The header of recent Linux Kernels includes the size of the image, and
therefore is not needed to be passed to zboot. Still process the third
parameter (size of image) in the event that an older kernel is being loaded
Signed-off-by: Graeme Russ
---
arch/i386/lib/zimage.c | 18 +
Use TEXT_BASE rather than a hard-coded base address on x86 linker scripts.
This will allow any board to define its base link address without having
to modify the linker script
Signed-off-by: Graeme Russ
---
board/eNET/u-boot.lds |8
1 files changed, 4 insertions(+), 4 deletions(-)
Relocation is not board-specific for the x86 architectrure, so
CONFIG_RELOC_FIXUP_WORKS can be defined globally in the config.h
Signed-off-by: Graeme Russ
---
arch/i386/include/asm/config.h |2 ++
include/configs/eNET.h |2 --
2 files changed, 2 insertions(+), 2 deletions(-)
dif
Hi All,
I have finally achieved my goal of creating a fully relocatable u-boot.bin
image. What this means is that U-Boot can be build for any TEXT_BASE and
loaded at any RAM address (see caveat 2 below) and executed using the 'go'
command. U-Boot will relocate to upper memory and run as if loaded
Dne Po 4. října 2010 01:45:16 Kyungmin Park napsal(a):
> Hi,
>
> There's no OneNAND tree but all patches are mainlined by Scott Wood's tree.
>
> And related with patch. I wonder why it's problem with your board?
>
> As it's function pointer. It should be located the data section and it's
> assig
Dne So 2. října 2010 19:33:56 Marek Vasut napsal(a):
> This moves "struct nand_bbt_descr largepage_memorybased" into
> "onenand_default_bbt" as that's the only place where this is used.
>
> This also removes an entry from .data section. (For me, this section
> disappears after relocation).
Scott,
Hi,
There's no OneNAND tree but all patches are mainlined by Scott Wood's tree.
And related with patch. I wonder why it's problem with your board?
As it's function pointer. It should be located the data section and it's
assigned at runtime.
Maybe your board runs the code at OneNAND directly. I
Dne Po 20. září 2010 03:57:25 Marek Vasut napsal(a):
> This fixes TIMEOUT with my Kingston 32GB USB3.0 flashdrive, which I
> experienced on my PXA270 (USB 1.1) Vpac270 board.
CC Remy
>
> Signed-off-by: Marek Vasut
> ---
> drivers/usb/host/ohci-hcd.c |2 +-
> 1 files changed, 1 insertions(+)
Dne Ne 3. října 2010 16:27:04 Marek Vasut napsal(a):
> Dne Ne 3. října 2010 08:40:19 Kyungmin Park napsal(a):
> > Hi,
> >
> > No it's used another place. that's reason not static function pointer.
> > I'll update it soon.
>
> Hey, my problem is this code hangs my CPU. If I apply this patch, it
>
There are some boards where it's not currently possible to detect all board
information at runtime, therefore I introduced a new column called "options" to
boards.cfg .
This column can contain multiple options, separated by comma [,] . In case
there's a simple options like 256M_U_BOOT, it's plain
On Sunday, October 03, 2010 17:40:32 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > Would it not be esier to rename your nand_delayed_init() into
> > > nand_init(), and add a "#ifndef CONFIG_SYS_NAND_DELAYED_INIT" around
> > > the current call to nand_init()?
> >
> > nand_init() cant handle be
Dear Mike Frysinger,
In message <201010031632.47732.vap...@gentoo.org> you wrote:
>
> > Would it not be esier to rename your nand_delayed_init() into
> > nand_init(), and add a "#ifndef CONFIG_SYS_NAND_DELAYED_INIT" around
> > the current call to nand_init()?
>
> nand_init() cant handle being call
Dear Marek Vasut,
In message <1286140454-19572-1-git-send-email-marek.va...@gmail.com> you wrote:
> With this implementation, the sentinel character in TARGET name is interpreted
> as an option and expanded to CONFIG_MK_xxx.
>
> Signed-off-by: Marek Vasut
> ---
> v2: Use comma, permit assignment
Dear Marek Vasut,
In message <201010032124.29154.marek.va...@gmail.com> you wrote:
>
> > > Oh, I'm sorry, I haven't noticed. Please merge whichever you find more
> > > suitable.
> >
> > NAK!
> >
> > I want to see this fixed at the base, not by adding workarounds.
> >
> > Best regards,
> >
> >
With this implementation, the sentinel character in TARGET name is interpreted
as an option and expanded to CONFIG_MK_xxx.
Signed-off-by: Marek Vasut
---
v2: Use comma, permit assignment
boards.cfg |1 +
mkconfig | 10 +++---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --
On Sunday, October 03, 2010 14:27:13 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > Many people like the current nand_init() behavior where it is always
> > initialized during boot and the flash size shown, but there are cases
> > where we are willing to forgo this niceness for speed/functionalit
Dear Marek Vasut,
In message <1286123674-13461-3-git-send-email-marek.va...@gmail.com> you wrote:
> Signed-off-by: Marek Vasut
> ---
> Makefile|8
> board/trizepsiv/conxs.c |2 +-
> boards.cfg |2 ++
> include/configs/trizepsiv.h |
Dear Marek Vasut,
In message <1286123674-13461-2-git-send-email-marek.va...@gmail.com> you wrote:
> Signed-off-by: Marek Vasut
> ---
> Makefile | 16
> board/vpac270/vpac270.c |2 +-
> boards.cfg|3 +++
> include/configs/vpac270.h |
Dear Marek Vasut,
In message <1286123674-13461-1-git-send-email-marek.va...@gmail.com> you wrote:
> With this implementation, the sentinel character in TARGET name is interpreted
> as an option and expanded to CONFIG_MK_xxx.
Sorry, but this is not the implementation we discussed in the past.
I k
Le 03/10/2010 20:54, J. William Campbell a écrit :
> Agreed. This should be possible to do now that there is a better
> understanding of the ELF format by the u-boot community. Perhaps the
> place to start would be trying to port what Graeme has done to ARM or
> perhaps better yet, PPC. Since lots
On 10/3/2010 11:29 AM, Wolfgang Denk wrote:
> Dear Reinhard Meyer,
>
> In message<4ca79896.2010...@emk-elektronik.de> you wrote:
>> I agree here. _If_ relocation, it should work without hand-adding
>> fixup stuff to all functions using initialized data with pointers.
>> Even Wolfgang forgot to f
Dne Ne 3. října 2010 20:21:33 Wolfgang Denk napsal(a):
> Dear Marek Vasut,
>
> In message <201010022059.53303.marek.va...@gmail.com> you wrote:
> > > I've prepared same patch. :)
> >
> > Oh, I'm sorry, I haven't noticed. Please merge whichever you find more
> > suitable.
>
> NAK!
>
> I want to
On 10/3/2010 11:14 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4ca75bfb.5030...@comcast.net> you wrote:
> And I think there are more places of this type in u-boot...
Yes, maybe. But relocation as I did for arm, also works
on m68k, sparc, mips, avr32 and th
Dear Albert ARIBAUD,
In message <4ca8ccc1.2010...@free.fr> you wrote:
>
> > Well, please keep in mind that all this code is working find on
> > PowerPC, which has been using relocation right from the beginning.
>
> I don't mean to say that PPC relocation does not work; I mean to say
> that a m
Dear "J. William Campbell",
In message <4ca8a2e0.7090...@comcast.net> you wrote:
>
> executable instructions than programs compiled without these options.
> The program will also contain more data space for the got. If -fPIC
> actually produced a fully position-independent executable, the extra
>
Dear Marek Vasut,
In message <201010031625.00339.marek.va...@gmail.com> you wrote:
> > > +#ifndef CONFIG_RELOC_FIXUP_WORKS
> > > +void onenand_reloc(void) {
> >
> > { should be on a separate line.
> >
> > WBR, Sergei
>
> Fixed in my tree, thanks!
Keep in mind that "your tree" is totally un
Dear "Hiremath, Vaibhav",
In message <19f8576c6e063c45be387c64729e739404aa21c...@dbde02.ent.ti.com> you
wrote:
>
> > Note that adding the definition may not be sufficient to get relocation
> > working.
> >
> [Hiremath, Vaibhav] But atleast it will make code to compile cleanly. I feel,
> at any c
Le 03/10/2010 20:03, Wolfgang Denk a écrit :
> Dear Reinhard Meyer,
>
> In message<4ca6e8e5.2090...@emk-elektronik.de> you wrote:
>>
>>> And yes, this means the content arrays of pointers such as init_sequence
>>> is not relocated. Been there, done that, can give you one of the
>>> tee-shirts I g
Dear Reinhard Meyer,
In message <4ca79896.2010...@emk-elektronik.de> you wrote:
>
> I agree here. _If_ relocation, it should work without hand-adding
> fixup stuff to all functions using initialized data with pointers.
> Even Wolfgang forgot to fixup his 2nd level command table in
> cmd_nvedit.c ;
Dear Mike Frysinger,
In message <1286048840-1901-1-git-send-email-vap...@gentoo.org> you wrote:
> Many people like the current nand_init() behavior where it is always
> initialized during boot and the flash size shown, but there are cases
> where we are willing to forgo this niceness for speed/fun
Dear Reinhard Meyer,
In message <4ca77afa.2090...@emk-elektronik.de> you wrote:
>
> My AT91 boards will not use relocation for the time being, and if
> relocation is god-like enforced I will find a way not to use it.
> I don't need to spend 10% more code for all that trouble.
Please see
http://a
Dear Marek Vasut,
In message <201010022059.53303.marek.va...@gmail.com> you wrote:
>
> > I've prepared same patch. :)
>
> Oh, I'm sorry, I haven't noticed. Please merge whichever you find more
> suitable.
NAK!
I want to see this fixed at the base, not by adding workarounds.
Best regards,
Wolf
Dear "J. William Campbell",
In message <4ca75bfb.5030...@comcast.net> you wrote:
>
> >>> And I think there are more places of this type in u-boot...
> >> Yes, maybe. But relocation as I did for arm, also works
> >> on m68k, sparc, mips, avr32 and they must do also this
> >> fixups, so for common f
Dear Marek Vasut,
In message <1286029567-30231-1-git-send-email-marek.va...@gmail.com> you wrote:
> This moves "struct nand_bbt_descr largepage_memorybased" into .data.rel, which
> allows it to be PIC with current U-Boot infrastructure for relocation.
>
> Also, I squished the ff_patternt into the
Dear Albert ARIBAUD,
In message <4ca6fb7e.3070...@free.fr> you wrote:
>
> >>> Short answer - the relocation process does not handle pointers inside
> >>> data structures.
> >>>
> >>> And yes, this means the content arrays of pointers such as init_sequence
> >>> is not relocated. Been there, done
Dear Albert ARIBAUD,
In message <4ca6ec99.5080...@free.fr> you wrote:
>
> There are two ways to fix that:
...
We should find the third way, which is that the tools actually
incude these pointers into the GOT so they get relocated
automatically.
Best regards,
Wolfgang Denk
--
DENX Software Eng
Dear Reinhard Meyer,
In message <4ca6e8e5.2090...@emk-elektronik.de> you wrote:
>
> > And yes, this means the content arrays of pointers such as init_sequence
> > is not relocated. Been there, done that, can give you one of the
> > tee-shirts I got :)
It should work.
Eventually we need to find o
Le 03/10/2010 18:47, Albert ARIBAUD a écrit :
> But the .rel.dyn generated by the linker section does not provide
> symbols to mark its start and end, and I have found no documentation in
> binutils ld which would describe how to rewrite the .rel.dyn section and
> add these symbols myself.
>
> How
Le 03/10/2010 17:36, J. William Campbell a écrit :
> Hi All,
> It is for sure that -fPIC/-fPIE programs will contain more executable
> instructions than programs compiled without these options.
> The program will also contain more data space for the got. If -fPIC
> actually produced a fully positi
Dne Ne 3. října 2010 18:34:34 Marek Vasut napsal(a):
> Signed-off-by: Marek Vasut
Missing MAKEALL entry removal handled in my tree ... will push this with a
final
version.
> ---
> Makefile|8
> board/trizepsiv/conxs.c |2 +-
> boards.cfg
Signed-off-by: Marek Vasut
---
Makefile|8
board/trizepsiv/conxs.c |2 +-
boards.cfg |2 ++
include/configs/trizepsiv.h |6 +++---
4 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/Makefile b/Makefile
index 59067ee..0
Signed-off-by: Marek Vasut
---
Makefile | 16
board/vpac270/vpac270.c |2 +-
boards.cfg|3 +++
include/configs/vpac270.h | 12 ++--
4 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/Makefile b/Makefile
index 92
With this implementation, the sentinel character in TARGET name is interpreted
as an option and expanded to CONFIG_MK_xxx.
Signed-off-by: Marek Vasut
---
boards.cfg |1 +
mkconfig |7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/boards.cfg b/boards.cfg
index 6
On 10/3/2010 1:58 AM, Albert ARIBAUD wrote:
> Le 03/10/2010 10:44, Graeme Russ a écrit :
>
>>> Bill just said that -pic (or, for ARM, -fPIC or -fPIE) was unnecessary
>>> for relocation. You seem to imply it actually is... In my experience,
>>> -fPIC and-fPIE do increase code by adding GOT relocat
Greetings,
An update on the blob vs u-boot problems Im having. I noticed that driving
UART3 > 19200
on blob caused the same kind of issues that Im seeing in u-boot.
But downgrading baud = 19200 works in u-boot, but when booting kernel
I instead get scrambled data (which looks like wrong baud). I
Dne Ne 3. října 2010 08:40:19 Kyungmin Park napsal(a):
> Hi,
>
> No it's used another place. that's reason not static function pointer.
> I'll update it soon.
Hey, my problem is this code hangs my CPU. If I apply this patch, it doesn't
happen anymore.
Where is this used and what's your proposed
Dne Ne 3. října 2010 08:40:55 Kyungmin Park napsal(a):
> Acked-by: Kyungmin Park
Added in my tree to commit message, Thanks!
>
> On Sun, Oct 3, 2010 at 2:33 AM, Marek Vasut wrote:
> > This allows to specify where the OneNAND IPL should load the U-Boot
> > binary. The purpose of CONFIG_SYS_LOAD_
Dne Ne 3. října 2010 13:19:21 Sergei Shtylyov napsal(a):
> Hello.
>
> On 02-10-2010 21:33, Marek Vasut wrote:
> > Signed-off-by: Marek Vasut
>
> [...]
>
> > diff --git a/common/cmd_onenand.c b/common/cmd_onenand.c
> > index 83d967b..fe84c3b 100644
> > --- a/common/cmd_onenand.c
> > +++ b/common
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Albert ARIBAUD
> Sent: Sunday, October 03, 2010 4:37 PM
> To: u-boot@lists.denx.de
> Subject: Re: [U-Boot] denx/master is not building for OMAP3 platforms
> except Beagle
>
> Le
Hello.
On 02-10-2010 21:33, Marek Vasut wrote:
> Signed-off-by: Marek Vasut
[...]
> diff --git a/common/cmd_onenand.c b/common/cmd_onenand.c
> index 83d967b..fe84c3b 100644
> --- a/common/cmd_onenand.c
> +++ b/common/cmd_onenand.c
> @@ -525,6 +525,12 @@ static cmd_tbl_t cmd_onenand_sub[] = {
>
Le 03/10/2010 12:50, Hiremath, Vaibhav a écrit :
> Hi All,
>
> I think the current denx/matser is broken and is not building up for OMAP3
> platforms except Beagle board.
>
> The error message on build is -
>
> board.c: In function '__dram_init_banksize':
> board.c:468: error: 'CONFIG_SYS_SDRAM_BA
Hi All,
I think the current denx/matser is broken and is not building up for OMAP3
platforms except Beagle board.
The error message on build is -
board.c: In function '__dram_init_banksize':
board.c:468: error: 'CONFIG_SYS_SDRAM_BASE' undeclared (first use in this
function)
board.c:468: error
Greetings,
Ive extended my bugsearching to find out why I cant get
everything working on my hp jornada flashrom (sa1110 + sa).
Im testing exactly same kernel(2.6.34) for both bootloaders so I know
the difference is in the bootloaders.
In short:
Blob works perfectly fine with bootloader and b
Le 03/10/2010 10:44, Graeme Russ a écrit :
>> Bill just said that -pic (or, for ARM, -fPIC or -fPIE) was unnecessary
>> for relocation. You seem to imply it actually is... In my experience,
>> -fPIC and-fPIE do increase code by adding GOT relocation to symbols that
>> need fixing, so they would in
On 03/10/10 18:10, Albert ARIBAUD wrote:
> Le 03/10/2010 01:07, Graeme Russ a écrit :
>> On 03/10/10 08:09, Albert ARIBAUD wrote:
>>> Le 02/10/2010 22:39, Reinhard Meyer a écrit :
>>>
And as an idea, if position independent code is used, only pointers
in initialized data need adjustment.
Le 03/10/2010 01:07, Graeme Russ a écrit :
> On 03/10/10 08:09, Albert ARIBAUD wrote:
>> Le 02/10/2010 22:39, Reinhard Meyer a écrit :
>>
>>> And as an idea, if position independent code is used, only pointers
>>> in initialized data need adjustment. Cannot the linker emit a table
>>> of addresses
74 matches
Mail list logo
