Wolfgang Denk wrote:
Dear Ben,
I just ran over this piece of code in NetLoop() [see net/net.c]:
286 int
287 NetLoop(proto_t protocol)
288 {
...
322 eth_halt();
323 #ifdef CONFIG_NET_MULTI
324 eth_set_current();
325 #endif
326 if (eth_init(bd) 0) {
[EMAIL PROTECTED] wrote:
Subject: [PATCH 08/11 v1] ARM: OMAP3: Add I2C and network support
From: Dirk Behme [EMAIL PROTECTED]
Add I2C and network support
I2C and network bits are kinda unrelated, don't you think?
snip
Index: u-boot_master/net/eth.c
Ben Warren wrote:
[EMAIL PROTECTED] wrote:
Subject: [PATCH 08/11 v1] ARM: OMAP3: Add I2C and network support
From: Dirk Behme [EMAIL PROTECTED]
Add I2C and network support
I2C and network bits are kinda unrelated, don't you think?
snip
Ben: Yes, you are right ;) The OMAP3 patch
Message: 2
Date: Thu, 25 Sep 2008 16:50:27 +0300
From: Felix Radensky [EMAIL PROTECTED]
Subject: [U-Boot] CFI driver and P33 64M flash
To: u-boot@lists.denx.de
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
'm running U-Boot 1.3.4 on custom 460EX
-
Hi All,
loadb -f /dev/ram0 -o 0x10 adn then
the bootm 0xa010 option is not helping It's displaying could
not open : No Such file or directory And the help says the option is bootm
[option] image. But nothing helps.
The image being tried is
Andy Fleming wrote:
From: Haiying Wang [EMAIL PROTECTED]
Change UEC phy interface from GMII to RGMII on MPC8568MDS board
Because on MPC8568MDS, GMII interface is only recommended for 1000Mbps speed,
but RGMII interface can work at 10/100/1000Mbps, and RGMII interface works
more stable.
Jerry Van Baren wrote:
OK, critique v2 (thanks to Wolfgang calling BS on my previous critique :-).
richardretanubun wrote:
Added for convenience for other platforms that uses MPC8360 (has 8 UCC).
6 eth interface is chosen because the platform I am using combines
UCC12 and UCC34 as gigEth
Dirk Behme wrote:
Ben Warren wrote:
[EMAIL PROTECTED] wrote:
Subject: [PATCH 08/11 v1] ARM: OMAP3: Add I2C and network support
From: Dirk Behme [EMAIL PROTECTED]
Add I2C and network support
I2C and network bits are kinda unrelated, don't you think?
snip
Ben: Yes, you are right ;)
Hi, all
I can run u-boot in my debugger TRACE32 with 'go' command,
but it couldn't be started from the flash without TRACE32 when
the board power on, and I get nothing from the console, I don't know what
happend, and anybody has experience in this problem?
Thanks in advance!
Robert
Dear Ben Warren,
In message [EMAIL PROTECTED] you wrote:
Am I reading this correctly that we eth_halt() and eth_init() the
network interface for each and every call to NetLoop?
Yes, it looks that way. Ripe for gutting.
I didn't have much time to look into the code, so I'm just
On Friday 26 September 2008, Wolfgang Denk wrote:
Am I reading this correctly that we eth_halt() and eth_init() the
network interface for each and every call to NetLoop?
Yes, it looks that way. Ripe for gutting.
I didn't have much time to look into the code, so I'm just
Kim Phillips wrote:
On Thu, 25 Sep 2008 20:17:30 +0200
Wolfgang Denk [EMAIL PROTECTED] wrote:
Dear Kim,
In message [EMAIL PROTECTED] you wrote:
On Thu, Sep 25, 2008 at 3:16 AM, Bartlomiej Sieka [EMAIL PROTECTED]
wrote:
More detailed description can be found in doc/README.au_tftp
'au'
Dear Stefan,
in message [EMAIL PROTECTED] you wrote:
Am I reading this correctly that we eth_halt() and eth_init() the
network interface for each and every call to NetLoop?
Yes, it looks that way. Ripe for gutting.
I didn't have much time to look into the code, so I'm
Dear Bartlomiej Sieka,
In message [EMAIL PROTECTED] you wrote:
How about 'updatefile' for the env. variable and 'README.update' for the
documentation?
ACK from me (this is doc/README.update, right?)
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk
Wolfgang Denk wrote:
Dear Bartlomiej Sieka,
In message [EMAIL PROTECTED] you wrote:
How about 'updatefile' for the env. variable and 'README.update' for the
documentation?
ACK from me (this is doc/README.update, right?)
Yes, doc/README.update.
Regards,
Bartlomiej Sieka
Stefan Roese wrote:
On Friday 26 September 2008, Wolfgang Denk wrote:
Am I reading this correctly that we eth_halt() and eth_init() the
network interface for each and every call to NetLoop?
Yes, it looks that way. Ripe for gutting.
I didn't have much time to look into the code, so I'm
Hi,
I see. Maybe we should call the variable updatefile or similar,
then?
How about au_file? updatefile suffers from similarity to the
commonly used (although not documented) update env. variable. But I'm
fine either way, just let me know what you prefer.
I would use updatefile, but if
Hi Robert,
I can run u-boot in my debugger TRACE32 with 'go' command,
but it couldn't be started from the flash without TRACE32 when
the board power on, and I get nothing from the console, I don't know what
happend, and anybody has experience in this problem?
It sounds like your
Hello,
i took the already submitted patches from Daniel Mack, fixed some minor
problems and patched it against the 1.3.4 tree.
The patch compiles clean and all my boards boots well.
If there are any objections leave me a note
peter
diff -purN u-boot-1.3.4/board/colibri/colibri.c
Signed-of-by: Richard Retanubun [EMAIL PROTECTED]
---
drivers/qe/uec.c | 46 +++---
1 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/drivers/qe/uec.c b/drivers/qe/uec.c
index 344c649..e3fbbb0 100644
--- a/drivers/qe/uec.c
+++
Hi Jerry,
Again I (and Wolfgang) stumbled about the problem, that the /chosen node is
not overwritten by the bootm command when it already exists. This is really
annoying, since we either:
a) Have to remove the chosen node from the dts files (which is not so easy
if we try to stay in sync
The current uec_miiphy_read and uec_miiphy_write hardcode access devlist[0]
This patch makes these function use the devname argument that is passed in to
allow access to the phy registers of other devices in devlist[].
Signed-of-by: Richard Retanubun [EMAIL PROTECTED]
---
Hi Ben,
I'm hoping the
Stefan Roese wrote:
Hi Jerry,
Again I (and Wolfgang) stumbled about the problem, that the /chosen node is
not overwritten by the bootm command when it already exists. This is really
annoying, since we either:
a) Have to remove the chosen node from the dts files (which is not so easy
Set force parameter in fdt_chosen() call in do_bootm_linux() call.
Without this, the chosen node is not overwritten if it already
exists.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
lib_ppc/bootm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib_ppc/bootm.c
Stefan Roese wrote:
Set force parameter in fdt_chosen() call in do_bootm_linux() call.
Without this, the chosen node is not overwritten if it already
exists.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
lib_ppc/bootm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Add support for CONFIG_EFI_PARTITION (GUID Partition Table)
Based on linux/fs/partitions/efi.[ch]
Signed-off-by: Richard Retanubun [EMAIL PROTECTED]
---
Hi Wolfgang,
Boy, do I suck at submitting patches.
This is the same patch as before,
with some minor comment cleanup and proper formatting of
Hello Ben,
I am trying to port u-boot on a system which deploys two different
types of ethernet PHYs, and don't see a good way of doing it with the
current sw structure.
There are concurrent implementations for supporting different PHYs,
and it looks like quite often bringing in a new etherent
Dear all,
I am new to U-boot. I have a mpc8313erdb board that already has U-boot
burned in flash. When the board reset, I get into U-boot (with U-boot
prompt =). My questions is: my gcc compiler produce a .exe file, can I
just tftp this file to an address and run it (go) ? Or I need to convert
Hi Vadim,
vb wrote:
Hello Ben,
I am trying to port u-boot on a system which deploys two different
types of ethernet PHYs, and don't see a good way of doing it with the
current sw structure.
There are concurrent implementations for supporting different PHYs,
and it looks like quite often
Hi Yuke,
What I am doing is to try to load RTEMS
Ok, that info helps.
It has a BSP for this board.
Thats good.
All the tools I used are targeting powerpc and tailed
for this board.
and those tools came from where?
But the final executable format is .exe. I am not sure if
this format
Yuke Tian wrote:
Hi David,
Thank you for your kind response. What I am doing is to try to load the
RTEMS (a kind of open source real time operating system) image to the
board. It has a BSP for this board. All the tools I used are targeting
powerpc and tailed for this board. But the final
Hi Yuke,
Sorry to ask the stupid question. I did study the RTEMS for a while and
am sure the tool set are correct (from ftp://www.rtems.com), otherwise
they will not build RTEMS. All the tools and development are done in
linux (RHLE5). I just got this board using U-boot and not sure about
Yuke Tian wrote:
Hi,
Sorry to ask the stupid question. I did study the RTEMS for a while and
am sure the tool set are correct (from ftp://www.rtems.com), otherwise
they will not build RTEMS. All the tools and development are done in
linux (RHLE5). I just got this board using U-boot and
Thanks.
To be specific, I followed the steps to build RTEMS:
1) Download a set of toolsets (gcc-4.2.3, binutils-2.18, newlib-1.16 and
RTEMS specific patches) and build them or use the pre-built rpm toolset
for RHLE5.
2) Download the RTEMS (4.9.0 for the latest version) and use the toolset
to
David Hawkins wrote:
Hi Yuke,
[snip]
You say that the development is done with RHLE5, but
then that a .exe is created. That seems to be a conflicting
statement. Perhaps you could explain ... are you running
the RTEMs tools under Wine??
The RTEMS quickstart example uses an .exe extension,
Jerry Van Baren wrote:
David Hawkins wrote:
Hi Yuke,
[snip]
You say that the development is done with RHLE5, but
then that a .exe is created. That seems to be a conflicting
statement. Perhaps you could explain ... are you running
the RTEMs tools under Wine??
The RTEMS quickstart example
Yuke Tian wrote:
Thanks.
To be specific, I followed the steps to build RTEMS:
1) Download a set of toolsets (gcc-4.2.3, binutils-2.18, newlib-1.16 and
RTEMS specific patches) and build them or use the pre-built rpm toolset
for RHLE5.
OK.
2) Download the RTEMS (4.9.0 for the latest
David Hawkins wrote:
Hi Yuke,
To be specific, I followed the steps to build RTEMS:
1) Download a set of toolsets (gcc-4.2.3, binutils-2.18, newlib-1.16 and
RTEMS specific patches) and build them or use the pre-built rpm toolset
for RHLE5.
2) Download the RTEMS (4.9.0 for the latest version)
Hi Yuke,
That is exactly what I want now (I need to pick up
U-boot later :-) ). I will try powerpc-linux-objcopy
and let you know.
Well, powerpc-linux-object copy will give you a binary
blob, but thats useless to you unless you know how to
use/load the blob.
I'm a little confused as to why
Hi David,
After email some people in RTEMS community, I got the solutions:
--- To prepare the U-boot image for RTEMS application (with os built in
for RTMES) in host pc (RHEL5)
powerpc-rtems4.9-objcopy -O binary test.ext test.bin (the
powerpc-rtems4.9-objcopy is provided from rtems toolset)
Hi Yuke,
After email some people in RTEMS community, I got the solutions:
--- To prepare the U-boot image for RTEMS application (with os built in
for RTMES) in host pc (RHEL5)
powerpc-rtems4.9-objcopy -O binary test.ext test.bin (the
powerpc-rtems4.9-objcopy is provided from rtems
Hello
(1) I don't quite understand what README means about CFG_MONITOR_BASE
-- is it supposed to reflect the actual physical address, where u-boot
resides, i.e. either flash or SDRAM, or it deals with flash only? Why
I'm in doubts, because some targets in include/configs/boards do not
define this
Hello
I was reading the U-Boot's README, section Memory management. I
don't quite understand, so please help me out:
1) does this section embrace various platforms and describe generic
behavior of U-boot or PPC-specific?
2) it presents memory configuration, as I understand, for the case of
43 matches
Mail list logo
