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

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

[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

[Ben Warren]

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

[Ben Warren]

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
>> UCC1&2 and UCC3&4 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; i<6; ++i) {
>>  printf ("%c%02X", i ? ':' : ' ', bd->bi_enetaddr[i]);
>>  }
>> -
>> +#endif
>>  #if defined(CONFIG_HAS_ETH1)
>>  puts ("\neth1addr=");
>>  for (i=0; i<6; ++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; i<6; ++i) {
>> +printf ("%c%02X", i ? ':' : ' ', bd->bi_enet4addr[i]);
>> +}
>> +#endif
>> +
>> +#if defined(CONFIG_HAS_ETH5)
>> +   puts ("\neth5addr=");
>> +   for (i=0; i<6; ++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

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

[Ben Warren]

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

[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() ?

[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() ?

[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

[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() ?

[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

[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

[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() ?

[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

[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

[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

[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 
+
+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 
+#include 
+#include 
+
+/* 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
+strr1,   [r0]
+
+ldr  

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

[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

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

[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

[Jerry Van Baren]

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

[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

[Jerry Van Baren]

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)

[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 

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

[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

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

[Anton Vorontsov]

On Fri, Sep 26, 2008 at 08:36:28AM -0700, vb wrote:
[...]
> What do you think?

Something like linux/drivers/net/phy/? Sounds great, but somebody
need to port it. ;-)

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
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.

[vb]

[cc]
On Fri, Sep 26, 2008 at 8:42 AM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> On Fri, Sep 26, 2008 at 08:36:28AM -0700, vb wrote:
> [...]
>> What do you think?
>
> Something like linux/drivers/net/phy/? Sounds great, but somebody
> need to port it. ;-)
>


Yes, this is a popular scheme, I don't claim to be its inventor. :-)
Obviously Linux model is not applicable as is, but the idea is very
similar, you are right,

cheers,
/vb

> --
> Anton Vorontsov
> email: [EMAIL PROTECTED]
> irc://irc.freenode.net/bd2
>
___
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.

[Anton Vorontsov]

On Fri, Sep 26, 2008 at 08:52:33AM -0700, vb wrote:
> [cc]
> On Fri, Sep 26, 2008 at 8:42 AM, Anton Vorontsov
> <[EMAIL PROTECTED]> wrote:
> > On Fri, Sep 26, 2008 at 08:36:28AM -0700, vb wrote:
> > [...]
> >> What do you think?
> >
> > Something like linux/drivers/net/phy/? Sounds great, but somebody
> > need to port it. ;-)
> >
> 
> Yes, this is a popular scheme, I don't claim to be its inventor. :-)
> Obviously Linux model is not applicable as is, but the idea is very
> similar, you are right,

Well, what I'm trying to say, is that it would be great to have
a model that is close to the Linux' one, as close as possible. Think
of code sharing, and future code integration...

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] mpc83xx U-boot questions

[Yuke Tian]

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] mpc83xx U-boot questions

[David Hawkins]

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] Handling different ethernhet phys on the same system.

[Ben Warren]

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

[Yuke Tian]

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.

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

[David Hawkins]

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

[Jerry Van Baren]

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 . 
Also the RTEMS documentation
   
   
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:


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.
   

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

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

[vb]

On Fri, Sep 26, 2008 at 10:03 AM, Ben Warren <[EMAIL PROTECTED]> wrote:
>
> 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.
>

Ben, great to hear that we think the same :-)

You are right that the PHYs can be probed, so there is no need to
attach any particular driver ahead of time, the only thing required
from the developer would the MDIO address defined in CONFIG_PHYSx_ADDR
as it is already done today.

Also, we can provide a 'catch all' driver relying on the standard PHY
register definition to fall back to if probing finds a PHY for which a
driver is not available.

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

Absolutely, I'll look into implementing something along these lines,
it is interesting to see what others think,

cheers,
Vadim

> 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

[Yuke Tian]

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


Jerry Van Baren wrote:
> 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 .
> Also the RTEMS documentation
>   
>   
> 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:
> 
>
>
> 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.
>   
>
> 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
>
>

___
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]

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

[Jerry Van Baren]

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:
   

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]

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:
>   
>
> 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]

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.
   
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".
   
   
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]

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

[David Hawkins]

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

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

[David Hawkins]

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

I have a collection of three of those 'CodeWarrior' USB-TAP devices,
and I'd been thinking the same thing ... but thats a thread
for another day ...

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

[Jerry Van Baren]

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.
   

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:
>>   
>>
>> 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]

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

[David Hawkins]

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

[Yuke Tian]

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

[David Hawkins]

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

Install the ELDK tools as per my document, and it'll
get installed for you. You'll want to install whatever
the latest version is ... ELDK-4.2 I think.

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

Great!

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

Its a binary for the development host (RHEL5), so it will
get installed with the ELDK.

As a bonus, once you boot a version of RTEMs built using their
toolset, you should be able to set the compiler tools to those
provided with the ELDK and build RTEMs with that toolset too.

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

[U-Boot] question about environment variables

[Roman Mashak]

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/ do not
define this macro.

(2) do I understand right that when CFG_ENV_IS_NOWHERE defined,
environment variables are not changeable and always default values are
used.?

Thanks in advance!

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

[U-Boot] U-Boot's memory configuration

[Roman Mashak]

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
booting from flash. How will it look when u-boot is loaded in RAM by
preliminary boot code?

I specifically want to understand how memory is organized by U-Boot on
ARM platform.

Sorry if question sounds silly.

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

[U-Boot] [PATCH 1/2] Fix the incorrect DDR clk freq reporting on 8536DS

[Jason Jin]

On 8536DS board, When the DDR clk is set async mode(SW3[6:8] != 111),
The display is still sync mode DDR freq. This patch try to fix
this. The display DDR freq is now the actual freq in both
sync and async mode.

Signed-off-by: Jason Jin <[EMAIL PROTECTED]>
---
 cpu/mpc85xx/cpu.c|3 ++-
 cpu/mpc85xx/speed.c  |3 ++-
 include/asm-ppc/immap_85xx.h |7 +++
 include/configs/MPC8536DS.h  |2 +-
 4 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index 67e81c0..f15b0a8 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -85,7 +85,8 @@ int checkcpu (void)
struct cpu_type *cpu;
 #ifdef CONFIG_DDR_CLK_FREQ
volatile ccsr_gur_t *gur = (void *)(CFG_MPC85xx_GUTS_ADDR);
-   u32 ddr_ratio = ((gur->porpllsr) & 0x3e00) >> 9;
+   u32 ddr_ratio = ((gur->porpllsr) & MPC85xx_PORPLLSR_DDR_RATIO)
+   >> MPC85xx_PORPLLSR_DDR_RATIO_SHIFT;
 #else
u32 ddr_ratio = 0;
 #endif
diff --git a/cpu/mpc85xx/speed.c b/cpu/mpc85xx/speed.c
index 1cda1e3..485ba20 100644
--- a/cpu/mpc85xx/speed.c
+++ b/cpu/mpc85xx/speed.c
@@ -54,7 +54,8 @@ void get_sys_info (sys_info_t * sysInfo)
 
 #ifdef CONFIG_DDR_CLK_FREQ
{
-   u32 ddr_ratio = ((gur->porpllsr) & 0x3e00) >> 9;
+   u32 ddr_ratio = ((gur->porpllsr) & MPC85xx_PORPLLSR_DDR_RATIO)
+   >> MPC85xx_PORPLLSR_DDR_RATIO_SHIFT;
if (ddr_ratio != 0x7)
sysInfo->freqDDRBus = ddr_ratio * CONFIG_DDR_CLK_FREQ;
}
diff --git a/include/asm-ppc/immap_85xx.h b/include/asm-ppc/immap_85xx.h
index 559d6ea..50c9dde 100644
--- a/include/asm-ppc/immap_85xx.h
+++ b/include/asm-ppc/immap_85xx.h
@@ -1552,6 +1552,13 @@ typedef struct par_io {
  */
 typedef struct ccsr_gur {
uintporpllsr;   /* 0xe - POR PLL ratio status register */
+#ifdef CONFIG_MPC8536
+#define MPC85xx_PORPLLSR_DDR_RATIO 0x3e00
+#define MPC85xx_PORPLLSR_DDR_RATIO_SHIFT   25
+#else
+#define MPC85xx_PORPLLSR_DDR_RATIO 0x3e00
+#define MPC85xx_PORPLLSR_DDR_RATIO_SHIFT   9
+#endif
uintporbmsr;/* 0xe0004 - POR boot mode status register */
 #define MPC85xx_PORBMSR_HA 0x0007
uintporimpscr;  /* 0xe0008 - POR I/O impedance status and 
control register */
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index 365818c..310c669 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -59,7 +59,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
 extern unsigned long get_board_ddr_clk(unsigned long dummy);
 #endif
 #define CONFIG_SYS_CLK_FREQget_board_sys_clk(0) /* sysclk for MPC85xx */
-/* #define CONFIG_DDR_CLK_FREQ get_board_ddr_clk(0) /\* ddrclk for MPC85xx *\/ 
FIXME-8536*/
+#define CONFIG_DDR_CLK_FREQget_board_ddr_clk(0)
 #define CONFIG_ICS307_REFCLK_HZ3000  /* ICS307 clock chip ref freq 
*/
 #define CONFIG_GET_CLK_FROM_ICS307   /* decode sysclk and ddrclk freq
 from ICS307 instead of switches */
-- 
1.5.4

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

[U-Boot] [PATCH 2/2] Do not init SATA when disabled.

[Jason Jin]

SGMII and SATA share the serdes on MPC8536 CPU, When SATA disabled
and the driver access the SATA registers, the cpu will hangup.
This patch try to fix this by reading the serdes status before the SATA
initialize.

Signed-off-by: Jason Jin <[EMAIL PROTECTED]>
---
 board/freescale/mpc8536ds/mpc8536ds.c |   12 
 lib_ppc/board.c   |   16 ++--
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/board/freescale/mpc8536ds/mpc8536ds.c 
b/board/freescale/mpc8536ds/mpc8536ds.c
index 88a2c5e..5d39fb4 100644
--- a/board/freescale/mpc8536ds/mpc8536ds.c
+++ b/board/freescale/mpc8536ds/mpc8536ds.c
@@ -651,6 +651,18 @@ int board_eth_init(bd_t *bis)
return pci_eth_init(bis);
 }
 
+int is_sata_supported()
+{
+   volatile ccsr_gur_t *gur = (void *)(CFG_MPC85xx_GUTS_ADDR);
+   uint devdisr = gur->devdisr;
+   uint sdrs2_io_sel =
+   (gur->pordevsr & MPC85xx_PORDEVSR_SRDS2_IO_SEL) >> 27;
+   if (sdrs2_io_sel & 0x04)
+   return 0;
+
+   return 1;
+}
+
 #if defined(CONFIG_OF_BOARD_SETUP)
 void
 ft_board_setup(void *blob, bd_t *bd)
diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index c02ac62..0e4e8d1 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -635,6 +635,16 @@ void board_init_f (ulong bootflag)
/* NOTREACHED - relocate_code() does not return */
 }
 
+int __is_sata_supported()
+{
+   /* For some boards, when sata disabled by the switch, and the
+* driver still access the sata registers, the cpu will hangup.
+* please define platform specific is_sata_supported() if your
+* board have such issue.*/
+   return 1;
+}
+int is_sata_supported() __attribute__((weak, alias("__is_sata_supported")));
+
 /
  *
  * This is the next part if the initialization sequence: we are now
@@ -1105,8 +1115,10 @@ void board_init_r (gd_t *id, ulong dest_addr)
 #endif
 
 #if defined(CONFIG_CMD_SATA)
-   puts ("SATA:  ");
-   sata_initialize ();
+   if (is_sata_supported()) {
+   puts("SATA:  ");
+   sata_initialize();
+   }
 #endif
 
 #ifdef CONFIG_LAST_STAGE_INIT
-- 
1.5.4

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