date:20080926

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) {
  327 eth_halt();
  328 return(-1);
  329 }

 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.
 This looks terribly inefficient to me - is there any rationale behind
 this?

   
Probably, but it escapes me.  It most certainly predates my involvement 
in this project.
 Also, the eth_set_current() checking should IMHO be done  just  once,
 before  we  start  a  network  transfer,  or  when we actually switch
 interfaces, but not for each and every call to NetLoop() ?

   
Maybe, but eth_set_current() is pretty lightweight.  NetLoop is only 
called when we start a network transfer, so this doesn't seem too 
egregious.  It could definitely stand to be refactored.
 Best regards,

 Wolfgang Denk

   
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 08/11 v1] ARM: OMAP3: Add I2C and network support

[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
 ===
 --- u-boot_master.orig/net/eth.c
 +++ u-boot_master/net/eth.c
 @@ -508,7 +508,7 @@ extern int emac4xx_miiphy_initialize(bd_
  extern int mcf52x2_miiphy_initialize(bd_t *bis);
  extern int ns7520_miiphy_initialize(bd_t *bis);
  extern int davinci_eth_miiphy_initialize(bd_t *bis);
 -
 +extern int eth_init(bd_t *bd);
  
  int eth_initialize(bd_t *bis)
  {
 @@ -532,6 +532,9 @@ int eth_initialize(bd_t *bis)
  #if defined(CONFIG_DRIVER_TI_EMAC)
   davinci_eth_miiphy_initialize(bis);
  #endif
 +#if defined(CONFIG_DRIVER_SMC911X)
 + eth_init(bis);
   
This isn't the right place to call eth_init(). I know the namespaces are 
pretty convoluted, but the eth_initialize() family of functions are 
intended to do things like register devices, initialize data structures 
etc. without actually enabling the device. eth_init() enables a device. 
The SMC911X driver doesn' t have such a thing, which is why none of the 
other boards that use this chip have anything in this file.
 +#endif
   return 0;
  }
  #endif
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot
   

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 08/11 v1] ARM: OMAP3: Add I2C and network support

2008-09-26 Thread Dirk Behme

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 is ~300k and I tried to put 
this in as less patches as possible while having no patch  40k. This 
resulted in some more or less unrelated code in one patch. Alternative 
would be to have more than the ~11 patches at the list we already have.

 Index: u-boot_master/net/eth.c
 ===
 --- u-boot_master.orig/net/eth.c
 +++ u-boot_master/net/eth.c
 @@ -508,7 +508,7 @@ extern int emac4xx_miiphy_initialize(bd_
  extern int mcf52x2_miiphy_initialize(bd_t *bis);
  extern int ns7520_miiphy_initialize(bd_t *bis);
  extern int davinci_eth_miiphy_initialize(bd_t *bis);
 -
 +extern int eth_init(bd_t *bd);

  int eth_initialize(bd_t *bis)
  {
 @@ -532,6 +532,9 @@ int eth_initialize(bd_t *bis)
  #if defined(CONFIG_DRIVER_TI_EMAC)
  davinci_eth_miiphy_initialize(bis);
  #endif
 +#if defined(CONFIG_DRIVER_SMC911X)
 +eth_init(bis);

 This isn't the right place to call eth_init(). I know the namespaces are 
 pretty convoluted, but the eth_initialize() family of functions are 
 intended to do things like register devices, initialize data structures 
 etc. without actually enabling the device. eth_init() enables a device. 
 The SMC911X driver doesn' t have such a thing, which is why none of the 
 other boards that use this chip have anything in this file.

Mani, Steve: Any comments on this?

Ben: Any hint where in existing code it is done right to take this as 
example?

Thanks

Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] CFI driver and P33 64M flash

2008-09-26 Thread yusuf khan

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 based board,
equipped with 64M P33 flash (similar to Intel P30). See
http://www.numonyx.com/Documents/Datasheets/314749_P33_Discrete_DS.pdfhttp://www.numonyx.com/Documents/Datasheets/314749_P33_Discrete_DS.pdf

This flash is comprised internally of two 32M flashes.
I have the following declarations in configuration file:

#define CFG_FLASH_CFI/* The flash is CFI compatible*/
#define CFG_FLASH_CFI_DRIVER/* Use common CFI driver*/

#define CFG_FLASH_BANKS_LIST{CFG_FLASH_BASE}
#define CFG_MAX_FLASH_BANKS1/* max number of memory banks*/
#define CFG_MAX_FLASH_SECT518/* max number of sectors on one
chip*/

#define CFG_FLASH_USE_BUFFER_WRITE 1/* use buffered writes (20x
faster)*/
#define CFG_FLASH_PROTECTION   1/* use hardware flash
protection*/
#define CFG_FLASH_EMPTY_INFO/* print 'E' for empty sector on
flinfo */

U-Boot identifies this flash as 32M flash. Below is debug output from
CFI driver:

FLASH: flash detect cfi
fwc addr fc00 cmd f0 f0 8bit x 8 bit
fwc addr fc00 cmd ff ff 8bit x 8 bit
fwc addr fc55 cmd 98 98 8bit x 8 bit
is= cmd 51(Q) addr fc10 is= 0 51
fwc addr fc000555 cmd 98 98 8bit x 8 bit
is= cmd 51(Q) addr fc10 is= 0 51
fwc addr fc00 cmd f0 f0f0 16bit x 8 bit
fwc addr fc00 cmd ff  16bit x 8 bit
fwc addr fcaa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr fc20 is= 0051 5151
fwc addr fc000aaa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr fc20 is= 0051 5151
fwc addr fc00 cmd f0 00f0 16bit x 16 bit
fwc addr fc00 cmd ff 00ff 16bit x 16 bit
fwc addr fcaa cmd 98 0098 16bit x 16 bit
is= cmd 51(Q) addr fc20 is= 0051 0051
is= cmd 52(R) addr fc22 is= 0052 0052
is= cmd 59(Y) addr fc24 is= 0059 0059
device interface is 1
found port 2 chip 2 port 16 bits chip 16 bits
00 : 51 52 59 01 00 0a 01 00 00 00 00 23 36 85 95 08  QRY#6...
10 : 09 0a 00 01 01 02 00 19 01 00 06 00 02 03 00 80  
20 : 00 fe 00 00 02 00 00 00 00 ff ff ff ff fc 36 a4  ..6.
fwc addr fc00 cmd ff 00ff 16bit x 16 bit
fwc addr fc00 cmd 90 0090 16bit x 16 bit
fwc addr fc00 cmd ff 00ff 16bit x 16 bit
fwc addr fcaa cmd 98 0098 16bit x 16 bit
manufacturer is 1
manufacturer id is 0x89
device id is 0x22
device id2 is 0x0
cfi version is 0x3135
size_ratio 1 port 16 bits chip 16 bits
found 2 erase regions
erase region 0: 0x0083
erase_region_count = 4 erase_region_size = 32768
erase region 1: 0x02fe
erase_region_count = 255 erase_region_size = 131072
fwc addr fc00 cmd ff 00ff 16bit x 16 bit
32 MB

What should I change in configuration/driver to get
all 64M of flash detected ?

Thanks a lot.

Felix.

Hi

Set the  CFG_MAX_FLASH_SECT  to 259 and adjust the sector size to 256K
I think it should work than.

-- 
Thanks  Regards

Yusuf A Khan
Multitech Software Systems
Koramangala,Bangalore
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] working with loadb bootm on u-boot-v2 for imx27ads Board

