Hi Andreas,
Le 04/11/2010 00:29, Andreas Bießmann a écrit :
This is mostly a copy of arm926ejs relocation and known to _not_ work
correctly a.t.m!
Can you give a specific case of board and toolchain that does not work?
Amicalement,
--
Albert.
___
Andre Schwarz andre.schw...@matrix-vision.de wrote on 2010/10/25 15:50:19:
Jocke,
[snip]
You still haven't reported weather the 4 nop's helped or not, yet you
seek my help. I am just going to ignore you until you do test it.
finally I got both some time and hardware :
4 nops after
Dear Andre Schwarz,
In message 4cc58b1b.8040...@matrix-vision.de you wrote:
Diffing both System.maps and U-Boot hexdump gives only trivial results :
- in_flash and _start_of_vectors adress increment = 0x10.
Hey, stop here.
How can _start_of_vectors shift? It i supposed to be at a fixed
Improved default config for OMAP4 Pandaboard for faster boot:
-reduced environment size to speed up memory initialization;
-USB TTY driver turned off;
-tweaked blob load address to avoid image relocation (according to
default uImage load address);
Signed-off-by: Sergiy
Dear Joakim Tjernlund,
In message
of5324ec0a.37c044b2-onc12577d1.0031f002-c12577d1.00326...@transmode.se you
wrote:
4 nops after _start does the trick, i.e. the board is up and running fine.
...
How is this going? If nothing else I think you should send
a patch for 83xx, adding the 4 nop's
Jocke,
[snip]
finally I got both some time and hardware :
4 nops after _start does the trick, i.e. the board is up and running fine.
Diffing both System.maps and U-Boot hexdump gives only trivial results :
- in_flash and _start_of_vectors adress increment = 0x10.
- offset calculation for
Hello,
The patch attached add support for a flash bank size of 16 MB and for a second
DRAM bank for the KS8695 (ARM9 core) depending on the configuration.
A better solution would be to calculate the values for the registers (only some
shifts are needed) but this was the lazy implementation.
I
Hello,
Because the Ethernet driver of the KS8695 reads his MAC from a fixed address, I
changed this driver to use the MAC from the environment like it was mentioned
in the docs.
The second patch in the patch set adds support for the new net multi api.
Sadly, the Ethernet driver has one
Hello,
Use MAC from the environment instead of read a hard coded address in the
ethernet driver of the KS8695.
Signed-off-by: Michael Bernstein michael.bernst...@controlware.de
---
diff --unified --recursive --new-file u-boot-2009.11/drivers/net/ks8695eth.c
Hello,
Add support for the new NET MULTI api in the ethernet driver of the KS8695.
Signed-off-by: Michael Bernstein michael.bernst...@controlware.de
---
diff --unified --recursive --new-file u-boot-2009.11/drivers/net/ks8695eth.c
u-boot-2009.11.new/drivers/net/ks8695eth.c
---
Hi Albert,
Am 04.11.2010 07:14, schrieb Albert ARIBAUD:
Hi Andreas,
Le 04/11/2010 00:29, Andreas Bießmann a écrit :
This is mostly a copy of arm926ejs relocation and known to _not_ work
correctly a.t.m!
Can you give a specific case of board and toolchain that does not work?
Wolfgang Denk w...@denx.de wrote on 2010/11/04 10:50:38:
Dear Andre Schwarz,
In message 4cc58b1b.8040...@matrix-vision.de you wrote:
Diffing both System.maps and U-Boot hexdump gives only trivial results :
- in_flash and _start_of_vectors adress increment = 0x10.
Hey, stop here.
I've just tested that patch using my small test-patch:
---
Marvell g 0x70
## Starting application at 0x0070 ...
U-Boot 2010.12-rc1-00037-g0ab2006 (Nov 04 2010 - 11:14:24)
Seagate-DockStar
SoC: Kirkwood 88F6281_A0
DRAM: 128 MiB
Dear all,
Am 04.11.2010 02:23, schrieb Joakim Tjernlund:
Graeme Russ graeme.r...@gmail.com wrote on 2010/11/04 02:13:44:
On Thu, Nov 4, 2010 at 12:00 PM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
The arm920t compiler/linker dif not handle weak functions correctely.
Therefore
Am 04.11.2010 11:26, schrieb Alexander Holler:
I've just tested that patch using my small test-patch:
---
Marvell g 0x70
## Starting application at 0x0070 ...
U-Boot 2010.12-rc1-00037-g0ab2006 (Nov 04 2010 - 11:14:24)
Wolfgang Denk w...@denx.de wrote on 2010/11/04 10:57:42:
Dear Joakim Tjernlund,
In message
of5324ec0a.37c044b2-onc12577d1.0031f002-c12577d1.00326...@transmode.se you
wrote:
4 nops after _start does the trick, i.e. the board is up and running fine.
...
How is this going? If nothing
Dear Sebastien Carlier,
Am 04.11.2010 04:27, schrieb Sebastien Carlier:
These weakly defined empty functions prevent the strong definition
from being linked in.
For example, libarm.a contains a weak symbol 'red_LED_on', which is
expected to be defined (strongly) in the board library.
Wolfgang Denk w...@denx.de wrote on 2010/11/04 10:57:42:
Dear Joakim Tjernlund,
In message
of5324ec0a.37c044b2-onc12577d1.0031f002-c12577d1.00326...@transmode.se
you wrote:
4 nops after _start does the trick, i.e. the board is up and running
fine.
...
How is this
Dear Joakim Tjernlund schrieb:
no, the nops has to be directly after _start:
. = EXC_OFF_SYS_RESET
.globl _start
_start: /* time t 0 */
nop
nop
nop
nop
My theory is that e300c2(no FPU) CPUs configured for low
boot vector, 0x100, really uses 0x110
Andy Pont andy.p...@sdcsystems.com wrote on 2010/11/04 11:58:19:
Joakim wrote...
Sure, but until freescale or someone else with eq. and motivation
researches it, we are stuck. I am not sure anyone else has tried
83xx based boards yet. If someone has please report. Also
include weather
On Thu, Nov 4, 2010 at 11:54 AM, Andreas Bießmann
andreas.de...@googlemail.com wrote:
---8---
__LIBS := $(subst $(obj),,$(LIBBOARD)) $(subst $(obj),,$(LIBS))
---8---
Still, why would the linker pull definitions from libboard.a? Library
archive are only searched by the linker to resolved
Joakim wrote...
Sure, but until freescale or someone else with eq. and motivation
researches it, we are stuck. I am not sure anyone else has tried
83xx based boards yet. If someone has please report. Also
include weather booted from NAND or NOR, CPU type(e300cX) and
what reset vector is
Dear Joakim Tjernlund,
In message
of4390b64d.1fbd6276-onc12577d1.003bb658-c12577d1.003bf...@transmode.se you
wrote:
hmm, what if a board decides to do a soft reset anyway, perhaps by mistake.
Would it not be a good thing if u-boot could handle that too?
What exactly is a soft reset in
Andy,
Sure, but until freescale or someone else with eq. and motivation
researches it, we are stuck. I am not sure anyone else has tried
83xx based boards yet. If someone has please report. Also
include weather booted from NAND or NOR, CPU type(e300cX) and
what reset vector is used.
I
Andre Schwarz andre.schw...@matrix-vision.de wrote on 2010/11/04 13:14:37:
Andy,
Sure, but until freescale or someone else with eq. and motivation
researches it, we are stuck. I am not sure anyone else has tried
83xx based boards yet. If someone has please report. Also
include weather
Wolfgang Denk w...@denx.de wrote on 2010/11/04 12:16:31:
Dear Joakim Tjernlund,
In message
of4390b64d.1fbd6276-onc12577d1.003bb658-c12577d1.003bf...@transmode.se you
wrote:
hmm, what if a board decides to do a soft reset anyway, perhaps by mistake.
Would it not be a good thing if
Andy,
Sure, but until freescale or someone else with eq. and motivation
researches it, we are stuck. I am not sure anyone else has tried
83xx based boards yet. If someone has please report. Also
include weather booted from NAND or NOR, CPU type(e300cX) and
what reset vector is used.
Le 04/11/2010 11:15, Andreas Bießmann a écrit :
Can you give a specific case of board and toolchain that does not work?
at91rm9200ek_ram_config (patch sent these days, is at91rm9200ek_config
with TEXT_BASE in RAM and SKIP_LOWLEVEL_INIT set). Toolchain was a
selfbuilt gcc-4.5.1 + binutils
Le 04/11/2010 11:46, Alexander Holler a écrit :
So the suggested change from Steve Sakoman (reordered fix from Albert
Aribaud) still seems to be the one to prefer.
Something is wrong here:
- .rel.dyn : { *(.rel.dyn) }
+ .rel.dyn : { *(.rel.*) }
This change is the same as the one
Dear Joakim Tjernlund,
In message
of18ca6215.dc3a539b-onc12577d1.00439a8b-c12577d1.0043b...@transmode.se you
wrote:
What exactly is a soft reset in U-Boot? And how would you perform
one?
Not in u-boot, but Linux or a privileged linux app. could.
Could do what? Modify the memory map
Am 04.11.2010 13:40, schrieb Albert ARIBAUD:
Le 04/11/2010 11:46, Alexander Holler a écrit :
So the suggested change from Steve Sakoman (reordered fix from Albert
Aribaud) still seems to be the one to prefer.
Something is wrong here:
- .rel.dyn : { *(.rel.dyn) }
+ .rel.dyn : { *(.rel.*) }
Le 04/11/2010 13:47, Alexander Holler a écrit :
Am 04.11.2010 13:40, schrieb Albert ARIBAUD:
Le 04/11/2010 11:46, Alexander Holler a écrit :
So the suggested change from Steve Sakoman (reordered fix from Albert
Aribaud) still seems to be the one to prefer.
Something is wrong here:
-
Wolfgang Denk w...@denx.de wrote on 2010/11/04 13:46:17:
Dear Joakim Tjernlund,
In message
of18ca6215.dc3a539b-onc12577d1.00439a8b-c12577d1.0043b...@transmode.se you
wrote:
What exactly is a soft reset in U-Boot? And how would you perform
one?
Not in u-boot, but Linux or a
Andre Schwarz andre.schw...@matrix-vision.de wrote on 2010/11/04 13:28:27:
Andy,
Sure, but until freescale or someone else with eq. and motivation
researches it, we are stuck. I am not sure anyone else has tried
83xx based boards yet. If someone has please report. Also
include
Dear Joakim Tjernlund,
In message
of51547b77.f521dbce-onc12577d1.0046eb0d-c12577d1.00474...@transmode.se you
wrote:
Could do what? Modify the memory map such that the Flash is mapped
Issue an soft reset somehow. Don't know how but I guessing it is possible?
If so the CPU would use reset
Wolfgang Denk w...@denx.de wrote on 2010/11/04 14:07:50:
Dear Joakim Tjernlund,
In message
of51547b77.f521dbce-onc12577d1.0046eb0d-c12577d1.00474...@transmode.se you
wrote:
Could do what? Modify the memory map such that the Flash is mapped
Issue an soft reset somehow. Don't know
Am 04.11.2010 13:55, schrieb Albert ARIBAUD:
Then please do test this V3 patch and verify if the issues you raise
still apply or are fixed.
V3 failed using my relocation-test-patch (and resulted in the same
problems as without any relocation patch). Therefor I've posted the
output. I though
Jocke,
[snip]
still -E_TOO_LITTLE_INFO:
sorry - thought it was clear already.
include weather booted from NAND or NOR, CPU type(e300cX) and
what reset vector is used.
CPU: e300c4, MPC8379, Rev: 2.1 at 600 MHz, CSB: 400 MHz
- Boot from NOR Flash
- HRCW from I2C EEPROM
- Reset
Andre Schwarz andre.schw...@matrix-vision.de wrote on 2010/11/04 14:32:15:
Jocke,
[snip]
still -E_TOO_LITTLE_INFO:
sorry - thought it was clear already.
include weather booted from NAND or NOR, CPU type(e300cX) and
what reset vector is used.
CPU: e300c4, MPC8379, Rev: 2.1 at
On Wed, 2010-11-03 at 13:38 -0700, Peter Tyser wrote:
I'd guess none of the functions in the SPL binary are referenced in
the
linker script or linker command line, so the linker thinks none of
them
are necessary and removes them.
Can you try the following patch:
I did a quick compile
After the removal of COLD/WARM start flags my mpc8321
board didn't boot anymore.
Trial and error suggests that map_flash_by_law1 needs
an isync(padding with 4 nop's also did the trick)
after updating LBLAWAR1 to make sure the the change has
reached the HW before continuing with the code that
Jocke,
CPU: e300c4, MPC8379, Rev: 2.1 at 600 MHz, CSB: 400 MHz
- Boot from NOR Flash
- HRCW from I2C EEPROM
- Reset Vector 0x100, i.e. low boot.
OK, almost the same as me, but I got a:
CPU: e300c2, MPC8321, Rev: 1.1 at 266.664 MHz, CSB: 133.332 MHz
However, I think I just
Andre Schwarz andre.schw...@matrix-vision.de wrote on 2010/11/04 15:49:06:
Jocke,
CPU: e300c4, MPC8379, Rev: 2.1 at 600 MHz, CSB: 400 MHz
- Boot from NOR Flash
- HRCW from I2C EEPROM
- Reset Vector 0x100, i.e. low boot.
OK, almost the same as me, but I got a:
CPU: e300c2,
On Thu, 2010-11-04 at 10:19 -0400, Haiying Wang wrote:
On Wed, 2010-11-03 at 13:38 -0700, Peter Tyser wrote:
I'd guess none of the functions in the SPL binary are referenced in
the
linker script or linker command line, so the linker thinks none of
them
are necessary and removes them.
On Tue, Oct 26, 2010 at 14:04, Menon, Nishanth n...@ti.com wrote:
Having a loop with a counter is no timing guarentee for timing
accuracy or compiler optimizations. For e.g. the same loop counter
which runs when the MPU is running at 600MHz will timeout in around
half the time when running at
On Mon, Oct 25, 2010 at 16:13, Menon, Nishanth n...@ti.com wrote:
DECLARE_GLOBAL_DATA_PTR is currently defined within the scope
of function while it is a global pointer. Change the scope of
definition to replicate it's global scope. This seems to help
gcc 4.5 optimizations as well.
On Mon, 01 Nov 2010 13:31:38 +0100
Reinhard Meyer u-b...@emk-elektronik.de wrote:
In this particular case the driver is not yet using the (existing) struct
at91_spi at all
WAIT!!!
There is the COMMON driver atmel_spi.c with atmel_spi.h in drivers/spi.
There need not be and
On Thu, 2010-11-04 at 08:45 -0700, Peter Tyser wrote:
Can you explain what you mean? The binary needs to be 4K, right? So
it
can't be trimmed down. But there should be more available space in
that
4K region, eg (all tests on MPC8536DS_NAND_config):
/* After apply my patch sent yesterday
Yes, you are right, the size is down. I only noticed the u-boot-spl size
by using ls -l, not via size. Now I get the same result as yours.
It is very good to see this trim-down size because I know some board
developers are fighting with the 4k limitation of the nand-spl size. Are
you going
Joakim Tjernlund wrote:
Trial and error suggests that map_flash_by_law1 needs
an isync(padding with 4 nop's also did the trick)
after updating LBLAWAR1 to make sure the the change has
reached the HW before continuing with the code that depends on it.
Add an isync to remap_flash_by_law0 for
Jocke,
ok - works for me, i.e. no quad-nop needed anymore.
Does both your boards work now?
MPC8343 @ 400MHz never had any issues - it's still working with your
patch applied.
MPC8377 works fine up to 533MHz ... 600MHz+ still hangs.
Looks like there are more sync missing.
I am
Le 04/11/2010 14:18, Alexander Holler a écrit :
Am 04.11.2010 13:55, schrieb Albert ARIBAUD:
Then please do test this V3 patch and verify if the issues you raise
still apply or are fixed.
V3 failed using my relocation-test-patch (and resulted in the same
problems as without any relocation
Wood Scott-B07421 wrote:
To be totally safe, we probably want to do a readback plus twi (to turn
a data dependency into a flow dependency) before the isync.
twi == trap word immediate?
If so, I don't see how that will turn a data dependency into a flow dependency.
Is that some sort of side
Wood Scott-B07421 b07...@freescale.com wrote on 2010/11/04 17:47:41:
Joakim Tjernlund wrote:
Trial and error suggests that map_flash_by_law1 needs
an isync(padding with 4 nop's also did the trick)
after updating LBLAWAR1 to make sure the the change has
reached the HW before continuing
The fixup procedure just stored a constant value in the
fixup table rather than just adjusting the table.
Although that doesn't seem to do any harm, it prevents
relocation more that once.
Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se
---
arch/powerpc/cpu/74xx_7xx/start.S |2
On 10/29/2010 10:58 PM, Steve Sakoman wrote:
Beagle expansion boards contain an i2c eeprom to identify themselves.
This patch adds code to read and parse the eeprom contents. It prints
the expansion board name and revision and modifies environment variables
as appropriate. This patch is based
Forgot to copy list on my reply!
-- Forwarded message --
From: Steve Sakoman sako...@gmail.com
Date: Thu, Nov 4, 2010 at 11:09 AM
Subject: Re: [U-Boot] [PATCH] OMAP4: speed up booting on Pandaboard
To: Sergiy Kibrik sergiy.kib...@globallogic.com
On Thu, Nov 4, 2010 at 2:38 AM,
On Thu, 2010-11-04 at 09:36 -0700, Peter Tyser wrote:
Glad to hear. I'll submit an official patch shortly. Just to make
sure, have you tried running one of the nand-spl images after the
patch
I sent yesterday? It'd be good to get confirmation that the
-gc-sections doesn't have any
You're still using a locally-built toolchain different from CS and ELDK
toolhcains that were tested so far, right? There is a warning at the
Yes, I'm still using Gentoo to compile u-boot native on that board.
linker stage in the build log you sent me:
ld: warning: creating a DT_TEXTREL in
Am 04.11.2010 19:37, schrieb Alexander Holler:
You're still using a locally-built toolchain different from CS and ELDK
toolhcains that were tested so far, right? There is a warning at the
Yes, I'm still using Gentoo to compile u-boot native on that board.
linker stage in the build log you
Le 04/11/2010 19:42, Alexander Holler a écrit :
Am 04.11.2010 19:37, schrieb Alexander Holler:
You're still using a locally-built toolchain different from CS and ELDK
toolhcains that were tested so far, right? There is a warning at the
Yes, I'm still using Gentoo to compile u-boot native on
Hello,
Am 04.11.2010 20:20, schrieb Albert ARIBAUD:
If I read that patch (66_*) correctly, it's the same as when using
--warn-shared-textrel in LDFLAGS.
All right. I don't like getting a warning like that, but as I cannot
reproduce your toolchain, I cannot avoid it.
I think they enabbled
Timur Tabi wrote:
Wood Scott-B07421 wrote:
To be totally safe, we probably want to do a readback plus twi (to turn
a data dependency into a flow dependency) before the isync.
twi == trap word immediate?
Yes.
If so, I don't see how that will turn a data dependency into a flow
I have added quite a few patches to u-boot-ti but MAKEALL returns several
errors.
I think most boards have not been updated since the ARM relocation patch.
I believe the rule is that support for boards that are not compiling will be
kept in mainline till the next release. After that we will
The following changes since commit 0c0892be0d93a5a892b93739c5eb3bf692fed4ff:
Wolfgang Denk (1):
Merge branch 'master' of git://git.denx.de/u-boot-marvell
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
Alagu Sankar (1):
mmc: Add multi-block read
Dear Menon, Nishanth,
In message aanlkti=hwbui5=zcfumma-eay7aaqw10g73w_cex8...@mail.gmail.com you
wrote:
On Mon, Oct 25, 2010 at 16:13, Menon, Nishanth n...@ti.com wrote:
DECLARE_GLOBAL_DATA_PTR is currently defined within the scope
of function while it is a global pointer. Change the scope
On Thu, Nov 4, 2010 at 8:58 AM, Menon, Nishanth n...@ti.com wrote:
On Mon, Oct 25, 2010 at 16:13, Menon, Nishanth n...@ti.com wrote:
DECLARE_GLOBAL_DATA_PTR is currently defined within the scope
of function while it is a global pointer. Change the scope of
definition to replicate it's global
On Tue, Oct 26, 2010 at 11:04 AM, Nishanth Menon n...@ti.com wrote:
Having a loop with a counter is no timing guarentee for timing
accuracy or compiler optimizations. For e.g. the same loop counter
which runs when the MPU is running at 600MHz will timeout in around
half the time when running
On Thu, Nov 4, 2010 at 1:25 PM, Paulraj, Sandeep s-paul...@ti.com wrote:
I have added quite a few patches to u-boot-ti but MAKEALL returns several
errors.
I think most boards have not been updated since the ARM relocation patch.
I believe the rule is that support for boards that are not
On Thu, Nov 4, 2010 at 1:25 PM, Paulraj, Sandeep s-paul...@ti.com wrote:
I have added quite a few patches to u-boot-ti but MAKEALL returns
several errors.
I think most boards have not been updated since the ARM relocation patch.
I believe the rule is that support for boards that
Le 04/11/2010 20:39, Alexander Holler a écrit :
Sidenote: My toolchain is reproducable, but that means you have to
compile a Gentoo system, because Gentoo is a source only distribution.
So it isn't as comfortable as using binary distributions (here), but it
has other advantages.
It probably
older ld emitted all ELF relocations in input sections named
.rel.dyn, whereas newer ld uses names of the form .rel*. The
linker script only collected .rel.dyn input sections. Rewrite
to collect all .rel* input sections and overlay with .bss.
Signed-off-by: Albert Aribaud albert.arib...@free.fr
older ld emitted all ELF relocations in input sections named
.rel.dyn, whereas newer ld uses names of the form .rel*. The
linker script only collected .rel.dyn input sections. Rewrite
to collect all .rel* input sections and overlay with .bss.
Signed-off-by: Albert Aribaud albert.arib...@free.fr
Le 04/11/2010 23:22, Albert Aribaud a écrit :
older ld emitted all ELF relocations in input sections named
..rel.dyn, whereas newer ld uses names of the form .rel*. The
linker script only collected .rel.dyn input sections. Rewrite
to collect all .rel* input sections and overlay with .bss.
From: Koen Kooi k...@dominion.thruhere.net
Patch was updated by Jason Kridner jkrid...@beagleboard.org:
* Use tabs to match style of other board revisions
* Only include board revisions that exist
* Default to the same configuration as the latest revision, but
without setting 'beaglerev'
It is desired to have the led command on the BeagleBoard to allow for some
interaction in the scripts.
This patch allows any board implementing the coloured LED API
to control the LEDs from the console.
led [green | yellow | red | all ] [ on | off ]
or
led [ 1 | 2 | 3 | all ] [ on | off ]
Added LED driver using status_led. USR0 is set to monitor the boot
status. USR1 is set to be the green LED.
(cherry picked from commit 048b526fd7cc0c642f27c674b3e235321c880b66)
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
board/ti/beagle/Makefile |4 ++-
From: Steve Kipisz s-kipi...@ti.com
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
arch/arm/include/asm/arch-omap3/omap3.h |9 +
board/ti/beagle/beagle.c|3 +++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git
78 matches
Mail list logo