2008-09-26 Thread Lejin

 -
 
 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 getting loaded on the same board when board is
 flashed with redboot using the following commands.
 
   1) load -r -b 0x10 -m xmodem zimage
   2) load -v -r -b 0x0100 -m xmodem  ramdisk.gz 
   3) exec -r 0x00100 -s 0x0060 -b 0x10 -l 0x0020 -c
 init=/linuxrc console=ttymxc0,115200 root=/dev/ram
 
 If any suggestions, please share..!!
 
 Thanks,
 Lejin
 
---

Hi All,

If anybody has tried with the bootm option for executing the Linux ZImage 
already loaded on RAM, on u-boot-v2 Please provide your suggestions.

Thanks,
Lejin


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Change UEC PHY interface to RGMII on MPC8568MDS

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.

 Now both UEC1 and UEC2 can work properly under u-boot.

 It is also in consistent with the kernel setting for 8568 UEC phy interface.

 Signed-off-by: Haiying Wang [EMAIL PROTECTED]

Looks good.  I'll push to net/next soon.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] [83xx] Adds two more ethernet interface to 83xx

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 and the other 4 UCC as 10/100 Eth.
 

 [snip]

   
 diff --git a/README b/README
 index ccd839c..8802304 100644
 --- a/README
 +++ b/README
 @@ -1095,8 +1095,11 @@ The following options need to be configured:
  
  - Ethernet address:
  CONFIG_ETHADDR
 +CONFIG_ETH1ADDR
  CONFIG_ETH2ADDR
  CONFIG_ETH3ADDR
 +CONFIG_ETH4ADDR
 +CONFIG_ETH5ADDR
  
  Define a default value for Ethernet address to use
  for the respective Ethernet interface, in case this
 

 OK, the above is unavoidable unless...

 A more major change but conceptually slick alternative would be a (weak) 
 function generating appropriate MAC addresses since on most/all boards 
 the MAC addresses of the etherspiggots are mathematically related.  The 
 generation function would use MAXCONTROLLERS (CONFIG_NUM_ETH?) to 
 generate the appropriate number of MAC address env variables.

   
Maybe most/all of the boards worked on by gvb, but I sure wouldn't want 
to generalize much beyond that. In my case, boards usually have one or 
more public ports, requiring registered addresses. These would probably 
be sequential. The other ports usually have private MAC addresses based 
on uniquish things like board serial numbers. And I'm sure there are 
lots of other schemes out there.
 diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
 index f4d9d40..67cc64f 100644
 --- a/common/cmd_bdinfo.c
 +++ b/common/cmd_bdinfo.c
 @@ -91,11 +91,12 @@ int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, 
 char *argv[])
  print_str (pevfreq,   strmhz(buf, bd-bi_pevfreq));
  #endif
  
 +#if defined(CONFIG_HAS_ETH0)
  puts (ethaddr =);
  for (i=0; i6; ++i) {
  printf (%c%02X, i ? ':' : ' ', bd-bi_enetaddr[i]);
  }
 -
 +#endif
  #if defined(CONFIG_HAS_ETH1)
  puts (\neth1addr=);
  for (i=0; i6; ++i) {
 @@ -117,6 +118,20 @@ int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, 
 char *argv[])
  }
  #endif
  
 +#if defined(CONFIG_HAS_ETH4)
 +   puts (\neth4addr=);
 +   for (i=0; i6; ++i) {
 +printf (%c%02X, i ? ':' : ' ', bd-bi_enet4addr[i]);
 +}
 +#endif
 +
 +#if defined(CONFIG_HAS_ETH5)
 +   puts (\neth5addr=);
 +   for (i=0; i6; ++i) {
 +printf (%c%02X, i ? ':' : ' ', bd-bi_enet5addr[i]);
 +}
 +#endif
 +
 

 Here is where a modification Kumar's loop (I would loop over 
 /aliases/ethernet[N] instead of the env variables) would cut out 5 
 copies of the same code and would scale infinitely.  Hmmm, we have 
 MAXCONTROLLERS (CONFIG_NUM_ETH?) to tell us how many etherspiggots we 
 have, can we loop on that?

 I would also *strongly* prefer eliminating bd-bi_enet[N]addr variables, 
 are they needed at all in a fdt-enabled system?  Are there any other 
 places that bd-bi_enet[N]addr is used?  If the only use is here, to 
 print out the MAC addresses, we can do Kumar's loop and print the env 
 variables directly instead of converting the env variable to 
 bd-enet[N]addr and then back into ASCII.  Bleah.

   
Let's try to back away from fdt for a minute. I know this particular 
controller is PowerPC and so fdt is relevant, but the concept of having 
oodles of network ports is hardly PowerPC-specific and so we need to 
think in more general terms.
 diff --git a/common/env_common.c b/common/env_common.c
 index 77f9944..0fee3af 100644
 --- a/common/env_common.c
 +++ b/common/env_common.c
 @@ -91,6 +91,12 @@ uchar default_environment[] = {
  #ifdef  CONFIG_ETH3ADDR
  eth3addr= MK_STR(CONFIG_ETH3ADDR) \0
  #endif
 +#ifdef  CONFIG_ETH4ADDR
 +eth4addr= MK_STR(CONFIG_ETH4ADDR) \0
 +#endif
 +#ifdef  CONFIG_ETH5ADDR
 +eth5addr= MK_STR(CONFIG_ETH5ADDR) \0
 +#endif
  #ifdef  CONFIG_IPADDR
  ipaddr=   MK_STR(CONFIG_IPADDR)   \0
  #endif
 diff --git a/common/env_embedded.c b/common/env_embedded.c
 index 77e5619..e79f843 100644
 --- a/common/env_embedded.c
 +++ b/common/env_embedded.c
 @@ -135,6 +135,12 @@ env_t environment __PPCENV__ = {
  #ifdef  CONFIG_ETH3ADDR
  eth3addr= MK_STR(CONFIG_ETH3ADDR) \0
  #endif
 +#ifdef  CONFIG_ETH4ADDR
 +eth4addr= MK_STR(CONFIG_ETH4ADDR) \0
 +#endif
 +#ifdef  CONFIG_ETH5ADDR
 +eth5addr= MK_STR(CONFIG_ETH5ADDR) \0
 +#endif
  #ifdef  CONFIG_ETHPRIME
  ethprime= CONFIG_ETHPRIME \0
  #endif
 

 OK, the above is unavoidable unless we use a function to generate the 
 sequence of MAC addresses.  (Caution: undeveloped concept.)

   
Since we don't allow anyone to define CONFIG_ETHxADDR in board

Re: [U-Boot] [PATCH 08/11 v1] ARM: OMAP3: Add I2C and network support

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 ;) The OMAP3 patch is ~300k and I tried to put 
 this in as less patches as possible while having no patch  40k. This 
 resulted in some more or less unrelated code in one patch. Alternative 
 would be to have more than the ~11 patches at the list we already have.

 Index: u-boot_master/net/eth.c
 ===
 --- u-boot_master.orig/net/eth.c
 +++ u-boot_master/net/eth.c
 @@ -508,7 +508,7 @@ extern int emac4xx_miiphy_initialize(bd_
  extern int mcf52x2_miiphy_initialize(bd_t *bis);
  extern int ns7520_miiphy_initialize(bd_t *bis);
  extern int davinci_eth_miiphy_initialize(bd_t *bis);
 -
 +extern int eth_init(bd_t *bd);

  int eth_initialize(bd_t *bis)
  {
 @@ -532,6 +532,9 @@ int eth_initialize(bd_t *bis)
  #if defined(CONFIG_DRIVER_TI_EMAC)
  davinci_eth_miiphy_initialize(bis);
  #endif
 +#if defined(CONFIG_DRIVER_SMC911X)
 +eth_init(bis);

 This isn't the right place to call eth_init(). I know the namespaces 
 are pretty convoluted, but the eth_initialize() family of functions 
 are intended to do things like register devices, initialize data 
 structures etc. without actually enabling the device. eth_init() 
 enables a device. The SMC911X driver doesn' t have such a thing, 
 which is why none of the other boards that use this chip have 
 anything in this file.

 Mani, Steve: Any comments on this?

 Ben: Any hint where in existing code it is done right to take this as 
 example?

eth_init() will get called in NetLoop() (net/net.c) whenever you send a 
packet.  You should never have to call it explicitly.  There doesn't 
appear to be a separate driver initialization for this controller.
 Thanks

 Dirk
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot couldn't be started from flash

2008-09-26 Thread Robert

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 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Inefficient code in NetLoop() ?

2008-09-26 Thread Wolfgang Denk

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 speculating
- maybe this is needed for switching interfaces in case of errors?

  This looks terribly inefficient to me - is there any rationale behind
  this?

 Probably, but it escapes me.  It most certainly predates my involvement 
 in this project.

I should know, but if I ever understood that part of the code, I have
completely forgotten about it ;-)

  Also, the eth_set_current() checking should IMHO be done  just  once,
  before  we  start  a  network  transfer,  or  when we actually switch
  interfaces, but not for each and every call to NetLoop() ?

 Maybe, but eth_set_current() is pretty lightweight.  NetLoop is only 
 called when we start a network transfer, so this doesn't seem too 
 egregious.  It could definitely stand to be refactored.

Do you plan to have a closer look on this in some near future?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Unix: Some say the learning curve is steep,  but  you  only  have  to
climb it once.  - Karl Lehenbauer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Inefficient code in NetLoop() ?

2008-09-26 Thread Stefan Roese

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 speculating
 - maybe this is needed for switching interfaces in case of errors?

Some ethernet interfaces (e.g. ppc4xx) need to get stopped after the network 
transaction. Otherwise the interface will continue to DMA data to the buffers 
and this could break OS booting. So please don't remove the eth_halt() after 
the transaction is finished.

Best regards,
Stefan

=
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] Automatic software update from TFTP server

2008-09-26 Thread Bartlomiej Sieka

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' as a prefix seems awfully terse and cryptic to me (not to mention
 reminding me of Australians and gold), something a bit longer would go
 a long way to making it clearer what the code does.
 agreed.  autoupdate_tftp?
 I think we should have a *file name so it's clear that this is a
 file name  and not - for example - a logical variable that takes
 yes/no value or similar.
 
 yes, then we'd be consistent with bootfile, fdtfile, etc.

How about 'updatefile' for the env. variable and 'README.update' for the 
documentation?

Regards,
Bartlomiej Sieka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Inefficient code in NetLoop() ?

2008-09-26 Thread Wolfgang Denk

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 just speculating
  - maybe this is needed for switching interfaces in case of errors?
 
 Some ethernet interfaces (e.g. ppc4xx) need to get stopped after the network 
 transaction. Otherwise the interface will continue to DMA data to the buffers 
 and this could break OS booting. So please don't remove the eth_halt() after 
 the transaction is finished.

Agreed, *after* performing the task, i. e. before the network related
command returns to the shell, the network interface  should  be  shut
down. But not right in the middle, in each netloop.

Also, please be aware that we're discussing this in the context of
netconsole, where it actually happens for each and every character
transmitted :-(

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
You cannot propel yourself forward by patting yourself on the back.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] Automatic software update from TFTP server

2008-09-26 Thread Wolfgang Denk

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  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
When in doubt, mumble;   when in trouble, delegate;  when in  charge,
ponder. -- James H. Boren
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] Automatic software update from TFTP server

2008-09-26 Thread Bartlomiej Sieka

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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Inefficient code in NetLoop() ?

2008-09-26 Thread Rafal Jaworowski

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 just speculating
 - maybe this is needed for switching interfaces in case of errors?
 
 Some ethernet interfaces (e.g. ppc4xx) need to get stopped after the network 
 transaction. Otherwise the interface will continue to DMA data to the buffers 
 and this could break OS booting. So please don't remove the eth_halt() after 
 the transaction is finished.

I share Stefan's concerns. Isn't in general the eth_init()/eth_halt()
construct because of polling mode where the network controller needs to make
sure to operate in well defined states?

In our deployments of using U-Boot networking facilities in standalone apps,
there were problems when not doing the full eth_init()/eth_halt() sequence:
without closing eth_halt() after the initial successfull transaction the
network interface would choke and not work after some time, and all subsequent
transfers would fail.

kind regards,
Rafal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] Automatic software update from TFTP server

2008-09-26 Thread Detlev Zundel

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 you prefer au_file (and nobody
 else comes up with comments or better suggestions) that's fine with
 me, too.

I second 'updatefile'.  au_file sounds too much like noise, I mean audio
;)

Cheers
  Detlev

-- 
Whatever you do will be insignificant,
but it is very important that you do it.
-- Mahatma Gandhi
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot couldn't be started from flash

2008-09-26 Thread Detlev Zundel

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 debugger does some initialization that is missing
from U-Boot.  So check any init lists (or whatever it is called for
TRACE32) and the startup of U-Boot and fix the discrepencies.

Cheers
  Detlev

-- 
Milk? called Reg. Er, please. One lump or two? One, please. Sugar?

Dirk Gently's Holistic Detective Agency, Douglas Adams
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] PATCH: Add support for Toradex Colibri PX270 Modules

2008-09-26 Thread Peter Katzmann

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 
u-boot-1.3.4-col/board/colibri/colibri.c
--- u-boot-1.3.4/board/colibri/colibri.c1970-01-01 
01:00:00.0 +0100
+++ u-boot-1.3.4-col/board/colibri/colibri.c2008-09-23 
15:13:35.0 +0200
@@ -0,0 +1,61 @@
+/*
+ * (C) Copyright 2007
+ * Daniel Mack, caiaq [EMAIL PROTECTED]
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* 
- */
+
+/*
+ * Miscelaneous platform dependent initialisations
+ */
+
+int board_init (void)
+{
+/* memory and cpu-speed are setup before relocation */
+/* so we do _nothing_ here */
+
+/* arch number of COLIRBI-Board */
+gd-bd-bi_arch_number = MACH_TYPE_COLIBRI;
+
+/* adress of boot parameters */
+gd-bd-bi_boot_params = 0xa100;
+
+return 0;
+}
+
+int board_late_init(void)
+{
+setenv(stdout, serial);
+setenv(stderr, serial);
+return 0;
+}
+
+
+int dram_init (void)
+{
+gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
+gd-bd-bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+return 0;
+}
diff -purN u-boot-1.3.4/board/colibri/config.mk 
u-boot-1.3.4-col/board/colibri/config.mk
--- u-boot-1.3.4/board/colibri/config.mk1970-01-01 
01:00:00.0 +0100
+++ u-boot-1.3.4-col/board/colibri/config.mk2008-09-23 
15:13:35.0 +0200
@@ -0,0 +1 @@
+TEXT_BASE = 0xa170
diff -purN u-boot-1.3.4/board/colibri/lowlevel_init.S 
u-boot-1.3.4-col/board/colibri/lowlevel_init.S
--- u-boot-1.3.4/board/colibri/lowlevel_init.S1970-01-01 
01:00:00.0 +0100
+++ u-boot-1.3.4-col/board/colibri/lowlevel_init.S2008-09-23 
15:13:35.0 +0200
@@ -0,0 +1,465 @@
+/*
+* This was originally from the Lubbock u-boot port.
+*
+* Most of this taken from Redboot hal_platform_setup.h with cleanup
+*
+* NOTE: I haven't clean this up considerably, just enough to get it
+* running. See hal_platform_setup.h for the source. See
+* board/cradle/lowlevel_init.S for another PXA250 setup that is
+* much cleaner.
+*
+* See file CREDITS for list of people who contributed to this
+* project.
+*
+* This program is free software; you can redistribute it and/or
+* modify it under the terms of the GNU General Public License as
+* published by the Free Software Foundation; either version 2 of
+* the License, or (at your option) any later version.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+* GNU General Public License for more details.
+*
+* You should have received a copy of the GNU General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+* MA 02111-1307 USA
+*/
+
+#include config.h
+#include version.h
+#include asm/arch/pxa-regs.h
+
+/* wait for coprocessor write complete */
+.macro CPWAIT reg
+mrcp15,0,\reg,c2,c0,0
+mov\reg,\reg
+subpc,pc,#4
+.endm
+
+
+/*
+*Memory setup
+*/
+
+.globl lowlevel_init
+lowlevel_init:
+
+/* Set up GPIO pins first - */
+
+ldrr0,=GPSR0
+ldrr1,=CFG_GPSR0_VAL
+strr1,   [r0]
+
+ldrr0,=GPSR1
+ldrr1,=CFG_GPSR1_VAL
+strr1,   [r0]
+
+ldrr0,=GPSR2
+ldrr1,=CFG_GPSR2_VAL
+strr1,   [r0]
+
+ldrr0,=GPSR3
+ldrr1,=CFG_GPSR3_VAL
+strr1,   [r0]
+
+ldrr0,=GPCR0
+ldrr1,=CFG_GPCR0_VAL
+strr1,   [r0]
+
+ldrr0,=GPCR1
+ldrr1,=CFG_GPCR1_VAL
+strr1,   [r0]
+
+ldrr0,=GPCR2
+ldrr1,=CFG_GPCR2_VAL
+strr1,   [r0]
+
+ldrr0,=GPCR3
+ldrr1,=CFG_GPCR3_VAL
+str

Re: [U-Boot] [U-boot] [PATCHv2 1/2] NET: QE: UEC: Make uec_miiphy_read() and uec_miiphy_write() use the devname arg.

2008-09-26 Thread richardretanubun

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
+++ b/drivers/qe/uec.c
@@ -639,6 +639,31 @@ static void phy_change(struct eth_device *dev)
 !defined(BITBANGMII)
 
 /*
+ * Find a device index from the devlist by name
+ *
+ * Returns:
+ *  The index where the device is located, -1 on error
+ */
+static int uec_miiphy_find_dev_by_name(char *devname)
+{
+   int i;
+
+   for (i = 0; i  MAXCONTROLLERS; i++) {
+   if (strncmp(devname, devlist[i]-name, strlen(devname)) == 0) {
+   break;
+   }
+   }
+
+   /* If device cannot be found, returns -1 */
+   if (i == MAXCONTROLLERS) {
+   debug (%s: device %s not found in devlist\n, __FUNCTION__, 
devname);
+   i = -1;
+   }
+
+   return i;
+}
+
+/*
  * Read a MII PHY register.
  *
  * Returns:
@@ -647,8 +672,16 @@ static void phy_change(struct eth_device *dev)
 static int uec_miiphy_read(char *devname, unsigned char addr,
unsigned char reg, unsigned short *value)
 {
-   *value = uec_read_phy_reg(devlist[0], addr, reg);
+   int devindex = 0;
 
+   if (devname == NULL || value == NULL) {
+   debug(%s: NULL pointer given\n, __FUNCTION__);
+   } else {
+   devindex = uec_miiphy_find_dev_by_name(devname);
+   if (devindex = 0) {
+   *value = uec_read_phy_reg(devlist[devindex], addr, reg);
+   }
+   }
return 0;
 }
 
@@ -661,11 +694,18 @@ static int uec_miiphy_read(char *devname, unsigned char 
addr,
 static int uec_miiphy_write(char *devname, unsigned char addr,
 unsigned char reg, unsigned short value)
 {
-   uec_write_phy_reg(devlist[0], addr, reg, value);
+   int devindex = 0;
 
+   if (devname == NULL) {
+   debug(%s: NULL pointer given\n, __FUNCTION__);
+   } else {
+   devindex = uec_miiphy_find_dev_by_name(devname);
+   if (devindex = 0) {
+   uec_write_phy_reg(devlist[devindex], addr, reg, value);
+   }
+   }
return 0;
 }
-
 #endif
 
 static int uec_set_mac_address(uec_private_t *uec, u8 *mac_addr)
-- 
1.5.5.GIT


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] /chosen node not overwritten by bootm

2008-09-26 Thread Stefan Roese

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 with the kernel.org version)

or

b) Have to manually use the U-Boot fdt commands to overwrite the chosen node

I can't remember why this current behavior is implemented this way. Jerry, 
can't we just overwrite this node even if it already exists? What would we 
loose by doing this?

Thanks.

Best regards,
Stefan

=
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-boot] [PATCHv2 1/2] NET: QE: UEC: Make uec_miiphy_read() and uec_miiphy_write() use the devname arg.

2008-09-26 Thread richardretanubun

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 7th try will do it. I forgot to add the commit message before.

 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
+++ b/drivers/qe/uec.c
@@ -639,6 +639,31 @@ static void phy_change(struct eth_device *dev)
 !defined(BITBANGMII)
 
 /*
+ * Find a device index from the devlist by name
+ *
+ * Returns:
+ *  The index where the device is located, -1 on error
+ */
+static int uec_miiphy_find_dev_by_name(char *devname)
+{
+   int i;
+
+   for (i = 0; i  MAXCONTROLLERS; i++) {
+   if (strncmp(devname, devlist[i]-name, strlen(devname)) == 0) {
+   break;
+   }
+   }
+
+   /* If device cannot be found, returns -1 */
+   if (i == MAXCONTROLLERS) {
+   debug (%s: device %s not found in devlist\n, __FUNCTION__, 
devname);
+   i = -1;
+   }
+
+   return i;
+}
+
+/*
  * Read a MII PHY register.
  *
  * Returns:
@@ -647,8 +672,16 @@ static void phy_change(struct eth_device *dev)
 static int uec_miiphy_read(char *devname, unsigned char addr,
unsigned char reg, unsigned short *value)
 {
-   *value = uec_read_phy_reg(devlist[0], addr, reg);
+   int devindex = 0;
 
+   if (devname == NULL || value == NULL) {
+   debug(%s: NULL pointer given\n, __FUNCTION__);
+   } else {
+   devindex = uec_miiphy_find_dev_by_name(devname);
+   if (devindex = 0) {
+   *value = uec_read_phy_reg(devlist[devindex], addr, reg);
+   }
+   }
return 0;
 }
 
@@ -661,11 +694,18 @@ static int uec_miiphy_read(char *devname, unsigned char 
addr,
 static int uec_miiphy_write(char *devname, unsigned char addr,
 unsigned char reg, unsigned short value)
 {
-   uec_write_phy_reg(devlist[0], addr, reg, value);
+   int devindex = 0;
 
+   if (devname == NULL) {
+   debug(%s: NULL pointer given\n, __FUNCTION__);
+   } else {
+   devindex = uec_miiphy_find_dev_by_name(devname);
+   if (devindex = 0) {
+   uec_write_phy_reg(devlist[devindex], addr, reg, value);
+   }
+   }
return 0;
 }
-
 #endif
 
 static int uec_set_mac_address(uec_private_t *uec, u8 *mac_addr)
-- 
1.5.5.GIT


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] /chosen node not overwritten by bootm

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
if we try to stay in sync with the kernel.org version)
 
 or
 
 b) Have to manually use the U-Boot fdt commands to overwrite the chosen node
 
 I can't remember why this current behavior is implemented this way. Jerry, 
 can't we just overwrite this node even if it already exists? What would we 
 loose by doing this?
 
 Thanks.
 
 Best regards,
 Stefan

Hi Stefan,

The behavior was to mimic the behavior of the non-LIBFDT original 
implementation (and because we thought it was a good idea at the time). 
  We originally assumed that the .dts file writer had more/better 
knowledge of the system than we did (which was true at the time).  This 
was aggravated by the conundrum that the original FDT support didn't do 
a good job of generating the /chosen properties (some were, some 
weren't), so the .dts writers /had to/ pre-init some /chosen values. 
The /aliases node also helped - configuration choices that use to be 
implicit in the .dts /chosen node are now in /aliases (major improvement!).

I thought we turned on the force flag so that the /chosen properties 
would be overwritten, apparently I'm mistaken.

I'm fine with overwriting the /chosen node and properties.  Generate a 
patch and I'll be happy to ack it.

(Note to self: maybe it is time to retire the force flag - it always 
made me uncomfortable and is confusing.  Is there anything left that we 
*don't* want to force?)

Best regards,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] fdt: Overwrite /chosen node in bootm if it already exists in the dtb

2008-09-26 Thread Stefan Roese

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 b/lib_ppc/bootm.c
index 38266e1..5af25dd 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -145,7 +145,7 @@ int do_bootm_linux(int flag, int argc, char *argv[], 
bootm_headers_t *images)
 * if the user wants it (the logic is in the subroutines).
 */
if (of_size) {
-   if (fdt_chosen(of_flat_tree, 0)  0) {
+   if (fdt_chosen(of_flat_tree, 1)  0) {
puts (ERROR: );
puts (/chosen node create failed);
puts ( - must RESET the board to recover.\n);
-- 
1.6.0.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Overwrite /chosen node in bootm if it already exists in the dtb

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(-)
 
 diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
 index 38266e1..5af25dd 100644
 --- a/lib_ppc/bootm.c
 +++ b/lib_ppc/bootm.c
 @@ -145,7 +145,7 @@ int do_bootm_linux(int flag, int argc, char *argv[], 
 bootm_headers_t *images)
* if the user wants it (the logic is in the subroutines).
*/
   if (of_size) {
 - if (fdt_chosen(of_flat_tree, 0)  0) {
 + if (fdt_chosen(of_flat_tree, 1)  0) {
   puts (ERROR: );
   puts (/chosen node create failed);
   puts ( - must RESET the board to recover.\n);

Acked-by: Gerald Van Baren [EMAIL PROTECTED]

Please apply, Wolfgang, and fix the error in my recollection.  :-)

gvb

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add support for CONFIG_EFI_PARTITION (GUID Partition Table)

2008-09-26 Thread richardretanubun

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 patch.

Richard 

 README  |2 +-
 disk/Makefile   |1 +
 disk/part.c |   33 -
 disk/part_efi.c |  425 +++
 disk/part_efi.h |  138 ++
 include/part.h  |8 +
 6 files changed, 603 insertions(+), 4 deletions(-)
 create mode 100644 disk/part_efi.c
 create mode 100644 disk/part_efi.h

diff --git a/README b/README
index ccd839c..409883e 100644
--- a/README
+++ b/README
@@ -687,7 +687,7 @@ The following options need to be configured:
 
 - Partition Support:
CONFIG_MAC_PARTITION and/or CONFIG_DOS_PARTITION
-   and/or CONFIG_ISO_PARTITION
+   and/or CONFIG_ISO_PARTITION and/or CONFIG_EFI_PARTITION
 
If IDE or SCSI support is enabled (CONFIG_CMD_IDE or
CONFIG_CMD_SCSI) you must configure support for at
diff --git a/disk/Makefile b/disk/Makefile
index f19d18d..c479145 100644
--- a/disk/Makefile
+++ b/disk/Makefile
@@ -32,6 +32,7 @@ COBJS-y += part_mac.o
 COBJS-y += part_dos.o
 COBJS-y += part_iso.o
 COBJS-y += part_amiga.o
+COBJS-y += part_efi.o
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/disk/part.c b/disk/part.c
index 80532a7..e2bf4ab 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -212,7 +212,8 @@ void dev_print (block_dev_desc_t *dev_desc)
 #if defined(CONFIG_MAC_PARTITION) || \
 defined(CONFIG_DOS_PARTITION) || \
 defined(CONFIG_ISO_PARTITION) || \
-defined(CONFIG_AMIGA_PARTITION)
+defined(CONFIG_AMIGA_PARTITION) || \
+defined(CONFIG_EFI_PARTITION)
 
 void init_part (block_dev_desc_t * dev_desc)
 {
@@ -230,6 +231,14 @@ void init_part (block_dev_desc_t * dev_desc)
}
 #endif
 
+/* must be placed before DOS partition detection */
+#ifdef CONFIG_EFI_PARTITION
+   if (test_part_efi(dev_desc) == 0) {
+   dev_desc-part_type = PART_TYPE_EFI;
+   return;
+   }
+#endif
+
 #ifdef CONFIG_DOS_PARTITION
if (test_part_dos(dev_desc) == 0) {
dev_desc-part_type = PART_TYPE_DOS;
@@ -286,6 +295,15 @@ int get_partition_info (block_dev_desc_t *dev_desc, int 
part
}
break;
 #endif
+
+#ifdef CONFIG_EFI_PARTITION
+   case PART_TYPE_EFI:
+   if (get_partition_info_efi(dev_desc,part,info) == 0) {
+   PRINTF (## Valid EFI partition found ##\n);
+   return (0);
+   }
+   break;
+#endif
default:
break;
}
@@ -356,14 +374,23 @@ void print_part (block_dev_desc_t * dev_desc)
print_part_amiga (dev_desc);
return;
 #endif
+
+#ifdef CONFIG_EFI_PARTITION
+   case PART_TYPE_EFI:
+   PRINTF (## Testing for valid EFI partition ##\n);
+   print_part_header (EFI, dev_desc);
+   print_part_efi (dev_desc);
+   return;
+#endif
}
puts (## Unknown partition table\n);
 }
 
 
-#else  /* neither MAC nor DOS nor ISO partition configured */
+#else  /* neither MAC nor DOS nor ISO nor AMIGA nor EFI partition configured */
 # error neither CONFIG_MAC_PARTITION nor CONFIG_DOS_PARTITION
-# error nor CONFIG_ISO_PARTITION configured!
+# error nor CONFIG_ISO_PARTITION nor CONFIG_AMIGA_PARTITION
+# error nor CONFIG_EFI_PARTITION configured!
 #endif
 
 #endif
diff --git a/disk/part_efi.c b/disk/part_efi.c
new file mode 100644
index 000..979019a
--- /dev/null
+++ b/disk/part_efi.c
@@ -0,0 +1,425 @@
+/*
+ * Copyright (C) 2008 RuggedCom, Inc.
+ * Richard Retanubun [EMAIL PROTECTED]
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/*
+ * Problems with CFG_64BIT_LBA:
+ *
+ * struct disk_partition.start in include/part.h is sized as ulong.
+ * When CFG_64BIT_LBA is activated, lbaint_t changes from ulong to uint64_t.
+ * For now, it is cast back to ulong at assignment.
+ *
+ * This limits the maximum size of addressable storage to  2 Terra

[U-Boot] Handling different ethernhet phys on the same system.

2008-09-26 Thread vb

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 controller
brings in a duplicate PHY driver code. OTOH it is always presumed that
the same kind of phy is used on all ports.

I want to modify this scheme, but I don't want to go too far on a
tangent, as we here plan to integrate our changes back into the master
repository one of those days.

Here is what I suggest doing:

we introduce a concept of 'phy bus' - an MDIO bus for instance, and
'phy interface' which is the phy driver.

For illustration purpose, the phy bus could look like this:
struct phy_bus {
int (*write)(u8 addr, u16 reg, u16 value);
int (*read)(u8 addr, u16 reg, u16 *value);
}

and the driver would provide methods like

struct phy_driver {
   int (*reset)(struct phy_bus*, u8 addr))
   int (*init)(struct phy_bus*, u8 addr)
...
}

the set of methods could be fine tuned at any time obviously, the
important thing is that each method would receive the pointer to the
phy bus to be used to communicate with the device.

Then, in the ethernet device structure we would add two pointers: to
the bus serving the port and to the driver serving the port.

This would allow any new ethernet controller provide its own mdio bus
implementation and then use existing phy driver the same way any other
controller uses it. This would also allow to attach different phy
devices to different ethernet ports. And of course the multiple PHY
implementations won't be needed anymore, just one instance will serve
any ethernet device.

What do you think?

TIA,
Vadim


On Thu, Sep 25, 2008 at 11:09 PM, Ben Warren [EMAIL PROTECTED] wrote:
 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) {
  327 eth_halt();
  328 return(-1);
  329 }

 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.
 This looks terribly inefficient to me - is there any rationale behind
 this?


 Probably, but it escapes me.  It most certainly predates my involvement
 in this project.
 Also, the eth_set_current() checking should IMHO be done  just  once,
 before  we  start  a  network  transfer,  or  when we actually switch
 interfaces, but not for each and every call to NetLoop() ?


 Maybe, but eth_set_current() is pretty lightweight.  NetLoop is only
 called when we start a network transfer, so this doesn't seem too
 egregious.  It could definitely stand to be refactored.
 Best regards,

 Wolfgang Denk


 regards,
 Ben
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] mpc83xx U-boot questions

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
it to some format (use mkimage) to run it ?

Does the load address and entry address matters ?  Does anyone happen to
know what is the correct load address for this board ?  One more
question, where do I get the mkimage for this board ?

Thank you in advance for your response.

Yuke Tian
Brookhaven National Lab
Upton, NY 11790
Tel:631-344-2872
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Handling different ethernhet phys on the same system.

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 bringing in a new etherent controller
 brings in a duplicate PHY driver code. OTOH it is always presumed that
 the same kind of phy is used on all ports.

 I want to modify this scheme, but I don't want to go too far on a
 tangent, as we here plan to integrate our changes back into the master
 repository one of those days.

 Here is what I suggest doing:

 we introduce a concept of 'phy bus' - an MDIO bus for instance, and
 'phy interface' which is the phy driver.

 For illustration purpose, the phy bus could look like this:
 struct phy_bus {
 int (*write)(u8 addr, u16 reg, u16 value);
 int (*read)(u8 addr, u16 reg, u16 *value);
 }

 and the driver would provide methods like

 struct phy_driver {
int (*reset)(struct phy_bus*, u8 addr))
int (*init)(struct phy_bus*, u8 addr)
 ...
 }

 the set of methods could be fine tuned at any time obviously, the
 important thing is that each method would receive the pointer to the
 phy bus to be used to communicate with the device.

 Then, in the ethernet device structure we would add two pointers: to
 the bus serving the port and to the driver serving the port.

 This would allow any new ethernet controller provide its own mdio bus
 implementation and then use existing phy driver the same way any other
 controller uses it. This would also allow to attach different phy
 devices to different ethernet ports. And of course the multiple PHY
 implementations won't be needed anymore, just one instance will serve
 any ethernet device.

 What do you think?

 TIA,
 Vadim
   
This is a topic that has been brought up many times before.  I actually 
started porting the Linux PHY stuff, but quickly realized that my 
limited CPU cycles would be better spent cleaning up the overall 
Ethernet driver architecture, with the PHY stuff to come later.

I like your ideas.  In addition to the inflexibility that you've 
mentioned, there's a lot of code duplication (see, for example the 
number of PHYs that are listed in the TSEC driver).  One of the things 
that's difficult to balance, and I don't know too many other peoples 
opinions, is how much board C code is acceptable, versus how much 
information should be specified by CONFIG_x definitions.  If everybody 
suddenly has to define an elaborate array of structs in board code 
rather than a few CONFIGs, usability goes down.  I don't really care, 
since IMHO you should know what you're doing when you port a bootloader, 
but maybe others feel differently.

Another thing to keep in mind is that we don't need to strongly bind a 
PHY type to an interface, really just a bus/ address (assuming we're 
using MDIO), since the devices are mostly probe-able.

Good conversation - let's keep it going.  It would be great if you could 
work on this.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc83xx U-boot questions

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 is good to download and run on the
 board using U-boot.  I just happen to know there is a
 mkimage utility from U-boot.

Given a file test.exe, type

file test.exe

and it'll tell you if its a PowerPC .elf format.

Before trying to get RTEMs running on the board,
see if your tools can build U-Boot, and build the
standard stand-alone application that exists in
the examples folder.

Here's some notes I wrote a while back for the
8349, which is in the same family as the 8313;

http://www.ovro.caltech.edu/~dwh/carma_board/powerpc_mpc8349e.pdf

Cheers,
Dave
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc83xx U-boot questions

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 executable format is
.exe. I am not sure if this format is good to download and run on the
board using U-boot. I just happen to know there is a mkimage utility
from U-boot.

1) You need to do a lot of reading: books - see below - and on-line
documentation such as http://www.denx.de/wiki/U-Boot/Documentation.
Also the RTEMS documentation
http://www.rtems.com/wiki/index.php/Quick_Start
http://www.rtems.com/onlinedocs.html
You have to have some fundamental knowledge before you can ask questions
that we can answer.

Note that you aren't the first to ask the question you started out with,
see the README file:
http://git.denx.de/?p=u-boot.git;a=blob;f=README;h=ccd839ca25828c2be9d2ac576259b443d0704792;hb=HEAD#l3859

2) Some (idiot) tools create non-Windows binary executables as .exe
files. This is nonstandard in terms of Windows executables and is
nonstandard in terms non-Windows executables. As a result, we cannot
say *anything* about your question WRT your gcc compiler producing a
.exe file.

If you list/dump/edit the .exe file, are the first three bytes the
characters ELF? If so, it isn't a Windows executable, but we still
don't know much about what it *is.* If it doesn't say ELF, it may be
a Windows executable and is useless for your purposes, or it may be a
raw binary file, but we still don't know much about what it *is.*

3) Your description of your toolset totally inadequate. Who made it?
Where did it come from? How do you know it is a cross-PPC compiler?
What version of gcc is it? What is your host? Windows? Windows+cygwin?
Linux? BSD? OSX? Solaris?

It sounds like you need to be asking questions of your toolset provider
(company if commercial), subscribe to the toolset's email list, and
RTEMS email lists.
http://www.rtems.com/wiki/index.php/RTEMSMailingLists

Good luck,
gvb

Thank you,

Yuke

David Hawkins wrote:
Hi Yuke,

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
it to some format (use mkimage) to run it ?

Does the load address and entry address matters ? Does anyone happen to
know what is the correct load address for this board ? One more
question, where do I get the mkimage for this board ?
New to U-Boot and embedded systems, eh?

If your gcc compiler is producing a .exe file, then
you sound like you are working on a Windows machine,
with say Cygwin. That particular version of gcc is
for the *Windows OS* and the *Intel architecture*.

The gcc compiler can be built for a specific processor
type and OS. The Denx ELDK has a prebuilt version of
gcc for the PowerPC on the MPC8313 that can be used
to build both U-boot, stand-alone, and Linux
applications. You would typically install the ELDK on
a Linux machine (eg. an Intel-based laptop/desktop).

You'll probably want to get yourself a copy of

Building Embedded Linux Systems, K. Yagmour, O'Reilly.

and read it to learn some of the basics of embedded
programming, and cross-platform development.

If you want to run an executable from U-Boot, then you'll
want to read the 'stand-alone applications' section of
the DULG.

http://www.denx.de/wiki/DULG/WebHome

But if what you really want is a Linux application, then
U-Boot will be used to boot Linux, and then your application
will run under Linux.

If you let us know exactly what you want your program to do,
we can suggest the path of least-resistance for you.

Cheers,
Dave

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc83xx U-boot questions

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
 it. David's manual help a lot. Thanks.

Its not that the questions are stupid, its that they lack
information sufficient to help you. For example,
the toolset ... readers of the list are busy, so expecting us
to follow links and try to interpret which toolset you have
installed is not going to happen. Its better to say,
I got the tool from this link ...' and it provided
powerpc-linux-gcc version XXX, etc., and then what you've
managed to succeed to do with the tools.

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??

Anyway, a good suggestion is to install ELDK and rebuild
U-Boot and update it, even get Linux booted. It may not be
your main goal, but consider it educational :)

Cheers,
Dave
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc83xx U-boot questions

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 not sure about
 it. David's manual help a lot. Thanks.
 
 Yuke

I didn't call your question stupid, just clueless.  ;-)

It sounds like you are coming up to speed rapidly, including providing 
useful background information and asking smart questions.  You might add 
the following to your reading list:
   http://www.catb.org/esr/faqs/smart-questions.html

Best regards,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc83xx U-boot questions

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 build RTEMS.
3) Compile a RTEMS application,  tailed for specific BSP.  That is where
I get .exe (it is ELF 32-bit MSB executable, PowerPC or cisco 4500,
version 1 (SYSV), statically linked, not stripped).  I just want to use
the vendor provided U-Boot to download the .exe and get it run. I didn't
expect to rebuilt U-Boot, but that might be educational :-)  

Yuke



Jerry Van Baren wrote:
 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 not sure about
 it. David's manual help a lot. Thanks.

 Yuke

 I didn't call your question stupid, just clueless.  ;-)

 It sounds like you are coming up to speed rapidly, including providing
 useful background information and asking smart questions.  You might
 add the following to your reading list:
   http://www.catb.org/esr/faqs/smart-questions.html

 Best regards,
 gvb


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc83xx U-boot questions

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, so it looks like 
Yuke's toolset is braindamaged.
   http://www.rtems.com/wiki/index.php/Quick_Start
Example:
   bash-3.1$ sparc-rtems4.9-gdb `find . -name ticker.exe`
(bleah!)

The RTEMS example is running on a simulator via gdb, which is a far cry 
from running on real hardware, booting either on bare metal (very big 
ouch) or using u-boot to start it (much less ouch - I would start by 
running your RTEMS build as a u-boot application - that gets you 
things like fairly painless serial support).

Note to Yuke: this will be a learning experience for you - please keep 
us informed so we can learn vicariously with you.  I'm not aware of 
anybody using u-boot to boot RTEMS, so you may have some useful stuff 
when you get to the end of your journey.  We will help as much as we can...

 Anyway, a good suggestion is to install ELDK and rebuild
 U-Boot and update it, even get Linux booted. It may not be
 your main goal, but consider it educational :)

Note to Yuke: you should also have a JTAG debugger to recover from 
failed u-boot reprogramming if you rebuild and reflash u-boot.  You may 
want to use a JTAG debugger even if you *don't* reflash u-boot.

Note that the Abatron BDI3000 supports gdb remote target.
   http://www.abatron.ch/products/bdi-family/bdi3000.html
   http://www.abatron.ch/products/debugger-support/gnu-support.html
I think most of the competitors do too now, but I don't know. 
Definitely ask about their linux (as the host) and gdb (remote target 
over ethernet) support before you buy.

USB-attached JTAG debuggers tend to be Windows-only.  Bleah!  On a 
positive note, I have a whole collection of single-board computers 
(curiously labeled USB TAP ;-) with a MPC866, usb, and JTAG interface. 
  If only I had the time to port u-boot to them and make them useful... :-D

 Cheers,
 Dave

Best regards,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc83xx U-boot questions

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 uses an .exe extension, so it looks
 like Yuke's toolset is braindamaged.
   http://www.rtems.com/wiki/index.php/Quick_Start
 Example:
   bash-3.1$ sparc-rtems4.9-gdb `find . -name ticker.exe`
 (bleah!)

 The RTEMS example is running on a simulator via gdb, which is a far
 cry from running on real hardware, booting either on bare metal (very
 big ouch) or using u-boot to start it (much less ouch - I would start
 by running your RTEMS build as a u-boot application - that gets you
 things like fairly painless serial support).

 Note to Yuke: this will be a learning experience for you - please keep
 us informed so we can learn vicariously with you.  I'm not aware of
 anybody using u-boot to boot RTEMS, so you may have some useful stuff
 when you get to the end of your journey.  We will help as much as we
 can...

Thanks. It is true that RTEMS provide .exe for gdb simulation. But we do
have BSP package and to build application for real board, like this
mpc8313 board. I might need to figure out how to make better use of
U-boot. But right now, I just want to use it to load image and get it
run. The vendor already installed U-boot.  I thought U-boot is just a
bootloader. Never think  about build RTEMS as u-boot application. It
seems I misunderstood a lot. :-(
 Anyway, a good suggestion is to install ELDK and rebuild
 U-Boot and update it, even get Linux booted. It may not be
 your main goal, but consider it educational :)

 Note to Yuke: you should also have a JTAG debugger to recover from
 failed u-boot reprogramming if you rebuild and reflash u-boot.  You
 may want to use a JTAG debugger even if you *don't* reflash u-boot.

 Note that the Abatron BDI3000 supports gdb remote target.
   http://www.abatron.ch/products/bdi-family/bdi3000.html
   http://www.abatron.ch/products/debugger-support/gnu-support.html
 I think most of the competitors do too now, but I don't know.
 Definitely ask about their linux (as the host) and gdb (remote target
 over ethernet) support before you buy.

 USB-attached JTAG debuggers tend to be Windows-only.  Bleah!  On a
 positive note, I have a whole collection of single-board computers
 (curiously labeled USB TAP ;-) with a MPC866, usb, and JTAG
 interface.  If only I had the time to port u-boot to them and make
 them useful... :-D

 Cheers,
 Dave

 Best regards,
 gvb


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc83xx U-boot questions

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 version) and use the toolset
 to build RTEMS.

OK for RTEMS, it may be some work getting it to compile u-boot or linux. 
  Or maybe not.  Around here, ELDK dominates because it is easy to build 
u-boot and linux with it (thanks, Wolfgang!).  If you get serious about 
rebuilding u-boot or linux, I would strongly urge you to use ELDK to 
build the first one before trying to get RTEMS' toolset to work.  Rule 
#1 of engineering: change only ONE variable at a time!

 3) Compile a RTEMS application,  tailed for specific BSP.  That is where
 I get .exe (it is ELF 32-bit MSB executable, PowerPC or cisco 4500,
 version 1 (SYSV), statically linked, not stripped).

That's good.

 I just want to use the vendor provided U-Boot to download the .exe
 and get it run.

I don't know anything about RTEMS and its BSP.  It may want to be burned 
into flash, replacing u-boot.  In that case, open your wallet and buy a 
JTAG debugger (e.g. BDI-3000).



If you want to use u-boot to load  go, you need to figure out where the 
.exe is loaded in memory and make sure it is in RAM, not by the start of 
RAM (interrupt vectors) or end of RAM (u-boot).  You probably will need 
to change the load location (Makefile or linker script *.lds).

You will need to figure out where RTEMS wants to live.  It may want to 
live at the start of RAM so it can take over the interrupt vectors.  You 
will need to figure out how to get it where it needs to be, if you 
cannot load it directly there.  You may be able to learn from how u-boot 
boots a vxWorks image?  That is the closest match that I can think of to 
how RTEMS will work.

You will also have to figure out how to make RTEMS support your board's 
I/O (serial first, ethernet second).

All of the above should be addressed more or less successfully by the 
BSP.  Whether your RTEMS+BSP plays well (or at all) with u-boot, I don't 
have a clue.  Since we (I) don't know much about RTEMS and the BSP you 
have, we (I) cannot say much specific.

 I didn't expect to rebuilt U-Boot, but that might be educational :-)  

It could be expensive too, if you don't have a JTAG debugger to recover 
from oopses. :-/

 Yuke

BTW, please bottom/inline post.
   http://en.wikipedia.org/wiki/Posting_style#Bottom-posting

Best regards,
gvb

 Jerry Van Baren wrote:
 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 not sure about
 it. David's manual help a lot. Thanks.

 Yuke
 I didn't call your question stupid, just clueless.  ;-)

 It sounds like you are coming up to speed rapidly, including providing
 useful background information and asking smart questions.  You might
 add the following to your reading list:
   http://www.catb.org/esr/faqs/smart-questions.html

 Best regards,
 gvb

 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc83xx U-boot questions

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) and use the toolset
 to build RTEMS.
 3) Compile a RTEMS application,  tailed for specific BSP.  That is where
 I get .exe (it is ELF 32-bit MSB executable, PowerPC or cisco 4500,
 version 1 (SYSV), statically linked, not stripped).  I just want to use
 the vendor provided U-Boot to download the .exe and get it run. I didn't
 expect to rebuilt U-Boot, but that might be educational :-)  

 Great, that is useful background information in which
 to pose your questions.

 It sounds like the Makefile puts a .exe extension on
 the ELF file, and that can safely be ignored.

 Does the RTEMs BSP for the MPC8313 board have a README
 that tells you how to boot RTEMs? The ELF file is
 not what will be executed by U-Boot. powerpc-linux-objcopy
 would most likely be used to convert the ELF into a binary
 image.  mkimage might be run on that image to add a header.
 However, I've only used U-Boot with standalone apps and
 Linux, so someone else would have to comment.
 (VxWorks/RTEMs users - any help here?)

 It does however sound like you have a reasonable tools
 setup, and the step you are looking for is

  'what is necessary to convert the ELF file to a U-Boot
   compatible format, and then what U-Boot command is needed
   to execute it?'

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.

Thank you and sorry again for the unclear statement.

 Hopefully someone can help answer that. Please go and re-review
 the U-Boot README file too, there's a chance that there are
 some useful comments in there - now that you know what you
 are looking for.

 If someone on the RTEMs list answers your question, please
 post the results back to this list so that the solution
 is available in the archive.

 Cheers,
 Dave



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc83xx U-boot questions

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 you say you have
a BSP, and none of this is explained in the BSP.

Where did this BSP come from? Got a link?

Cheers,
Dave
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc83xx U-boot questions

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)
gzip -9 test.bin
mkimage -A ppc -O rtems -T kernel -C gzip -a 100 -e 1 -n RTEMS
Test -d test.bin test.img  (I am still looking for mkimage software)

--To load through U-boot (pre-installed by board vendor)
setenv ethact TSEC1  (this board has 6 ethernet port, choose one)
setenv ipaddr 123.345.123.1 (board ip)
setenv serverip 123.345.123.2 (tftp server ip)
tftp 100 test.img  (load image to this RAM address)
bootm  (then run)

This is the recommended step to boot the board into RTEMS through U-boot.

I guess to get mkimage for this board, I need to rebuilt U-boot anyway.
Or this mkimage is a standard utility from U-boot ?

Thanks for the discussion.

Yuke

David Hawkins wrote:
 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 you say you have
 a BSP, and none of this is explained in the BSP.

 Where did this BSP come from? Got a link?

 Cheers,
 Dave


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc83xx U-boot questions