[U-Boot] No reply to USB related questions

[Dushara Jayasinghe]

Hi,

I've posted a few questions to the list for which I didn't get any response. 

http://www.mail-archive.com/u-boot@lists.denx.de/msg17801.html

Please let me know if I'm breaking in ML rules and I'll change my evil ways :-)

Thanks,

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

Re: [U-Boot] [PATCH] ppc: Fix compile error for boards with CONFIG_DDR_ECC

[Stefan Roese]

On Wednesday 15 July 2009 07:01:08 Peter Tyser wrote:
> A bug was introduced by commit e94e460c6e8741f42dab6d8dd4b596ba5d9d79ae
> which affected non-MPC83xx/85xx/86xx ppc boards which had CONFIG_DDR_ECC
> defined and resulted in errors such as:
>
> Configuring for canyonlands board...
> fsl_dma.c:50:2: error: #error "Freescale DMA engine not supported on your
> processor"
> make[1]: *** No rule to make target `.depend', needed by `libdma.a'.  Stop.
>
> Signed-off-by: Peter Tyser 

Thanks Peter.

Wolfgang, I suggest that you pull this patch directly so that the breakage is 
fixed.

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

[U-Boot] [GIT PULL] Please pull microblaze

[Michal Simek]

Hi Wolfgang,

please pull the following changes.

Thanks,
Michal


The following changes since commit bfadb17f69c256196620c32164775f063a59c34f:
  Anton Vorontsov (1):
mpc83xx: MPC837xEMDS: Use hwconfig instead of pci_external_arbiter 
variable

are available in the git repository at:

  git://www.denx.de/git/u-boot-microblaze.git master

Michal Simek (2):
  microblaze: Removed unused variables
  microblaze: Remove ignored return type for __arch__swab16 function

 include/asm-microblaze/byteorder.h |4 +++-
 lib_microblaze/board.c |4 
 2 files changed, 3 insertions(+), 5 deletions(-)


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] USB not working with 4.3.2 gcc compiler in u-boot 1.1.5

[Remy Bohmer]

Hello,

2009/7/17 Ben Warren :
> virupax wrote:
>> Hi
>>
>> I am using  arm-unknown-linux-gnueabi-gcc 4.3.2 compiler to compile the
>> u-boot 1.1.5 for the at91sam9260 board. When i use this u-boot image usb
>> start command is not detecting the connected usb stick.
>> Request Sense returned 00 00 00
>> Device NOT ready
>>    Request Sense returned 00 00 00
>>
>> If use some other old compiler to compile this u-boot, usb works fine in
>> that image.
>>
>> Some pls guide me what may be the difference.
>>
>>
> Your version of U-boot is about 3 years old.  Nobody will be interested
> in debugging it.  Please update to the latest and see if the problem exists.

This problem is indeed solved about a year ago. It was a problem with
all gcc-4.x ARM compilers that compiled the code badly.
It was solved by refactoring the code a little, such that the compiler
produces correct output. (see the code)

So, indeed: move to the current version. (the at91sam9260-ek board is
supported by mainline, so why do you use this prehistoric version
anyway?)

Kind Regards,

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

Re: [U-Boot] [PATCH v2 2/3] Fix 2k page size NAND for iMX27

[Eric Bénard]

Scott Wood a écrit :
> On Wed, Jul 15, 2009 at 05:18:40PM +0200, Eric Benard wrote:
>> +if (pdata->is2k) {
>> +host->pagesize_2k = 1;
>> +NFMS |= (1 << NFMS_BIT);
>> +this->badblock_pattern = &smallpage_memorybased;
> 
> Why are you using the small-page badblock pattern with large pages?
> 
that's what Freescale is doing in its Linux BSP and it doesn't work 
without, at least on my board (8 bits width NAND):

if (!this->badblock_pattern) {
if (mtd->writesize == NAND_PAGESIZE_2KB)
this->badblock_pattern = &smallpage_memorybased;
else
this->badblock_pattern = (mtd->writesize > 512) ?
&largepage_memorybased : &smallpage_memorybased;
}

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

Re: [U-Boot] [PATCH] Improve U-Boot Porting Guide in the README

[Wolfgang Denk]

Dear Brent Cook,

In message <200907161744.51888.bc...@bpointsys.com> you wrote:
>
> This is hilarious, though I am curious what the real-world analog to 
> 'return 0;' is :)

This depends on the caller's context. In case of hobby projects it
usually means be_happy(), show_others(), drink_beer() or the like,
where in commercial contexts it means send_invoice_to_customer().

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: w...@denx.de
To get something done, a committee should consist  of  no  more  than
three men, two of them absent.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] PATCH 2/2] Add pci/pcie E1000 ethernet support for MPC8544DS and MPC8536 boards

[Zang Roy-R61911]

 

> -Original Message-
> From: Ben Warren [mailto:biggerbadder...@gmail.com] 
> Sent: Friday, July 17, 2009 5:22 AM
> To: Wolfgang Denk
> Cc: Zang Roy-R61911; U-Boot-Denx; Kumar Gala
> Subject: Re: [U-Boot] PATCH 2/2] Add pci/pcie E1000 ethernet 
> support for MPC8544DS and MPC8536 boards
> 
> Wolfgang Denk wrote:
> > Dear Roy Zang,
> >
> > In message <1247105148.29920.3.ca...@rock.ap.freescale.net> 
> you wrote:
> >   
> >> Sorry for the mistake. It is my oversight when I 
> regenerate the patch
> >> before send out. 
> >> Pick up this one:
> >>
> >>   From: Roy Zang 
> >>Add pci/pcie E1000 ethernet support for MPC8544DS and 
> MPC8536 boards.
> >>Signed-off-by: Roy Zang 
> >> 
> >
> > Doesn't apply with git-am. Please use git-format-patch to create
> > patches.
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> >   
> Still undergoing review (sorry it's taking so long).  Please 
> don't apply 
> yet.
Sorry. It is really long, but I do not see reason to split it :-(.
In fact the kernel file is bigger than this one.
Thanks.
Roy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] PATCH 2/2] Add pci/pcie E1000 ethernet support for MPC8544DS and MPC8536 boards

[Zang Roy-R61911]

 

> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de] 
> Sent: Friday, July 17, 2009 6:26 AM
> To: Ben Warren
> Cc: Zang Roy-R61911; U-Boot-Denx; Kumar Gala
> Subject: Re: [U-Boot] PATCH 2/2] Add pci/pcie E1000 ethernet 
> support for MPC8544DS and MPC8536 boards
> 
> Dear Ben Warren,
> 
> In message <4a5f9a05.70...@gmail.com> you wrote:
> >
> > >>   From: Roy Zang 
> > >>Add pci/pcie E1000 ethernet support for MPC8544DS and 
> MPC8536 boards.
> > >>Signed-off-by: Roy Zang 
> > >
> > > Doesn't apply with git-am. Please use git-format-patch to create
> > > patches.
> ...
> > Still undergoing review (sorry it's taking so long).  
> Please don't apply 
> > yet.
> 
> I did not intend to meddle with your business. Just wanted to point
> out formal deficiencies of the patch.
I always use git-format-patch to create patches :-(. 
The issue maybe induced by wrong 
format when I reply the mail.
Anyway, I will resend it . Before that, I'd like to get Ben's feedback.
Thanks.
Roy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv3 3/3] 83xx, kmeter1: added NAND support

[Heiko Schocher]

Hello Scott

Scott Wood wrote:
> On Mon, Jul 13, 2009 at 12:15:12PM +0200, Heiko Schocher wrote:
>> +#define read_mode() in_8((volatile unsigned char __iomem *) \
>> +CONFIG_NAND_MODE_REG)
>> +#define write_mode(val) out_8((volatile unsigned char __iomem *) \
>> +CONFIG_NAND_MODE_REG, val)
>> +#define read_data() in_8((volatile unsigned char __iomem *) \
>> +CONFIG_NAND_DATA_REG)
>> +#define write_data(val) out_8((volatile unsigned char __iomem *) \
>> +CONFIG_NAND_DATA_REG, val)
> 
> No need for volatile when using accessors.  If you kept a pointer around
> instead of casting here, you could reasonably use the accessors directly
> without needing wrappers...
> 
> If this is purely for U-Boot and not shared with Linux we can drop the
> __iomem.

OK, I fix it.

>> +static void kpn_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int 
>> ctrl)
>> +{
>> +u8  reg_val = read_mode();
> 
> No tab after "u8".
> 
>> +if (ctrl & NAND_CTRL_CHANGE) {
>> +if ( ctrl & NAND_NCE)
> 
> No space after "(".

Yep, you are right. Fixed.

>> +reg_val = reg_val & ~KPN_CE1N;
>> +else
>> +reg_val = reg_val | KPN_CE1N;
>> +write_mode(reg_val);
>> +}
>> +if (cmd == NAND_CMD_NONE)
>> +return;
>> +
>> +reg_val = reg_val & ~(KPN_ALE + KPN_CLE);
>> +if (ctrl & NAND_CLE)
>> +reg_val = reg_val | KPN_CLE;
>> +if (ctrl & NAND_ALE)
>> +reg_val = reg_val | KPN_ALE;
> 
> If ALE/CLE is sticky in the hardware mode register, you could probably
> move this under NAND_CTRL_CHANGE and simplify things a little.

I try this out.

>> diff --git a/include/configs/kmeter1.h b/include/configs/kmeter1.h
>> index 811ba88..4de0dfc 100644
>> --- a/include/configs/kmeter1.h
>> +++ b/include/configs/kmeter1.h
>> @@ -324,6 +324,12 @@
>>  #define CONFIG_SYS_DTT_HYSTERESIS   3
>>  #define CONFIG_SYS_DTT_BUS_NUM  (CONFIG_SYS_MAX_I2C_BUS)
>>
>> +#if defined(CONFIG_CMD_NAND)
>> +#define CONFIG_NAND_KMETER1
> 
> No tab after #define.

fixed.

>> +#define CONFIG_SYS_MAX_NAND_DEVICE  1
>> +#define CONFIG_SYS_NAND_BASECONFIG_SYS_PIGGY_BASE
>> +#endif
>> +
>>  #if defined(CONFIG_PCI)
>>  #define CONFIG_CMD_PCI
>>  #endif
> 
> This file looks a little different in the current tree (2 rather than
> CONFIG_SYS_MAX_I2C_BUS), so it wouldn't apply cleanly.

Hmm... this is the third patch of a patchset, so it apply cleanly, if
the other 2 patches are first applied ... or should I base this patch
against current nand-flash tree, because this patch goes through your
tree?

thanks for reviewing
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add bootstrap command

[Stefan Roese]

On Thursday 16 July 2009 22:08:27 Matthias Fuchs wrote:
> > OK. But if your "sbe" command is "better" than the current bootstrap one,
> > then let's see if it makes sense to use your command as the common one.
>
> Dirk's approach is very generic. Putting nothing but the EEPROM data and a
> descriptive table into the board file is what we need.

I'm aware of this, since I suggested to Dirk to implement it this way. ;)

> I only suggest to
> add an additional label to each entry that is used instead of using numbers
> and I'd to pass this label as argument instead of the a number. One could
> use the numbers as labels also :-)

Ack.

> When you do no pass the argument we could either print the descriptive
> texts as menu (as DIrk did so far) and wait for input or just print the
> texts as kind of help and the must supply an argument if he want to change
> something (I prefer the latter).

Yes, just printing all available config options when called without parameter 
is what I prefer as well. Something like this:

=> 4xx_config (or 4xx_bootstrap)
Available configurations:
  NameCPU  PLB  OPB  EBC  Boot-Location
  1   333  133  66   66   NOR
  2   333  133  66   66   NAND
  3   333  133  66   66   PCI
  4   400  133  66   66   NOR
  5   400  133  66   66   NAND
  6   400  160  80   53   NOR
  ...

The board maintainer could of course use real "names" instead of the numbers 
here.

> > > > Does you command support more features? What's the main
> > > > difference?
> > >
> > > Much simpler. Just call sbe with a descriptive argument like a CPU
> > > frequency or something like '667-66' on a 440EPx target with 66Mhz PCI
> > > clock or 'sr-test-only' for something you will remove later :-). This
> > > has two advantages over just using
> > > numbers: You can remove configurations without making the following
> > > configs in the table moving to the front and its a little more secure
> > > meaning you have to type a couple of valid character to  reconfigure
> > > the clocking. Just using "bootstrap 5" is error-prone.
> >
> > Ack.
> >
> > > Well, I like my syntax and behavior, but I do not want to totally
> > > dismiss Dirk's idea as long as I can keep my sbe command :-)
> >
> > Seems that "your" command is not so bad. ;) I'll take a look at it
> > tomorrow. Perhaps we can use some of your ideas in such a new common
> > (PPC4xx) implementation. :)
>
> My implementation is nothing but ar if-!strcmp-else-if-!strcmp
> implementation. But putting things together is a good idea.

Yes, the implementation itself is non-optimal. I'll send an updated version of 
Dirk's patch with the "new" user interface and a new command-naming 
(hopefully) today.

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

Re: [U-Boot] [PATCH] Add bootstrap command

[Stefan Roese]

On Friday 17 July 2009 02:12:45 Dave Mitchell wrote:
> >> Keep in mind the processor UM documentation section that covers these
> >> boot methods is labeled "Bootstrap Operations". It refers the registers
> >> that the EEPROM values populate as "bootstrap registers", etc.
> >
> > Yes, I know. But then, bootstrapping [1] is  really  a  name  with  a
> > _very_ fuzzy meaning. It can be anything. The fact thay it was chosen
> > in  the  UM documentation does't make it better - in U-Boot context I
> > think about other activities, and in Linux context  yet  about  other
> > things.
>
> In general, the term does have a "fuzzy" meaning. But within the AMCC
> 4xx processors, it does not. And we are talking about a command that
> would only be available to AMCC 4xx processors.
>
> A command that's been in use on several U-Boot 4xx ports for some time.

I'm aware of this fact. And changing this name is of course non-optimal. But 
from my point of view, the advantages of enhancing this command and making it 
easier usable/portable for all 4xx boards overweight this disadvantage.

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

Re: [U-Boot] USB not working with 4.3.2 gcc compiler in u-boot 1.1.5

[Ben Warren]

virupax wrote:
> Hi
>
> I am using  arm-unknown-linux-gnueabi-gcc 4.3.2 compiler to compile the
> u-boot 1.1.5 for the at91sam9260 board. When i use this u-boot image usb
> start command is not detecting the connected usb stick.
> Request Sense returned 00 00 00
> Device NOT ready
>Request Sense returned 00 00 00
>
> If use some other old compiler to compile this u-boot, usb works fine in
> that image.
>
> Some pls guide me what may be the difference.
>
>   
Your version of U-boot is about 3 years old.  Nobody will be interested 
in debugging it.  Please update to the latest and see if the problem exists.

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

[U-Boot] USB not working with 4.3.2 gcc compiler in u-boot 1.1.5

[virupax]

Hi

I am using  arm-unknown-linux-gnueabi-gcc 4.3.2 compiler to compile the
u-boot 1.1.5 for the at91sam9260 board. When i use this u-boot image usb
start command is not detecting the connected usb stick.
Request Sense returned 00 00 00
Device NOT ready
   Request Sense returned 00 00 00

If use some other old compiler to compile this u-boot, usb works fine in
that image.

Some pls guide me what may be the difference.



 

-- 
View this message in context: 
http://www.nabble.com/USB-not-working-with-4.3.2-gcc-compiler-in-u-boot-1.1.5-tp24528292p24528292.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

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

Re: [U-Boot] [PATCH] Convert SMC911X Ethernet driver to CONFIG_NET_MULTI API

[Ben Warren]

Mike Frysinger wrote:
> couple changes to squash into this:
>  - fix build error for systems using in 16bit
>  - tweak bf548-ezkit update
>  - do not leak priv malloc() if dev malloc() failed
>  - make sure we clear eth_device (we really need a zalloc())
>  - initialize dev->enetaddr in the driver register func
>  - initialize the driver mac with dev->enetaddr
>
> seems to work on my bf548-ezkit:


Wow, that was quick!  Thanks!

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

Re: [U-Boot] [PATCH] Convert SMC911X Ethernet driver to CONFIG_NET_MULTI API

[Mike Frysinger]

couple changes to squash into this:
 - fix build error for systems using in 16bit
 - tweak bf548-ezkit update
 - do not leak priv malloc() if dev malloc() failed
 - make sure we clear eth_device (we really need a zalloc())
 - initialize dev->enetaddr in the driver register func
 - initialize the driver mac with dev->enetaddr

seems to work on my bf548-ezkit:

Net:   smc911x-0
Hit any key to stop autoboot:  0
bfin> t 0 u-boot.bin
smc911x: initializing
smc911x: detected LAN9218 controller
smc911x: phy initialized
smc911x: MAC 00:e0:22:fe:bd:04
Using smc911x-0 device
TFTP from server 192.168.0.2; our IP address is 192.168.0.15
Filename 'u-boot.bin'.
Load address: 0x0
Loading: ##
done
Bytes transferred = 258112 (3f040 hex)
bfin>

-mike

diff --git a/board/bf548-ezkit/bf548-ezkit.c b/board/bf548-ezkit/bf548-ezkit.c
index 69a581b..88a0cd4 100644
--- a/board/bf548-ezkit/bf548-ezkit.c
+++ b/board/bf548-ezkit/bf548-ezkit.c
@@ -79,12 +79,9 @@ int board_early_init_f(void)
return 0;
 }
 
+#ifdef CONFIG_SMC911X
 int board_eth_init(bd_t *bis)
 {
-   int rc = 0;
-#ifdef CONFIG_SMC911X
-   rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
-#endif
-   return rc;
+   return smc911x_initialize(0, CONFIG_SMC911X_BASE);
 }
-
+#endif
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 9eb080f..2bbd7ea 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -37,49 +37,17 @@ void pkt_data_push(struct eth_device *dev, u32 addr, u32 
val) \
 
 #define mdelay(n)   udelay((n)*1000)
 
-static int smx911x_handle_mac_address(struct eth_device *dev)
+static void smx911x_handle_mac_address(struct eth_device *dev)
 {
unsigned long addrh, addrl;
-   uchar m[6];
-   char env_parm_name[10];  /* Long enough for ethxxaddr */
-   u8 dev_num = ((struct smc911x_priv *)(dev->priv))->dev_num;
-
-   if (dev_num == 0)
-   strncpy(env_parm_name, "ethaddr", 7);
-   else
-   sprintf(env_parm_name, "eth%huaddr", dev_num);
-
-   if (eth_getenv_enetaddr(env_parm_name, m)) {
-   /* if the environment has a valid mac address then use it */
-   addrl = m[0] | (m[1] << 8) | (m[2] << 16) | (m[3] << 24);
-   addrh = m[4] | (m[5] << 8);
-   smc911x_set_mac_csr(dev, ADDRL, addrl);
-   smc911x_set_mac_csr(dev, ADDRH, addrh);
-   } else {
-   /* if not, try to get one from the eeprom */
-   addrh = smc911x_get_mac_csr(dev, ADDRH);
-   addrl = smc911x_get_mac_csr(dev, ADDRL);
-
-   m[0] = (addrl   ) & 0xff;
-   m[1] = (addrl >>  8 ) & 0xff;
-   m[2] = (addrl >> 16 ) & 0xff;
-   m[3] = (addrl >> 24 ) & 0xff;
-   m[4] = (addrh   ) & 0xff;
-   m[5] = (addrh >>  8 ) & 0xff;
-
-   /* we get 0xff when there is no eeprom connected */
-   if ((m[0] & m[1] & m[2] & m[3] & m[4] & m[5]) == 0xff) {
-   printf(DRIVERNAME ": no valid mac address in "
-   "environment and no eeprom found\n");
-   return -1;
-   }
-
-   eth_setenv_enetaddr(env_parm_name, m);
-   }
+   uchar *m = dev->enetaddr;
 
-   printf(DRIVERNAME ": MAC %pM\n", m);
+   addrl = m[0] | (m[1] << 8) | (m[2] << 16) | (m[3] << 24);
+   addrh = m[4] | (m[5] << 8);
+   smc911x_set_mac_csr(dev, ADDRL, addrl);
+   smc911x_set_mac_csr(dev, ADDRH, addrh);
 
-   return 0;
+   printf(DRIVERNAME ": MAC %pM\n", m);
 }
 
 static int smc911x_miiphy_read(struct eth_device *dev,
@@ -188,8 +156,7 @@ static int smc911x_init(struct eth_device *dev, bd_t * bd)
/* Configure the PHY, initialize the link state */
smc911x_phy_configure(dev);
 
-   if ((smx911x_handle_mac_address(dev)) < 0)
-   goto err_out;
+   smx911x_handle_mac_address(dev);
 
/* Turn on Tx + Rx */
smc911x_enable(dev);
@@ -274,16 +241,34 @@ static int smc911x_rx(struct eth_device *dev)
 
 int smc911x_initialize(u8 dev_num, int base_addr)
 {
-   struct smc911x_priv *priv = malloc(sizeof(struct smc911x_priv));
+   unsigned long addrl, addrh;
+   struct smc911x_priv *priv;
+   struct eth_device *dev;
+
+   priv = malloc(sizeof(*priv));
if (!priv)
return 0;
-   struct eth_device *dev = malloc(sizeof(struct eth_device));
-   if (!dev)
+
+   dev = malloc(sizeof(*dev));
+   if (!dev) {
+   free(dev);
return 0;
+   }
+   memset(dev, 0, sizeof(*dev));
+
priv->dev_num = dev_num;
dev->priv = priv;
dev->iobase = base_addr;
 
+   addrh = smc911x_get_mac_csr(dev, ADDRH);
+   addrl = smc911x_get_mac_csr(dev, ADDRL);
+   dev->enetaddr[0] = addrl;
+   dev->enetaddr[1] = addrl >>  8;
+   dev->enetaddr[2] = addrl >> 16;
+   dev->enetaddr[3] = addrl 

Re: [U-Boot] [PATCH] Convert SMC911X Ethernet driver to CONFIG_NET_MULTI API

[Ben Warren]

Ben Warren wrote:
> All in-tree boards that use this controller have CONFIG_NET_MULTI added
> Also:
>  - changed CONFIG_DRIVER_SMC911X* to CONFIG_SMC911X*
>  - cleaned up line lengths 
>  - modified all boards that override weak function in this driver
>
> Signed-off-by: Ben Warren 
> ---
Note: I haven't actually *tested* this code, only verified that it 
compiles cleanly on an ARM platform and that the appropriate weak 
functions are overridden (looked in System.map).  Although the changes 
are mainly cosmetic, there's a very good chance that bugs were 
introduced, so if anybody can try it please do!

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

[U-Boot] [PATCH] Convert SMC911X Ethernet driver to CONFIG_NET_MULTI API

[Ben Warren]

All in-tree boards that use this controller have CONFIG_NET_MULTI added
Also:
 - changed CONFIG_DRIVER_SMC911X* to CONFIG_SMC911X*
 - cleaned up line lengths 
 - modified all boards that override weak function in this driver

Signed-off-by: Ben Warren 
---
 board/bf548-ezkit/bf548-ezkit.c |   11 ++
 board/cm-bf548/cm-bf548.c   |   10 ++
 board/freescale/mx31pdk/mx31pdk.c   |   10 ++
 board/imx31_litekit/imx31_litekit.c |   10 ++
 board/imx31_phycore/imx31_phycore.c |   10 ++
 board/micronas/vct/ebi_smc911x.c|   22 -
 board/micronas/vct/vct.c|   10 ++
 board/omap3/evm/evm.c   |   10 ++
 board/renesas/ap325rxa/ap325rxa.c   |   10 ++
 board/renesas/rsk7203/rsk7203.c |   17 +++-
 drivers/net/Makefile|2 +-
 drivers/net/smc911x.c   |  151 +++---
 drivers/net/smc911x.h   |  173 +++
 include/configs/ap325rxa.h  |7 +-
 include/configs/bf548-ezkit.h   |7 +-
 include/configs/cm-bf548.h  |7 +-
 include/configs/imx31_litekit.h |7 +-
 include/configs/imx31_phycore.h |7 +-
 include/configs/mx31pdk.h   |7 +-
 include/configs/omap3_evm.h |7 +-
 include/configs/rsk7203.h   |7 +-
 include/configs/vct.h   |9 +-
 include/netdev.h|1 +
 23 files changed, 341 insertions(+), 171 deletions(-)

diff --git a/board/bf548-ezkit/bf548-ezkit.c b/board/bf548-ezkit/bf548-ezkit.c
index 74f93ba..69a581b 100644
--- a/board/bf548-ezkit/bf548-ezkit.c
+++ b/board/bf548-ezkit/bf548-ezkit.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -77,3 +78,13 @@ int board_early_init_f(void)
 
return 0;
 }
+
+int board_eth_init(bd_t *bis)
+{
+   int rc = 0;
+#ifdef CONFIG_SMC911X
+   rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+#endif
+   return rc;
+}
+
diff --git a/board/cm-bf548/cm-bf548.c b/board/cm-bf548/cm-bf548.c
index 1c26600..796263d 100644
--- a/board/cm-bf548/cm-bf548.c
+++ b/board/cm-bf548/cm-bf548.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -77,3 +78,12 @@ int board_early_init_f(void)
 
return 0;
 }
+
+int board_eth_init(bd_t *bis)
+{
+   int rc = 0;
+#ifdef CONFIG_SMC911X
+   rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+#endif
+   return rc;
+}
diff --git a/board/freescale/mx31pdk/mx31pdk.c 
b/board/freescale/mx31pdk/mx31pdk.c
index 6b60c17..9f47169 100644
--- a/board/freescale/mx31pdk/mx31pdk.c
+++ b/board/freescale/mx31pdk/mx31pdk.c
@@ -25,6 +25,7 @@
 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -61,3 +62,12 @@ int checkboard(void)
printf("Board: i.MX31 MAX PDK (3DS)\n");
return 0;
 }
+
+int board_eth_init(bd_t *bis)
+{
+   int rc = 0;
+#ifdef CONFIG_SMC911X
+   rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+#endif
+   return rc;
+}
diff --git a/board/imx31_litekit/imx31_litekit.c 
b/board/imx31_litekit/imx31_litekit.c
index cb3e174..2ac622d 100644
--- a/board/imx31_litekit/imx31_litekit.c
+++ b/board/imx31_litekit/imx31_litekit.c
@@ -23,6 +23,7 @@
 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -75,3 +76,12 @@ int checkboard (void)
printf("Board: i.MX31 Litekit\n");
return 0;
 }
+
+int board_eth_init(bd_t *bis)
+{
+   int rc = 0;
+#ifdef CONFIG_SMC911X
+   rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+#endif
+   return rc;
+}
diff --git a/board/imx31_phycore/imx31_phycore.c 
b/board/imx31_phycore/imx31_phycore.c
index 92aba96..3d7b7f7 100644
--- a/board/imx31_phycore/imx31_phycore.c
+++ b/board/imx31_phycore/imx31_phycore.c
@@ -24,6 +24,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -128,3 +129,12 @@ int checkboard (void)
printf("Board: Phytec phyCore i.MX31\n");
return 0;
 }
+
+int board_eth_init(bd_t *bis)
+{
+   int rc = 0;
+#ifdef CONFIG_SMC911X
+   rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+#endif
+   return rc;
+}
diff --git a/board/micronas/vct/ebi_smc911x.c b/board/micronas/vct/ebi_smc911x.c
index e1b67a0..c9ef33d 100644
--- a/board/micronas/vct/ebi_smc911x.c
+++ b/board/micronas/vct/ebi_smc911x.c
@@ -18,6 +18,7 @@
  */
 
 #include 
+#include 
 #include 
 #include "vct.h"
 
@@ -45,10 +46,11 @@ int ebi_init_smc911x(void)
  * Accessor functions replacing the "weak" functions in
  * drivers/net/smc911x.c
  */
-u32 smc911x_reg_read(u32 addr)
+u32 smc911x_reg_read(struct eth_device *dev, u32 addr)
 {
volatile u32 data;
 
+   addr += dev->iobase;
reg_write(EBI_DEV1_CONFIG2(EBI_BASE), 0x004F);
ebi_wait();
reg_write(EBI_CPU_IO_ACCS(EBI_BASE), (EXT_DEVICE_CHANNEL_1 | addr));
@@ -58,8 +60,9 @@ u32 smc911x_reg_read(u32 addr)
return (data);
 }
 
-void smc911x_reg_write(u32 addr, u32 data)
+void smc911x_reg_write(struct eth_device *dev, u32 addr, u32 data)
 {
+   

Re: [U-Boot] [PATCH] ARM Cortex A8: Move OMAP3 specific reset handler to OMAP3 code

[Minkyu Kang]

Dear Jean and Dirk,

>  cpu/arm_cortexa8/omap3/lowlevel_init.S |   12 
>  cpu/arm_cortexa8/start.S   |   14 --
>  2 files changed, 12 insertions(+), 14 deletions(-)
>
> Index: u-boot-arm/cpu/arm_cortexa8/omap3/lowlevel_init.S
> ===
> --- u-boot-arm.orig/cpu/arm_cortexa8/omap3/lowlevel_init.S
> +++ u-boot-arm/cpu/arm_cortexa8/omap3/lowlevel_init.S
> @@ -181,6 +181,18 @@ lowlevel_init:
>/* back to arch calling code */
>mov pc, lr
>  +.global reset_cpu
> +reset_cpu:
> +  ldr r1, rstctl  @ get addr for global reset
> +  @ reg
> +  mov r3, #0x2@ full reset pll + mpu
> +  str r3, [r1]@ force reset
> +  mov r0, r0
> +_loop_forever:
> +  b   _loop_forever
> +rstctl:
> +  .word   PRM_RSTCTRL
> +
 please move this to reset.S other wise fine
>>> Most probably your idea is that each file should only contain
>>> functionality which fits 100% (120%?) what the file name implies (?).
>>> While from general point of view this is correct, it makes no sense to
>>> create new files again and again just to follow this rule. We already
>>> created a cache.c on your request, now you request a new file reset.S
>>> for ~5 assembly lines. This new file would contain more comments (e.g.
>>> GPL header) than useful code.
>> the idea is different here
>> I want to have only code in lowlevel_init.S that can be disable by
>> CONFIG_SKIP_LOWLEVEL_INIT and do it via Makefile
>
> Looking at recent OMAP3 lowlevel_init.S most probably some other stuff
> has to be moved to make this work, too. So for the moment, the
> cleanest way is to move above reset_cpu to low_levelinit.S. And then
> later, after thorough investigation and testing, move the stuff needed
> for your idea to an appropriate place. This move will be consistent
> then and will avoid polluting source tree with unnecessary files until
> then.
>
> So let's do it in two steps:
>
> a) Now, move reset_cpu to lowlevel_init.S so that Riverful can go on
> with his work
>
> b) Later, move everything necessary in one consistent patch set while
> you implement your "CONFIG_SKIP_LOWLEVEL_INIT via Makefile" idea
>

As you known riverful and me prepare the new SOC (s5pc100) patch.
so, we've been waiting for this issue to be resolved.
Please let me know how do you solve this problem.

I think... as Wolfgang said.. it would be better make new file.

I hope to be progressed this issue :)
thanks

-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [patch] rm9200 lowevel_init: don't touch reserved/readonly registers

[David Brownell]

For some reason the AT91rm9200 lowlevel init writes to a bunch of
reserved or read-only addresses.  All the boards seem to define the
value-to-be-written values as zero ... but they shouldn't actually
be writing *anything* there.

No documented erratum justifies these accesses.  It looks like maybe
some pre-release BDI-2000 setup code has been carried along by cargo
cult programming since at least late 2004 (per GIT history).

Here's a patch disabling what seems to be bogosity.  Tested on a
csb337; there were no behavioral changes.
---
 cpu/arm920t/at91rm9200/lowlevel_init.S |   14 ++
 include/configs/at91rm9200dk.h |5 -
 include/configs/at91rm9200ek.h |5 -
 include/configs/cmc_pu2.h  |5 -
 include/configs/csb637.h   |5 -
 include/configs/m501sk.h   |5 -
 include/configs/mp2usb.h   |5 -
 7 files changed, 2 insertions(+), 42 deletions(-)

--- a/cpu/arm920t/at91rm9200/lowlevel_init.S
+++ b/cpu/arm920t/at91rm9200/lowlevel_init.S
@@ -81,6 +81,7 @@ LoopOsc:
bne 0b
/* delay - this is all done by guess */
ldr r0, =0x0001
+   /* (vs reading PMC_SR for LOCKA, LOCKB ... or MOSCS earlier) */
 1:
subsr0, r0, #1
bhi 1b
@@ -108,16 +109,6 @@ LoopOsc:
.ltorg
 
 SMRDATA:
-   .word AT91C_MC_PUIA
-   .word CONFIG_SYS_MC_PUIA_VAL
-   .word AT91C_MC_PUP
-   .word CONFIG_SYS_MC_PUP_VAL
-   .word AT91C_MC_PUER
-   .word CONFIG_SYS_MC_PUER_VAL
-   .word AT91C_MC_ASR
-   .word CONFIG_SYS_MC_ASR_VAL
-   .word AT91C_MC_AASR
-   .word CONFIG_SYS_MC_AASR_VAL
.word AT91C_EBI_CFGR
.word CONFIG_SYS_EBI_CFGR_VAL
.word AT91C_SMC_CSR0
@@ -128,8 +119,7 @@ SMRDATA:
.word CONFIG_SYS_PLLBR_VAL
.word AT91C_MCKR
.word CONFIG_SYS_MCKR_VAL
-   /* SMRDATA is 80 bytes long */
-   /* here there's a delay of 100 */
+   /* here there's a delay */
 SMRDATA1:
.word AT91C_PIOC_ASR
.word CONFIG_SYS_PIOC_ASR_VAL
--- a/include/configs/at91rm9200dk.h
+++ b/include/configs/at91rm9200dk.h
@@ -45,11 +45,6 @@
 #ifndef CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_SYS_USE_MAIN_OSCILLATOR 1
 /* flash */
-#define CONFIG_SYS_MC_PUIA_VAL 0x
-#define CONFIG_SYS_MC_PUP_VAL  0x
-#define CONFIG_SYS_MC_PUER_VAL 0x
-#define CONFIG_SYS_MC_ASR_VAL  0x
-#define CONFIG_SYS_MC_AASR_VAL 0x
 #define CONFIG_SYS_EBI_CFGR_VAL0x
 #define CONFIG_SYS_SMC_CSR0_VAL0x3284 /* 16bit, 2 TDF, 4 WS */
 
--- a/include/configs/at91rm9200ek.h
+++ b/include/configs/at91rm9200ek.h
@@ -56,11 +56,6 @@
 #ifndef CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_SYS_USE_MAIN_OSCILLATOR 1
 /* flash */
-#define CONFIG_SYS_MC_PUIA_VAL 0x
-#define CONFIG_SYS_MC_PUP_VAL  0x
-#define CONFIG_SYS_MC_PUER_VAL 0x
-#define CONFIG_SYS_MC_ASR_VAL  0x
-#define CONFIG_SYS_MC_AASR_VAL 0x
 #define CONFIG_SYS_EBI_CFGR_VAL0x
 #define CONFIG_SYS_SMC_CSR0_VAL0x3284 /* 16bit, 2 TDF, 4 WS */
 
--- a/include/configs/cmc_pu2.h
+++ b/include/configs/cmc_pu2.h
@@ -44,11 +44,6 @@
 #ifndef CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_SYS_USE_MAIN_OSCILLATOR 1
 /* flash */
-#define CONFIG_SYS_MC_PUIA_VAL 0x
-#define CONFIG_SYS_MC_PUP_VAL  0x
-#define CONFIG_SYS_MC_PUER_VAL 0x
-#define CONFIG_SYS_MC_ASR_VAL  0x
-#define CONFIG_SYS_MC_AASR_VAL 0x
 #define CONFIG_SYS_EBI_CFGR_VAL0x
 #define CONFIG_SYS_SMC_CSR0_VAL0x100032ad /* 16bit, 2 TDF, 4 WS */
 
--- a/include/configs/csb637.h
+++ b/include/configs/csb637.h
@@ -45,11 +45,6 @@
 #ifndef CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_SYS_USE_MAIN_OSCILLATOR 1
 /* flash */
-#define CONFIG_SYS_MC_PUIA_VAL 0x
-#define CONFIG_SYS_MC_PUP_VAL  0x
-#define CONFIG_SYS_MC_PUER_VAL 0x
-#define CONFIG_SYS_MC_ASR_VAL  0x
-#define CONFIG_SYS_MC_AASR_VAL 0x
 #define CONFIG_SYS_EBI_CFGR_VAL0x
 #define CONFIG_SYS_SMC_CSR0_VAL0x3284 /* 16bit, 2 TDF, 4 WS */
 
--- a/include/configs/m501sk.h
+++ b/include/configs/m501sk.h
@@ -46,11 +46,6 @@
  */
 #define CONFIG_SYS_USE_MAIN_OSCILLATOR 1
 /* flash */
-#define CONFIG_SYS_MC_PUIA_VAL 0x
-#define CONFIG_SYS_MC_PUP_VAL  0x
-#define CONFIG_SYS_MC_PUER_VAL 0x
-#define CONFIG_SYS_MC_ASR_VAL  0x
-#define CONFIG_SYS_MC_AASR_VAL 0x
 #define CONFIG_SYS_EBI_CFGR_VAL0x
 #define CONFIG_SYS_SMC_CSR0_VAL0x3284 /* 16bit, 2 TDF, 4 WS */
 
--- a/include/configs/mp2usb.h
+++ b/include/configs/mp2usb.h
@@ -49,11 +49,6 @@
 #ifndef CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_SYS_USE_MAIN_OSCILLATOR 1
 /* flash */
-#define CONFIG_SYS_MC_PUIA_VAL 0x
-#define CONFIG_SYS_MC_PUP_VAL  0x
-#define CONFIG_SYS_MC_PUER_

Re: [U-Boot] [patch/rfc] rm9200 lowevel_init: don't touch reserved/readonly registers

[David Brownell]

On Friday 10 July 2009, Wolfgang Denk wrote:
> Dear David Brownell,
> 
> In message <200906282241.54948.davi...@pacbell.net> you wrote:
> > On Tuesday 09 June 2009, David Brownell wrote:
> > > 
> > > Meanwhile, here's a patch/RFC disabling what seems to be bogosity.
> > > If it's eventually a "go", the supporting code should be removed.
> > 
> > No comments?
> 
> If no comments come for a patch-RFC for some days, you should try and
> re-post itas a real patch.

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

[U-Boot] USB storage device read very slow

[Dushara Jayasinghe]

Hi all,

I'm trying to boot linux from a USB flash stick and I found the read operations 
to be very slow. Upon further investigation, I found the bottleneck to be 
caused by a call to wait_ms(5). (See line 663 @ 
http://git.denx.de/?p=u-boot/u-boot-mpc83xx.git;a=blob;f=common/usb_storage.c;hb=792a09eb9d5d8c4f74b7e9f2e887316d511a4e80).
 I'm not sure why this call is necessary as usb_bulk_msg() checks the device 
status anyway.

I removed the call to wait_ms, without any adverse effect but could someone 
explain what this piece of code is trying to achieve?

Thanks in advance,

Dushara



Dushara Jayasinghe
Phone : +61 3 9538-3397 <>
This email may contain confidential information. If you have received this 
email in error, please delete it immediately, and inform us of the mistake by 
return email. Any form of reproduction, or further dissemination of this email 
is strictly prohibited. Also, please note that opinions expressed in this email 
are those of the author, and are not necessarily those of Optiscan Pty Ltd.


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

[U-Boot] [PATCH 2/2] Remove legacy NAND and disk on chip references from boards.

[Scott Wood]

Signed-off-by: Scott Wood 
---
Applied to u-boot-nand-flash.

If any of these boards are still maintained, please test to make sure
they still work (albeit without NAND -- or you can add support for
non-legacy NAND).

A few of these boards were not using legacy NAND, but had some leftover
cruft from it -- again, please make sure that I didn't break anything,
remove too much, or miss something that should have been removed.

I've got MAKEALLs running for ppc and arm that I'll let run overnight,
but currently there are a lot of unrelated errors (especially on ARM
with libgcc problems), so I may miss something.

 board/delta/nand.c|4 --
 board/esd/common/auto_update.c|   50 ---
 board/g2000/g2000.c   |   15 --
 board/netphone/netphone.c |   16 --
 board/netta/netta.c   |   15 --
 board/netta2/netta2.c |   16 --
 board/netvia/netvia.c |   15 --
 board/omap2420h4/omap2420h4.c |   23 -
 board/samsung/smdk6400/smdk6400.c |   11 
 board/sixnet/sixnet.c |5 --
 board/stxxtc/stxxtc.c |   16 --
 board/zylonite/nand.c |4 --
 include/configs/BMW.h |4 --
 include/configs/CATcenter.h   |8 ---
 include/configs/CPU86.h   |   10 
 include/configs/CPU87.h   |4 --
 include/configs/G2000.h   |   20 ---
 include/configs/GEN860T.h |   17 --
 include/configs/MIP405.h  |   10 
 include/configs/NETPHONE.h|   86 
 include/configs/NETTA.h   |   99 -
 include/configs/NETTA2.h  |   86 
 include/configs/NETVIA.h  |   74 ---
 include/configs/PCIPPC2.h |   12 -
 include/configs/PCIPPC6.h |   12 -
 include/configs/PIP405.h  |4 --
 include/configs/PM520.h   |   22 
 include/configs/PM826.h   |   14 -
 include/configs/PM828.h   |   13 -
 include/configs/PPChameleonEVB.h  |   26 --
 include/configs/RBC823.h  |9 ---
 include/configs/SXNI855T.h|   67 -
 include/configs/TQM85xx.h |2 -
 include/configs/VCMA9.h   |   38 --
 include/configs/at91rm9200dk.h|   30 ---
 include/configs/csb637.h  |   32 
 include/configs/delta.h   |9 ---
 include/configs/m501sk.h  |5 --
 include/configs/omap2420h4.h  |   36 -
 include/configs/sbc2410x.h|   23 -
 include/configs/stxxtc.h  |   82 --
 include/configs/svm_sc8xx.h   |4 --
 include/configs/zylonite.h|8 ---
 43 files changed, 0 insertions(+), 1056 deletions(-)

diff --git a/board/delta/nand.c b/board/delta/nand.c
index aff7c54..e87d502 100644
--- a/board/delta/nand.c
+++ b/board/delta/nand.c
@@ -23,7 +23,6 @@
 #include 
 
 #if defined(CONFIG_CMD_NAND)
-#if !defined(CONFIG_NAND_LEGACY)
 
 #include 
 #include 
@@ -550,7 +549,4 @@ int board_nand_init(struct nand_chip *nand)
return 0;
 }
 
-#else
- #error "U-Boot legacy NAND support not available for Monahans DFC."
-#endif
 #endif
diff --git a/board/esd/common/auto_update.c b/board/esd/common/auto_update.c
index 33aeb46..c4a49e2 100644
--- a/board/esd/common/auto_update.c
+++ b/board/esd/common/auto_update.c
@@ -27,9 +27,6 @@
 #include 
 #include 
 #include 
-#if defined(CONFIG_NAND_LEGACY)
-#include 
-#endif
 #include 
 #include 
 
@@ -58,20 +55,6 @@ extern int flash_sect_erase(ulong, ulong);
 extern int flash_sect_protect (int, ulong, ulong);
 extern int flash_write (char *, ulong, ulong);
 
-#if defined(CONFIG_CMD_NAND) && defined(CONFIG_NAND_LEGACY)
-/* references to names in cmd_nand.c */
-#define NANDRW_READ0x01
-#define NANDRW_WRITE   0x00
-#define NANDRW_JFFS2   0x02
-#define NANDRW_JFFS2_SKIP  0x04
-extern struct nand_chip nand_dev_desc[];
-extern int nand_legacy_rw(struct nand_chip* nand, int cmd,
- size_t start, size_t len,
- size_t * retlen, u_char * buf);
-extern int nand_legacy_erase(struct nand_chip* nand, size_t ofs,
-size_t len, int clean);
-#endif
-
 extern block_dev_desc_t ide_dev_desc[CONFIG_SYS_IDE_MAXDEVICE];
 
 int au_check_cksum_valid(int i, long nbytes)
@@ -158,9 +141,6 @@ int au_do_update(int i, long sz)
int off, rc;
uint nbytes;
int k;
-#if defined(CONFIG_CMD_NAND) && defined(CONFIG_NAND_LEGACY)
-   int total;
-#endif
 
hdr = (image_header_t *)LOAD_ADDR;
 #if defined(CONFIG_FIT)
@@ -240,15 +220,6 @@ int au_do_update(int i, long sz)
au_image[i].name);
debug ("flash_sect_erase(%lx, %lx);\n", start, end);
flash_sect_erase (star

Re: [U-Boot] [PATCH] Add bootstrap command

[Dave Mitchell]

On 7/16/2009 5:11 PM, Wolfgang Denk wrote:
> Dear Dave Mitchell,
>
> In message<4a5f8a1d.4030...@gmail.com>  you wrote:
>>> Please find a better description (avoiding "bootstrap"), and then
>>> chose a descriptive name.
>> Keep in mind the processor UM documentation section that covers these
>> boot methods is labeled "Bootstrap Operations". It refers the registers
>> that the EEPROM values populate as "bootstrap registers", etc.
>
> Yes, I know. But then, bootstrapping [1] is  really  a  name  with  a
> _very_ fuzzy meaning. It can be anything. The fact thay it was chosen
> in  the  UM documentation does't make it better - in U-Boot context I
> think about other activities, and in Linux context  yet  about  other
> things.

In general, the term does have a "fuzzy" meaning. But within the AMCC 
4xx processors, it does not. And we are talking about a command that 
would only be available to AMCC 4xx processors.

A command that's been in use on several U-Boot 4xx ports for some time.

>
>> There is some logic in tying the section of the processor manual to the
>> command. Whatever the command ends up being labeled, it would be nice if
>> its purpose was clear to those who actually work in 4xx space.
>
> We are changing the CPU configuration, right? It has nothing to do
> with actually booting or bootstrapping? We are setting parameters that
> will be used by the CPU when it comes up out of reset, that's all.

It does actually allow you to set the boot ROM location, just FYI.

>
> So maybe we call this config_cpu ?
>
>> Not to mention there is documentation referencing the current commands
>> used by the evaluation platforms.
>
> Documentation should be updated when new software versions become
> available - that's a matter of fact.

Of course. And I suppose I'm wasting energy typing since you have 
already made up your mind on the subject but no harm in trying.

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

Re: [U-Boot] [PATCH] OneNAND IPL: Move u-boot-onenand linker script to common use

[Shinya Kuribayashi]

Scott Wood wrote:
> On Mon, Jul 13, 2009 at 09:48:30AM +0900, Kyungmin Park wrote:
>> Basically I agree your opinion, however do see the other arch OneNAND
>> usage? I mean I can't see the other arch patches.
> 
> There was nothing but powerpc in nand_spl at first, but I don't think ARM
> developers would have appreciated finding hardcoded powerpc assumptions
> when they tried to add their boards.

Heh, we're already using onenand_ipl on our MIPS machines ;-)

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

[U-Boot] [PATCH] Blackfin: bf537-{minotaur, srv1}: do not hardcode CONFIG_ETHADDR

[Mike Frysinger]

MAC addresses should not be hardcoded in boards to avoid random link level
conflicts.

Signed-off-by: Mike Frysinger 
---
 include/configs/bf537-minotaur.h |5 ++---
 include/configs/bf537-srv1.h |5 ++---
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/include/configs/bf537-minotaur.h b/include/configs/bf537-minotaur.h
index 23c2d33..463b7d0 100644
--- a/include/configs/bf537-minotaur.h
+++ b/include/configs/bf537-minotaur.h
@@ -87,9 +87,8 @@
 
 #define CONFIG_SYS_AUTOLOAD"no"
 #define CONFIG_ROOTPATH/romfs
-/* Use a fixed MAC address for booting up. Firstboot linux
- * must fetch a valid MAC from the production server. */
-#define CONFIG_ETHADDR 02:80:ad:20:31:42
+/* Uncomment next line to use fixed MAC address */
+/* #define CONFIG_ETHADDR  02:80:ad:20:31:42 */
 
 
 /*
diff --git a/include/configs/bf537-srv1.h b/include/configs/bf537-srv1.h
index 727b7e7..7368629 100644
--- a/include/configs/bf537-srv1.h
+++ b/include/configs/bf537-srv1.h
@@ -87,9 +87,8 @@
 
 #define CONFIG_SYS_AUTOLOAD"no"
 #define CONFIG_ROOTPATH/romfs
-/* Use a fixed MAC address for booting up. Firstboot linux
- * must fetch a valid MAC from the production server. */
-#define CONFIG_ETHADDR 02:80:ad:20:31:42
+/* Uncomment next line to use fixed MAC address */
+/* #define CONFIG_ETHADDR  02:80:ad:20:31:42 */
 
 
 /*
-- 
1.6.3.3

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

Re: [U-Boot] Initial environment variables

[Mike Frysinger]

On Thursday 16 July 2009 18:21:57 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > I'm do not understand why and I see in several include/configs/*.h
> > > files that these environment variable are being set as default.  I'm
> > > guessing that there's something that I'm missing.
> >
> > the board maintainer decides the default env values, not board users. 
> > Ben's comment was probably on the assumption that you are in the latter
> > category.
>
> That's only the first stage.
>
> After that, the custodian decides what is acceptable for mainline, and
> after that the project mainainer - ummm, that's me.
>
> And we do not accept any "default network configurations" in mainline.
>
> I'm really fed up by zillions of devices all coming up with the very
> same MAC address just because the board vendor (1) has no clue and (2)
> is too stingy to buy a block of MAC addresses.

we arent talking mac addresses here which i agree -- any default/hardcoding 
there is wrong
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Improve U-Boot Porting Guide in the README

[Brent Cook]

On Wednesday 15 July 2009 07:42:59 pm Jerry Van Baren wrote:
> Update for...
> * BDI2000 -> BDI3000 (BDI2000 is obsolete).
> * Add a line to read the doc/README.* files
> * Fix coding standard violations
>
> Signed-off-by: Gerald Van Baren 
> ---
> Dear Wolfgang,
>
> I was looking at the Porting Guide and realized it needed some updating.

This is hilarious, though I am curious what the real-world analog to 
'return 0;' is :)

 - Brent


> Thanks,
> gvb
>
>  README |   60 
>  1 files changed, 36 insertions(+), 24 deletions(-)
>
> diff --git a/README b/README
> index de700bd..ca415d3 100644
> --- a/README
> +++ b/README
> @@ -3992,15 +3992,15 @@ U-Boot Porting Guide:
>  list, October 2002]
>
>
> -int main (int argc, char *argv[])
> +int main(int argc, char *argv[])
>  {
>   sighandler_t no_more_time;
>
> - signal (SIGALRM, no_more_time);
> - alarm (PROJECT_DEADLINE - toSec (3 * WEEK));
> + signal(SIGALRM, no_more_time);
> + alarm(PROJECT_DEADLINE - toSec (3 * WEEK));
>
>   if (available_money > available_manpower) {
> - pay consultant to port U-Boot;
> + Pay consultant to port U-Boot;
>   return 0;
>   }
>
> @@ -4008,35 +4008,47 @@ int main (int argc, char *argv[])
>
>   Subscribe to u-boot mailing list;
>
> - if (clueless) {
> - email ("Hi, I am new to U-Boot, how do I get started?");
> - }
> + if (clueless)
> + email("Hi, I am new to U-Boot, how do I get started?");
>
>   while (learning) {
>   Read the README file in the top level directory;
> - Read http://www.denx.de/twiki/bin/view/DULG/Manual ;
> + Read http://www.denx.de/twiki/bin/view/DULG/Manual;
> + Read applicable doc/*.README;
>   Read the source, Luke;
> + /* find . -name "*.[chS]" | xargs grep -i  */
>   }
>
> - if (available_money > toLocalCurrency ($2500)) {
> - Buy a BDI2000;
> - } else {
> + if (available_money > toLocalCurrency ($2500))
> + Buy a BDI3000;
> + else
>   Add a lot of aggravation and time;
> - }
> -
> - Create your own board support subdirectory;
>
> - Create your own board config file;
> -
> - while (!running) {
> - do {
> - Add / modify source code;
> - } until (compiles);
> - Debug;
> - if (clueless)
> - email ("Hi, I am having problems...");
> + if (a similar board exists) {   /* hopefully... */
> + cp -a board/ board/
> + cp include/configs/.h include/configs/.h
> + } else {
> + Create your own board support subdirectory;
> + Create your own board include/configs/.h file;
> + }
> + Edit new board/ files
> + Edit new include/configs/.h
> +
> + while (!accepted) {
> + while (!running) {
> + do {
> + Add / modify source code;
> + } until (compiles);
> + Debug;
> + if (clueless)
> + email("Hi, I am having problems...");
> + }
> + Send patch file to the U-Boot email list;
> + if (reasonable critiques)
> + Incorporate improvements from email list code review;
> + else
> + Defend code as written;
>   }
> - Send patch file to Wolfgang;
>
>   return 0;
>  }

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

Re: [U-Boot] PATCH 2/2] Add pci/pcie E1000 ethernet support for MPC8544DS and MPC8536 boards

[Wolfgang Denk]

Dear Ben Warren,

In message <4a5f9a05.70...@gmail.com> you wrote:
>
> >>   From: Roy Zang 
> >>Add pci/pcie E1000 ethernet support for MPC8544DS and MPC8536 boards.
> >>Signed-off-by: Roy Zang 
> >
> > Doesn't apply with git-am. Please use git-format-patch to create
> > patches.
...
> Still undergoing review (sorry it's taking so long).  Please don't apply 
> yet.

I did not intend to meddle with your business. Just wanted to point
out formal deficiencies of the patch.

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: w...@denx.de
The existence of god implies a violation of causality.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Initial environment variables

[Wolfgang Denk]

Dear Ron Madrid,

In message <401734.38482...@web83507.mail.sp1.yahoo.com> you wrote:
> 
> > the board maintainer decides the default env values, not
> > board users.  Ben's 
> > comment was probably on the assumption that you are in the
> > latter category.
> 
> Ah, that could be why.  Thankfully I am the maintainer for the board.  So I
> am going to assume then that it would be OK for me to add these variable
> settings to my board's include/configs file and submit a patch for it,
> unless I here other objections.

We do not accept any "default network configurations"  in  the  board
configuration.  It  makes  no  sense when all boards come up with the
very same network setting - it only causes problems and frustration.

[Don't tell me about "useful" use cases - all thse can be done in
different ways, easier.]

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: w...@denx.de
It's all Klatchian to me.
- Terry Pratchett & Stephen Briggs, _The Discworld Companion_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Initial environment variables

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200907161656.44300.vap...@gentoo.org> you wrote:
>
> > I'm do not understand why and I see in several include/configs/*.h files
> > that these environment variable are being set as default.  I'm guessing
> > that there's something that I'm missing.
>
> the board maintainer decides the default env values, not board users.  Ben's 
> comment was probably on the assumption that you are in the latter category.

That's only the first stage.

After that, the custodian decides what is acceptable for mainline, and
after that the project mainainer - ummm, that's me.

And we do not accept any "default network configurations" in mainline.

I'm really fed up by zillions of devices all coming up with the very
same MAC address just because the board vendor (1) has no clue and (2)
is too stingy to buy a block of MAC addresses.

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: w...@denx.de
I know engineers. They love to change things. - Dr. McCoy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add bootstrap command

[Wolfgang Denk]

Dear Matthias Fuchs,

In message <200907162224.23377.matthias.fu...@esd-electronics.com> you wrote:
>
> > Please find a better description (avoiding "bootstrap"), and then
> > chose a descriptive name.
> ccc - config chip|cpu configuration
> scc - setup chip|cpu configuration
> wcc - write chip|cpu configuration
> wcce - write chip|cpu configuration eeprom

Which of these will you still remember after the third glass of beer?
;-)

> I am not a friend of long names :-)

Neiter am I. But there  are  some  basic  rules  for  user  interface
design. Short commands should only be used for "harmless" operations.
Long  names  are OK for critical actions where you better should have
your brain  online  and  not  only  your  fingers  continue  to  type
something  after  the  brain  detached. And short commands should bne
used  for  frequently  used  commands,  while  long,  self-explaining
commands are OK for more exotic operations.

This _is_ a thing that requires attention, and you do not need it
frequently - I guess if you run statistics about command usage it will
be in the bottom 5% -  agreed?

So a long name is perfect.

Something  like  "config_cpu"  or  "set_cpu_config"  etc.  (and   the
underscore  is intentional to make you think twice what you are doing
here).

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: w...@denx.de
I'm what passes for a Unix guru in my office. This is  a  frightening
concept. - Lee Ann Goldstein, in <3k55ba$...@butch.lmsc.lockheed.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add bootstrap command

[Wolfgang Denk]

Dear Dave Mitchell,

In message <4a5f8a1d.4030...@gmail.com> you wrote:
>
> > Please find a better description (avoiding "bootstrap"), and then
> > chose a descriptive name.
> 
> Keep in mind the processor UM documentation section that covers these 
> boot methods is labeled "Bootstrap Operations". It refers the registers 
> that the EEPROM values populate as "bootstrap registers", etc.

Yes, I know. But then, bootstrapping [1] is  really  a  name  with  a
_very_ fuzzy meaning. It can be anything. The fact thay it was chosen
in  the  UM documentation does't make it better - in U-Boot context I
think about other activities, and in Linux context  yet  about  other
things.

> There is some logic in tying the section of the processor manual to the 
> command. Whatever the command ends up being labeled, it would be nice if 
> its purpose was clear to those who actually work in 4xx space.

We are changing the CPU configuration, right? It has nothing to do
with actually booting or bootstrapping? We are setting parameters that
will be used by the CPU when it comes up out of reset, that's all.

So maybe we call this config_cpu ?

> Not to mention there is documentation referencing the current commands 
> used by the evaluation platforms.

Documentation should be updated when new software versions become
available - that's a matter of fact.


[1] http://en.wikipedia.org/wiki/Bootstrap

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: w...@denx.de
It is impractical for  the  standard  to  attempt  to  constrain  the
behavior  of code that does not obey the constraints of the standard.
  - Doug Gwyn
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add bootstrap command

[Wolfgang Denk]

Dear Matthias Fuchs,

In message <200907162208.28398.matthias.fu...@esd-electronics.com> you wrote:
>
> > But unfortunately not specific enough for a "common" command.
> I think we are talking about a generic 4xx command to write data into
> the EEPROM that is read by the bootstrap controller. But I do not care about 
> the name ;-)

We're changing some board configuration data. Maybe the command name
should start with "conf[ig]" then.

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: w...@denx.de
All this doesn't alter anything, you know. The world is still full of
stupid people. They don't use their brains. They don't seem  to  want
to think straight.- Terry Pratchett, _Soul Music_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Typo fix: use CONFIG_SOC_DM644X, not CONFIG_SOC_DM646.

[Wolfgang Denk]

Dear Scott Wood,

In message <20090716194726.gf32...@b07421-ec1.am.freescale.net> you wrote:
>
> Applied to u-boot-nand-flash.
> 
> Wolfgang, I used "Typo fix: use CONFIG_SOC_DM644X, not CONFIG_SOC_DM646."
> as the first line of the commit message, which differs from the "Pull
> request: nand flash" subject of the outer message that will show up on
> the archive list.  Do you want me to resend the patch to the list as an
> e-mail with that subject (and if I do, can I then fix the "DM646" typo
> and clarify which code the fix is for?), or is the updated subject line
> in this e-mail enough?

That's enough. Thanks a lot for the heads-up.


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: w...@denx.de
This all sounds complicated, but it mostly does excatly what you  ex-
pect. It's just difficult for us to explain what you expect...
   - L. Wall & R. L. Schwartz, _Programming Perl_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Initial environment variables

[Mike Frysinger]

On Thursday 16 July 2009 17:08:55 Ben Warren wrote:
> Ron Madrid wrote:
> > --- On Thu, 7/16/09, Mike Frysinger  wrote:
> >> the board maintainer decides the default env values, not
> >> board users.  Ben's
> >> comment was probably on the assumption that you are in the
> >> latter category.
> >
> > Ah, that could be why.  Thankfully I am the maintainer for the board.  So
> > I am going to assume then that it would be OK for me to add these
> > variable settings to my board's include/configs file and submit a patch
> > for it, unless I here other objections.
>
> No, there should be no default net parameters, because you're making
> likely-bogus assumptions about the network that your board's going to go
> into.  Just because your LAN uses '192.168.0.x' doesn't mean anybody
> else's does.

i dont see why this is a problem.  providing a consistent default network 
setup doesnt cause any problems whatsoever.  if you have a different network 
layout, then it's trivial to (1) change it or (2) type "dhcp".

this is the first ive heard against letting board maintainers dictate default 
network settings.  i do it for all ADI Blackfin boards and never once have i 
heard a complaint from people who use them.

> It's even worse for MAC addresses - what if I buy two of
> your boards and plug them into the same switch?  If the addresses are
> identical all sorts of bad things can happen.  Not to mention that
> public MAC addresses are assigned (and paid for) and should be
> guaranteed to be unique.  And private (bit 41 set) addresses are used in
> many different ways.  One systems company that I worked at would program
> these dynamically based on which shelf/slot the board was plugged into.
> It's best to fail loudly (a printf stating that MAC addresses haven't
> been programmed) than to silently cause network issues.

MAC addresses are a completely different issue than IP settings.  i agree that 
there should never be a default environment value in any board in the tree.  a 
quick grep of the tree indicates that people have been very bad in this area 
(and i see that i merged two such Blackfin boards).  i'll send patches for the 
two boards i watch over.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Initial environment variables

[Ben Warren]

ron_mad...@sbcglobal.net wrote:
> --- On Thu, 7/16/09, Ben Warren  wrote:
>
>   
>> From: Ben Warren 
>> Subject: Re: [U-Boot] Initial environment variables
>> To: "Ron Madrid" 
>> Cc: u-boot@lists.denx.de, "Mike Frysinger" 
>> Date: Thursday, July 16, 2009, 2:08 PM
>> Ron Madrid wrote:
>> 
>>> --- On Thu, 7/16/09, Mike Frysinger 
>>>   
>> wrote:
>> 
>>>   
>>>   
 the board maintainer decides the default env
 
>> values, not
>> 
 board users.  Ben's comment was probably on
 
>> the assumption that you are in the
>> 
 latter category.
 
 
>>> Ah, that could be why.  Thankfully I am the
>>>   
>> maintainer for the board.  So I
>> 
>>> am going to assume then that it would be OK for me to
>>>   
>> add these variable
>> 
>>> settings to my board's include/configs file and submit
>>>   
>> a patch for it,
>> 
>>> unless I here other objections.
>>>
>>> Ron
>>>   
>>>   
>> No, there should be no default net parameters, because
>> you're making likely-bogus assumptions about the network
>> that your board's going to go into.  Just because your
>> LAN uses '192.168.0.x' doesn't mean anybody else's
>> does.  It's even worse for MAC addresses - what if I
>> buy two of your boards and plug them into the same
>> switch?  If the addresses are identical all sorts of
>> bad things can happen.  Not to mention that public MAC
>> addresses are assigned (and paid for) and should be
>> guaranteed to be unique.  And private (bit 41 set)
>> addresses are used in many different ways.  One systems
>> company that I worked at would program these dynamically
>> based on which shelf/slot the board was plugged into. 
>> It's best to fail loudly (a printf stating that MAC
>> addresses haven't been programmed) than to silently cause
>> network issues.  I could go on and on, but hopefully
>> you get the point.
>> 
>
> I do understand your points.  I am confused then as to why there are
> around 100 different board configurations that include these variables.
>
> Ron
>
>   
Sorry, before my time :)  They should be cleaned up.

regards,
Ben

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

Re: [U-Boot] Initial environment variables

[ron_madrid]

--- On Thu, 7/16/09, Ben Warren  wrote:

> From: Ben Warren 
> Subject: Re: [U-Boot] Initial environment variables
> To: "Ron Madrid" 
> Cc: u-boot@lists.denx.de, "Mike Frysinger" 
> Date: Thursday, July 16, 2009, 2:08 PM
> Ron Madrid wrote:
> > --- On Thu, 7/16/09, Mike Frysinger 
> wrote:
> > 
> >   
> >> the board maintainer decides the default env
> values, not
> >> board users.  Ben's comment was probably on
> the assumption that you are in the
> >> latter category.
> >> 
> > 
> > Ah, that could be why.  Thankfully I am the
> maintainer for the board.  So I
> > am going to assume then that it would be OK for me to
> add these variable
> > settings to my board's include/configs file and submit
> a patch for it,
> > unless I here other objections.
> > 
> > Ron
> >   
> No, there should be no default net parameters, because
> you're making likely-bogus assumptions about the network
> that your board's going to go into.  Just because your
> LAN uses '192.168.0.x' doesn't mean anybody else's
> does.  It's even worse for MAC addresses - what if I
> buy two of your boards and plug them into the same
> switch?  If the addresses are identical all sorts of
> bad things can happen.  Not to mention that public MAC
> addresses are assigned (and paid for) and should be
> guaranteed to be unique.  And private (bit 41 set)
> addresses are used in many different ways.  One systems
> company that I worked at would program these dynamically
> based on which shelf/slot the board was plugged into. 
> It's best to fail loudly (a printf stating that MAC
> addresses haven't been programmed) than to silently cause
> network issues.  I could go on and on, but hopefully
> you get the point.

I do understand your points.  I am confused then as to why there are
around 100 different board configurations that include these variables.

Ron

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

Re: [U-Boot] PATCH 2/2] Add pci/pcie E1000 ethernet support for MPC8544DS and MPC8536 boards

[Ben Warren]

Wolfgang Denk wrote:
> Dear Roy Zang,
>
> In message <1247105148.29920.3.ca...@rock.ap.freescale.net> you wrote:
>   
>> Sorry for the mistake. It is my oversight when I regenerate the patch
>> before send out. 
>> Pick up this one:
>>
>>   From: Roy Zang 
>>Add pci/pcie E1000 ethernet support for MPC8544DS and MPC8536 boards.
>>Signed-off-by: Roy Zang 
>> 
>
> Doesn't apply with git-am. Please use git-format-patch to create
> patches.
>
> Best regards,
>
> Wolfgang Denk
>
>   
Still undergoing review (sorry it's taking so long).  Please don't apply 
yet.

regards,
Ben

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

Re: [U-Boot] PATCH 2/2] Add pci/pcie E1000 ethernet support for MPC8544DS and MPC8536 boards

[Wolfgang Denk]

Dear Roy Zang,

In message <1247105148.29920.3.ca...@rock.ap.freescale.net> you wrote:
>
> Sorry for the mistake. It is my oversight when I regenerate the patch
> before send out. 
> Pick up this one:
>
>   From: Roy Zang 
>Add pci/pcie E1000 ethernet support for MPC8544DS and MPC8536 boards.
>Signed-off-by: Roy Zang 

Doesn't apply with git-am. Please use git-format-patch to create
patches.

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: w...@denx.de
The human race has one really effective weapon, and that is laughter.
 - Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Refresh LZMA-lib to 4.65

[Wolfgang Denk]

Dear rhabarber1848,

In message  you wrote:
> 
> it seems I solved the problem.

Hm...

> The end value for the kernel was too high, the attached patch[1] should fix
> it, a LZMA-compressed kernel booted well. I did not test the bz2 case but
> it seems it suffers from the same bug.

Maybe lzmaBuffToBuffDecompress() stores an incorrect value in unc_len?

> diff -uNr u-boot-2009.06.org/common/cmd_bootm.c 
> u-boot-2009.06/common/cmd_bootm.c
> --- u-boot-2009.06.org/common/cmd_bootm.c 2009-06-14 21:30:39.0 
> +0200
> +++ u-boot-2009.06/common/cmd_bootm.c 2009-07-15 18:28:28.0 +0200
> @@ -380,7 +380,7 @@
>   return BOOTM_ERR_RESET;
>   }
>  
> - *load_end = load + unc_len;
> + *load_end = load + image_len;
>   break;
>  #endif /* CONFIG_BZIP2 */
>  #ifdef CONFIG_LZMA
> @@ -396,7 +396,7 @@
>   show_boot_progress (-6);
>   return BOOTM_ERR_RESET;
>   }
> - *load_end = load + unc_len;
> + *load_end = load + image_len;

This seems definitely wrong to me. image_len is the length of the
_compressed_ image, which is not what we need here.

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: w...@denx.de
"Wish not to seem, but to be, the best."  - Aeschylus
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Initial environment variables

[Ben Warren]

Ron Madrid wrote:
> --- On Thu, 7/16/09, Mike Frysinger  wrote:
>
>   
>> the board maintainer decides the default env values, not
>> board users.  Ben's 
>> comment was probably on the assumption that you are in the
>> latter category.
>> 
>
> Ah, that could be why.  Thankfully I am the maintainer for the board.  So I
> am going to assume then that it would be OK for me to add these variable
> settings to my board's include/configs file and submit a patch for it,
> unless I here other objections.
>
> Ron
>   
No, there should be no default net parameters, because you're making 
likely-bogus assumptions about the network that your board's going to go 
into.  Just because your LAN uses '192.168.0.x' doesn't mean anybody 
else's does.  It's even worse for MAC addresses - what if I buy two of 
your boards and plug them into the same switch?  If the addresses are 
identical all sorts of bad things can happen.  Not to mention that 
public MAC addresses are assigned (and paid for) and should be 
guaranteed to be unique.  And private (bit 41 set) addresses are used in 
many different ways.  One systems company that I worked at would program 
these dynamically based on which shelf/slot the board was plugged into.  
It's best to fail loudly (a printf stating that MAC addresses haven't 
been programmed) than to silently cause network issues.  I could go on 
and on, but hopefully you get the point.

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

Re: [U-Boot] [PATCH 1/3] arm: Added support for MB86R01 'Jade' SoC

[Wolfgang Denk]

Dear Matthias Weisser,

In message <1247039227-17910-2-git-send-email-matthias.weis...@graf-syteco.de> 
you wrote:
> This patch adds support for MB86R01 'Jade' SoC from Fujitsu
...
> +/* nothing really to do with interrupts, just starts up a counter. */
> +int timer_init(void)
> +{
> + *(volatile ulong *)(TIMER_BASE + 0) = TIMER_LOAD_VAL;
> + *(volatile ulong *)(TIMER_BASE + 8) = 0x86;

Here and everyhere else: please use accessor functions instead of
(volatile) register assignments.

> +unsigned long long get_ticks(void)
> +{
> + ulong now = READ_TIMER;
> +
> + if (now <= lastdec) /* normal mode (non roll) */
> + /* move stamp forward with absolut diff ticks */
> + timestamp += (lastdec - now);
> + else/* we have rollover of incrementer */

Please add braces for multiline branches.

> +void udelay(unsigned long usec)
> +{
> + unsigned long long tmp;
> + ulong tmo;
> +
> + tmo = usec_to_tick(usec);
> + tmp = get_ticks() + tmo;/* get current timestamp */
> +
> + while (get_ticks() < tmp)   /* loop till event */
> + /*NOP*/;

What about the timestamp wrapping around?

> +ulong get_tbclk(void)
> +{
> + ulong tbclk;
> +
> + tbclk = CONFIG_SYS_HZ;
> + return tbclk;
> +}

Why not simply "return CONFIG_SYS_HZ;" ?

> diff --git a/include/asm-arm/arch-jade/jade.h 
> b/include/asm-arm/arch-jade/jade.h
> new file mode 100755
> index 000..c2b28a2
> --- /dev/null
> +++ b/include/asm-arm/arch-jade/jade.h
...
> +#ifndef JADE_H
> +#define JADE_H
> +
> +typedef  volatile unsigned int   JREG;   /* Hardware register definition 
> */

This is not needed / allowed/ Please use accessor functions.

> +/*
> + * Physical Address Defines
> + */
> +#define JADE_GDC_PHYS_BASE   0xf1fc  /* GDC phys */
> +#define JADE_GDC_PHYS_DISP_BASE  0xf1fd  /* GDC 
> DisplayBase phys */
> +#define JADE_CCNT_PHYS_BASE  0xfff42000  /* Chip Control Module 
> */
> +#define JADE_CAN0_PHYS_BASE  0xfff54000  /* CAN 0 phys */
> +#define JADE_CAN1_PHYS_BASE  0xfff55000  /* CAN 1 phys */
> +#define JADE_I2C0_PHYS_BASE  0xfff56000  /* I2C 0 phys */
> +#define JADE_I2C1_PHYS_BASE  0xfff57000  /* I2C 1 phys */
> +#define JADE_EHCI_PHYS_BASE  0xfff8  /* EHCI phys */
> +#define JADE_OHCI_PHYS_BASE  0xfff81000  /* OHCI phys */
> +#define JADE_IRC1_PHYS_BASE  0xfffb  /* Jade cascaded 
> Interrupt Controller phys */

Line too long (many more too long lines, please check globally).

> +#define JADE_TIMER_PHYS_BASE 0xfffe  /* Counter/Timers JADE 
> phys */
> +#define JADE_UART0_PHYS_BASE 0xfffe1000  /* UART 0 phys */
> +#define JADE_UART1_PHYS_BASE 0xfffe2000  /* UART 1 phys */
> +#define JADE_IRCE_PHYS_BASE  0xfffe4000  /* Extended Interrupt 
> Controller */
> +#define JADE_CRG_PHYS_BASE   0xfffe7000  /* Clock Reset 
> Generator */
> +#define JADE_IRC0_PHYS_BASE  0xfffe8000  /* Jade Interrupt 
> Controller phys */
> +#define JADE_GPIO_PHYS_BASE  0xfffe9000  /* GPIO phys */

Please do not use register addresses directly - declare a C structure,
and use typed variables. This applies not only here, but globally.


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: w...@denx.de
God grant me the senility to accept the things I cannot  change,  The
frustration  to  try to change things I cannot affect, and the wisdom
to tell the difference.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/8] hwconfig and some its users

[Anton Vorontsov]

On Thu, Jul 16, 2009 at 10:52:13PM +0200, Wolfgang Denk wrote:
> Dear Kim Phillips,
> 
> In message <20090707173804.acc352f9.kim.phill...@freescale.com> you wrote:
> >
> > > Any news on this?
> > 
> > Wolfgang, if you have no objection, please apply directly.
> 
> Done.

Thanks a lot, Wolfgang!

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
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] Initial environment variables

[Ron Madrid]

--- On Thu, 7/16/09, Mike Frysinger  wrote:

> the board maintainer decides the default env values, not
> board users.  Ben's 
> comment was probably on the assumption that you are in the
> latter category.

Ah, that could be why.  Thankfully I am the maintainer for the board.  So I
am going to assume then that it would be OK for me to add these variable
settings to my board's include/configs file and submit a patch for it,
unless I here other objections.

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

Re: [U-Boot] [PATCH 2/3] minor fixes for mvBC-P (MPC5200)

[Wolfgang Denk]

Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,

In message <1245678505.3867.13.ca...@swa-m460> you wrote:
> 
> Content-Disposition: attachment; 
> filename="0001-rebased-mvBC-P-with-minor-fixes.patch"
> Content-Type: text/x-patch; 
> name="0001-rebased-mvBC-P-with-minor-fixes.patch"; charset="UTF-8"
> Content-Transfer-Encoding: 7bit

Please send your patches inline, NOT as attachments!

> rebase and make use of common code.
> add i2c and configurable pci latency.

This should be split. The "use common code" should go into the "factor
out" patch to make it an atomic operation. 

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: w...@denx.de
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Initial environment variables

[Mike Frysinger]

On Thursday 16 July 2009 16:46:36 Ron Madrid wrote:
> > Ron Madrid wrote:
> > > When I submitted patches for my new board SIMPC8313 I
> > > recall being told that I had inappropriately initialized some of my
> > > environment variables.  Most specifically I am interested in having
> > > default serverip, ipaddr, and ethaddr environment variables.  Is this
> > > most appropriately done with a specific
> > > #define (such as #define CONFIG_SERVERIP) or within #define
> > > CONFIG_EXTRA_ENV_SETTINGS?
> >
> > You can set CONFIGs for all of these things in your own
> > private build and they'll work, but they're inappropriate for main-line
> > U-boot.  I hope the reasoning is obvious.
>
> I'm do not understand why and I see in several include/configs/*.h files
> that these environment variable are being set as default.  I'm guessing
> that there's something that I'm missing.

the board maintainer decides the default env values, not board users.  Ben's 
comment was probably on the assumption that you are in the latter category.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] factor out common code for matrix vision boards

[Wolfgang Denk]

Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,

In message <1245678391.3867.11.ca...@swa-m460> you wrote:
> 
> factor out common code for Matrix Vision based boards.
> 
> Signed-off-by: Andre Schwarz 
> ---
>  board/matrix_vision/common/Makefile|   54 ++
>  board/matrix_vision/common/mv_common.c |  125 
> 
>  board/matrix_vision/common/mv_common.h |   25 +++
>  3 files changed, 204 insertions(+), 0 deletions(-)
>  create mode 100644 board/matrix_vision/common/Makefile
>  create mode 100644 board/matrix_vision/common/mv_common.c
>  create mode 100644 board/matrix_vision/common/mv_common.h

Hm... to me factor out means removing the same part of code form
several places and adding a unique copy of it somewhere. But I see
only added code, none removed?

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: w...@denx.de
"In matters of principle, stand like a rock;  in  matters  of  taste,
swim with the current."- Thomas Jefferson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/8] hwconfig and some its users

[Wolfgang Denk]

Dear Kim Phillips,

In message <20090707173804.acc352f9.kim.phill...@freescale.com> you wrote:
>
> > Any news on this?
> 
> Wolfgang, if you have no objection, please apply directly.

Done.

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: w...@denx.de
Genius doesn't work on an assembly line basis.  You can't simply say,
"Today I will be brilliant."
-- Kirk, "The Ultimate Computer", stardate 4731.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 8/8] mpc83xx: MPC837xEMDS: Use hwconfig instead of pci_external_arbiter variable

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090609202538.gh20...@oksana.dev.rtsoft.ru> you wrote:
> Since we have simple hwconfig interface now, we don't need
> pci_external_arbiter variable any longer.
> 
> Signed-off-by: Anton Vorontsov 
> ---
>  board/freescale/mpc837xemds/mpc837xemds.c |3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)

Applied, thanks.

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: w...@denx.de
If there are self-made purgatories, then we all have to live in them.
-- Spock, "This Side of Paradise", stardate 3417.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/8] mpc83xx: MPC8315ERDB: Use hwconfig for board type selection

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090609202536.gg20...@oksana.dev.rtsoft.ru> you wrote:
> This patch simply converts the board to the hwconfig infrastructure.
> 
> Signed-off-by: Anton Vorontsov 
> ---
>  board/freescale/mpc8315erdb/mpc8315erdb.c |   14 +-
>  include/configs/MPC8315ERDB.h |1 +
>  2 files changed, 6 insertions(+), 9 deletions(-)

Applied, thanks.

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: w...@denx.de
"Data is a lot like humans: It is  born.  Matures.  Gets  married  to
other  data, divorced. Gets old. One thing that it doesn't do is die.
It has to be killed." - Arthur Miller
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/8] fsl_dr_usb: Fixup disabled USB controllers nodes in device tree

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090609202534.gf20...@oksana.dev.rtsoft.ru> you wrote:
> We should add status = "disabled" property when USB controller can't
> be used (for example when USB pins muxed away to another device).
> 
> Also convert whole fdt_fixup_dr_usb() to use more compact routines
> from fdt_support.h.
> 
> Signed-off-by: Anton Vorontsov 
> ---
>  cpu/mpc83xx/cpu.c|4 +++
>  drivers/usb/otg/fsl_dr_usb.c |   60 -
>  2 files changed, 39 insertions(+), 25 deletions(-)

[Oops, please ignore previous reply to wrong patch submission.]

Does not apply:

Applying: fsl_dr_usb: Fixup disabled USB controllers nodes in device tree
error: drivers/usb/otg/fsl_dr_usb.c: does not exist in index
fatal: sha1 information is lacking or useless
(drivers/usb/otg/fsl_dr_usb.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0006.

Please rebase and resubmit.

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: w...@denx.de
Punishment becomes ineffective after a certain point. Men become  in-
sensitive.
-- Eneg, "Patterns of Force", stardate 2534.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Initial environment variables

[Ron Madrid]

> Ron Madrid wrote:
> > When I submitted patches for my new board SIMPC8313 I
> recall being told that
> > I had inappropriately initialized some of my
> environment variables.  Most
> > specifically I am interested in having default
> serverip, ipaddr, and ethaddr
> > environment variables.  Is this most
> appropriately done with a specific
> > #define (such as #define CONFIG_SERVERIP) or within
> #define
> > CONFIG_EXTRA_ENV_SETTINGS?
> >
> >   
> You can set CONFIGs for all of these things in your own
> private build 
> and they'll work, but they're inappropriate for main-line
> U-boot.  I 
> hope the reasoning is obvious.

I'm do not understand why and I see in several include/configs/*.h files that 
these environment variable are being set as default.  I'm guessing that there's 
something that I'm missing.

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

Re: [U-Boot] [PATCH 5/8] fdt_support, usb: Move fdt_fixup_dr_usb routine to drivers/usb/otg

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090609202532.ge20...@oksana.dev.rtsoft.ru> you wrote:
> In subsequent patches we'll use FSL-specific functions in
> fdt_fixup_dr_usb(), so let's move the routine to a more appropriate
> place.
> 
> So far fsl_dr_usb.c isn't actually an USB driver, but eventually it
> will turn into one, let's hope. ;-)
> 
> Also rename CONFIG_HAS_FSL_DR_USB to CONFIG_USB_FSL_DR to be
> consistent with other USB drivers.
> 
> Signed-off-by: Anton Vorontsov 
> ---
>  Makefile  |1 +
>  board/freescale/mpc8315erdb/mpc8315erdb.c |1 +
>  board/freescale/mpc837xemds/mpc837xemds.c |1 +
>  board/freescale/mpc837xerdb/mpc837xerdb.c |1 +
>  common/fdt_support.c  |   41 --
>  drivers/usb/otg/Makefile  |   46 +
>  drivers/usb/otg/fsl_dr_usb.c  |   52 
> +
>  include/configs/MPC8315ERDB.h |2 +-
>  include/configs/MPC837XEMDS.h |2 +-
>  include/configs/MPC837XERDB.h |2 +-
>  include/fdt_support.h |6 ---
>  include/fsl_dr_usb.h  |   21 +++
>  12 files changed, 126 insertions(+), 50 deletions(-)
>  create mode 100644 drivers/usb/otg/Makefile
>  create mode 100644 drivers/usb/otg/fsl_dr_usb.c
>  create mode 100644 include/fsl_dr_usb.h

Sorry, doesn't apply:

Applying: fsl_dr_usb: Fixup disabled USB controllers nodes in device tree
error: drivers/usb/otg/fsl_dr_usb.c: does not exist in index
fatal: sha1 information is lacking or useless
(drivers/usb/otg/fsl_dr_usb.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0006.

Please rebase and resubmit.

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: w...@denx.de
"The two most common things in the universe are hydrogen  and  stupi-
dity."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/8] fdt_support, usb: Move fdt_fixup_dr_usb routine to drivers/usb/otg

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090609202532.ge20...@oksana.dev.rtsoft.ru> you wrote:
> In subsequent patches we'll use FSL-specific functions in
> fdt_fixup_dr_usb(), so let's move the routine to a more appropriate
> place.
> 
> So far fsl_dr_usb.c isn't actually an USB driver, but eventually it
> will turn into one, let's hope. ;-)
> 
> Also rename CONFIG_HAS_FSL_DR_USB to CONFIG_USB_FSL_DR to be
> consistent with other USB drivers.
> 
> Signed-off-by: Anton Vorontsov 
> ---
>  Makefile  |1 +
>  board/freescale/mpc8315erdb/mpc8315erdb.c |1 +
>  board/freescale/mpc837xemds/mpc837xemds.c |1 +
>  board/freescale/mpc837xerdb/mpc837xerdb.c |1 +
>  common/fdt_support.c  |   41 --
>  drivers/usb/otg/Makefile  |   46 +
>  drivers/usb/otg/fsl_dr_usb.c  |   52 
> +
>  include/configs/MPC8315ERDB.h |2 +-
>  include/configs/MPC837XEMDS.h |2 +-
>  include/configs/MPC837XERDB.h |2 +-
>  include/fdt_support.h |6 ---
>  include/fsl_dr_usb.h  |   21 +++
>  12 files changed, 126 insertions(+), 50 deletions(-)
>  create mode 100644 drivers/usb/otg/Makefile
>  create mode 100644 drivers/usb/otg/fsl_dr_usb.c
>  create mode 100644 include/fsl_dr_usb.h

Sorry, this patch doesn't apply:

Applying: fdt_support, usb: Move fdt_fixup_dr_usb routine to drivers/usb/otg
error: patch failed: common/fdt_support.c:454
error: common/fdt_support.c: patch does not apply
error: patch failed: include/configs/MPC8315ERDB.h:344
error: include/configs/MPC8315ERDB.h: patch does not apply
error: patch failed: include/fdt_support.h:53
error: include/fdt_support.h: patch does not apply
fatal: sha1 information is lacking or useless 
(board/freescale/mpc837xemds/mpc837xemds.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0005.

Please rebase and resubmit.

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: w...@denx.de
If it has syntax, it isn't user friendly.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/7] nand: Change NAND_MAX_OOBSIZE to 218 as needed for some 4k page devices

[Scott Wood]

On Thu, Jun 04, 2009 at 04:40:36PM +0200, Stefan Roese wrote:
> This is needed for the MPC512x NAND driver (fsl_nfc_nand.c) which already
> defines such a 4k plus 218 bytes ECC layout.
> 
> Signed-off-by: Stefan Roese 
> Cc: Scott Wood 
> ---

Applied to u-boot-nand-flash.  Sorry for the delay, it got lost in a pile
of old e-mail.

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

Re: [U-Boot] [PATCH 4/8] mpc83xx: MPC837XEMDS: Fixup eSDHC nodes in device tree

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090609202531.gd20...@oksana.dev.rtsoft.ru> you wrote:
> fdt_fixup_esdhc() will either disable or enable eSDHC nodes, and
> also will fixup clock-frequency property.
> 
> Plus, since DR USB and eSDHC are mutually exclusive, we should
> only configure the eSDHC if asked through hwconfig.
> 
> Signed-off-by: Anton Vorontsov 
> ---
>  board/freescale/mpc837xemds/mpc837xemds.c |   37 ++--
>  include/configs/MPC837XEMDS.h |1 +
>  2 files changed, 25 insertions(+), 13 deletions(-)

Applied, thanks.

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: w...@denx.de
In the bathtub of history the truth is harder to hold than the  soap,
and much more difficult to find ... - Terry Pratchett, _Sourcery_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/8] mpc83xx: MPC837XERDB: Add support for FSL eSDHC

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090609202530.gc20...@oksana.dev.rtsoft.ru> you wrote:
> This patch adds support for eSDHC on MPC837XERDB boards. The WP
> switch doesn't seem to work on RDB boards though, the WP pin is
> always asserted (can see the pin state when it's in GPIO mode).
> 
> FSL DR USB and FSL eSDHC are mutually exclusive because of pins
> multiplexing, so user should specify 'esdhc' or 'dr_usb' options
> in the hwconfig environment variable to choose between the
> devices.
> 
> p.s.
> Now we're very close to a monitor len limit (196 bytes left using
> gcc-4.2.0), so also increase the monitor len by one sector (64 KB).
> 
> Signed-off-by: Anton Vorontsov 
> ---
>  board/freescale/mpc837xerdb/mpc837xerdb.c |   18 ++
>  include/configs/MPC837XERDB.h |   18 +-
>  2 files changed, 35 insertions(+), 1 deletions(-)

Applied, thanks.

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: w...@denx.de
"I didn't know it was impossible when I did it."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/8] fsl_esdhc: Add device tree fixups

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090609202529.gb20...@oksana.dev.rtsoft.ru> you wrote:
> This patch implements fdt_fixup_esdhc() function that is used to fixup
> the device tree.
> 
> The function adds status = "disabled" propery if esdhc pins muxed away,
> otherwise it fixups clock-frequency for esdhc nodes.
> 
> Signed-off-by: Anton Vorontsov 
> ---
>  drivers/mmc/fsl_esdhc.c |   19 +++
>  include/fsl_esdhc.h |8 
>  2 files changed, 27 insertions(+), 0 deletions(-)

Applied, thanks.

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: w...@denx.de
When dreams become more important than reality, you give  up  travel,
building,  creating;  you even forget how to repair the machines left
behind by your ancestors. You just  sit  living  and  reliving  other
lives left behind in the thought records.
-- Vina, "The Menagerie" ("The Cage"), stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/8] Add simple hwconfig infrastructure

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090609202527.ga20...@oksana.dev.rtsoft.ru> you wrote:
> This patch implements simple hwconfig infrastructure: an
> interface for software knobs to control a hardware.
> 
> This is very simple implementation, i.e. it is implemented
> via `hwconfig' environment variable. Later we could write
> some "hwconfig " commands, ncurses
> interface for Award BIOS-like interface, and frame-buffer
> interface for AMI GUI[1] BIOS-like interface with mouse
> support[2].
> 
> Current implementation details/limitations:
> 
> 1. Doesn't support options dependencies and mutual exclusion.
>We can implement this by integrating apt-get[3] into the
>u-boot. But I didn't bother yet.
> 
> 2. Since we don't implement hwconfig command, i.e. we're working
>with the environement directly, there is no way to tell that
>toggling a particular option will need a reboot to take
>an effect. So, for now it's advised to always reboot the
>target after modifying hwconfig variable.
> 
> 3. We support hwconfig options with arguments. For example,
> 
>set hwconfig dr_usb:mode=peripheral,phy_type=ulpi
> 
>That means:
>- dr_usb - enable Dual-Role USB controller;
>- dr_usb:mode=peripheral - USB in Function mode;
>- dr_usb:phy_type=ulpi - USB should work with ULPI PHYs;
> 
> The purpose of this simple implementation is to define some
> internal API and then we can continue improving user experience
> by adding more mature interface, like hwconfig command with
> bells and whistles. Or not adding, if we feel that current
> interface fits its needs.
> 
> [1] http://en.wikipedia.org/wiki/American_Megatrends
> [2] Regarding ncurses and GUI with mouse support -- I'm just
> kidding.
> [3] The comment regarding apt-get is also a joke, meaning that
> dependency tracking could be non-trivial. For example, for
> enabling HW feature X we may need to disable Y, and turn Z
> into reduced mode (like RMII-only interface for ethernet,
> no MII).
> 
> It's quite trivial to implement simple cases though.
> 
> Signed-off-by: Anton Vorontsov 
> ---
>  common/Makefile|1 +
>  common/hwconfig.c  |  210 
> 
>  include/hwconfig.h |   69 +
>  3 files changed, 280 insertions(+), 0 deletions(-)
>  create mode 100644 common/hwconfig.c
>  create mode 100644 include/hwconfig.h

Applied, thanks.

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: w...@denx.de
The games have always  strengthened  us.  Death  becomes  a  familiar
pattern. We don't fear it as you do.
-- Proconsul Marcus Claudius, "Bread and Circuses",
   stardate 4041.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add bootstrap command

[Matthias Fuchs]

> Dear Matthias Fuchs,
> 
> In message <200907161547.17433.matthias.fu...@esd.eu> you wrote:
> >
> > > Hi Dirk,
> > > 
> > > On Wednesday 15 July 2009 16:46:12 Mike Frysinger wrote:
> > > > On Wednesday 15 July 2009 09:48:00 Dirk Eibach wrote:
> > > > > This adds a generic command for programming I2C bootstrap eeproms.
> > > > > Implementation for Canyonlands board is included.
> > > >
> > > > "bootstrap" is pretty generic.  can you pick something a little more
> > > > descriptive/specific ?
> > > 
> > > I agree with Mike. Please change the command name and the files to 
> > > something 
> > > more specific. How about "4xxbootstrap"? Or "4xxstrap"? 
> > To long for my taste. 
> > 
> > > Any other good ideas  
> > > about this naming welcome. :)
> > We called this command "sbe" on our PMC440 (440EPx) and upcoming 
> > PMC405DE (405EP) board. I must admit that I forget its meaning.
> > Probably something like 'setup bootstrap eeprom'. But it works
> 
> Indeed. "sbe" is not an acceptable name as nobody will know what it's
> suppost to mean.
> 
> > a little mit different that the bootstrap command.
> 
> Actually the name "bootstrap" command itself is something that I
> really dislike.
> 
> Please find a better description (avoiding "bootstrap"), and then
> chose a descriptive name.
ccc - config chip|cpu configuration
scc - setup chip|cpu configuration
wcc - write chip|cpu configuration
wcce - write chip|cpu configuration eeprom

I am not a friend of long names :-)

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

Re: [U-Boot] [PATCH] Add bootstrap command

[Dave Mitchell]

On 7/16/2009 2:36 PM, Wolfgang Denk wrote:
> Dear Matthias Fuchs,
>
> In message<200907161547.17433.matthias.fu...@esd.eu>  you wrote:
>>> Hi Dirk,
>>>
>>> On Wednesday 15 July 2009 16:46:12 Mike Frysinger wrote:
 On Wednesday 15 July 2009 09:48:00 Dirk Eibach wrote:
> This adds a generic command for programming I2C bootstrap eeproms.
> Implementation for Canyonlands board is included.
 "bootstrap" is pretty generic.  can you pick something a little more
 descriptive/specific ?
>
>> a little mit different that the bootstrap command.
>
> Actually the name "bootstrap" command itself is something that I
> really dislike.
>
> Please find a better description (avoiding "bootstrap"), and then
> chose a descriptive name.

Keep in mind the processor UM documentation section that covers these 
boot methods is labeled "Bootstrap Operations". It refers the registers 
that the EEPROM values populate as "bootstrap registers", etc.

There is some logic in tying the section of the processor manual to the 
command. Whatever the command ends up being labeled, it would be nice if 
its purpose was clear to those who actually work in 4xx space.

Not to mention there is documentation referencing the current commands 
used by the evaluation platforms.

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

Re: [U-Boot] Please pull u-boot-cfi-flash

[Wolfgang Denk]

Dear Stefan Roese,

In message <200907161530.12024...@denx.de> you wrote:
> The following changes since commit 7d4450a9773673052fcd7fdf0a4a88c089126ac1:
>   Wolfgang Denk (1):
> mpc5121ads: add JFFS2 and MTDPARTS support; adjust flash map
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-cfi-flash.git master
> 
> Kim Phillips (1):
>   mtd: cfi - if defined, use MAX_FLASH_BANKS_DETECT for static 
> declarations
> 
>  drivers/mtd/cfi_mtd.c |   11 +--
>  1 files changed, 9 insertions(+), 2 deletions(-)

Applied, thanks.

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: w...@denx.de
Applying computer technology is simply finding the  right  wrench  to
pound in the correct screw.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ppc4xx: Cleanup PLU405 board code

[Matthias Fuchs]

Some Coding style cleanup (braces, whitespaces, long lines)

Signed-off-by: Matthias Fuchs 
---
 board/esd/plu405/plu405.c |  118 +++-
 1 files changed, 62 insertions(+), 56 deletions(-)

diff --git a/board/esd/plu405/plu405.c b/board/esd/plu405/plu405.c
index fdacbf6..e41545a 100644
--- a/board/esd/plu405/plu405.c
+++ b/board/esd/plu405/plu405.c
@@ -27,10 +27,7 @@
 #include 
 #include 
 
-
-#if 0
-#define FPGA_DEBUG
-#endif
+#undef FPGA_DEBUG
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -48,7 +45,6 @@ const unsigned char fpgadata[] =
  */
 #include "../common/fpga.c"
 
-
 /*
  * include common auto-update code (for esd boards)
  */
@@ -68,7 +64,7 @@ int N_AU_IMAGES = (sizeof(au_image) / sizeof(au_image[0]));
 /* Prototypes */
 int gunzip(void *, int, unsigned char *, unsigned long *);
 
-int board_early_init_f (void)
+int board_early_init_f(void)
 {
/*
 * IRQ 0-15  405GP internally generated; active high; level sensitive
@@ -94,15 +90,13 @@ int board_early_init_f (void)
 * EBC Configuration Register: set ready timeout to
 * 512 ebc-clks -> ca. 15 us
 */
-   mtebc (epcr, 0xa840); /* ebc always driven */
+   mtebc(epcr, 0xa840); /* ebc always driven */
 
return 0;
 }
 
-int misc_init_r (void)
+int misc_init_r(void)
 {
-   unsigned char *duart0_mcr = (unsigned char *)((ulong)DUART0_BA + 4);
-   unsigned char *duart1_mcr = (unsigned char *)((ulong)DUART1_BA + 4);
unsigned char *dst;
unsigned char fctr;
ulong len = sizeof(fpgadata);
@@ -115,9 +109,10 @@ int misc_init_r (void)
gd->bd->bi_flashoffset = 0;
 
dst = malloc(CONFIG_SYS_FPGA_MAX_SIZE);
-   if (gunzip (dst, CONFIG_SYS_FPGA_MAX_SIZE, (uchar *)fpgadata, &len) != 
0) {
-   printf ("GUNZIP ERROR - must RESET board to recover\n");
-   do_reset (NULL, 0, 0, NULL);
+   if (gunzip(dst, CONFIG_SYS_FPGA_MAX_SIZE,
+  (uchar *)fpgadata, &len) != 0) {
+   printf("GUNZIP ERROR - must RESET board to recover\n");
+   do_reset(NULL, 0, 0, NULL);
}
 
status = fpga_boot(dst, len);
@@ -152,7 +147,7 @@ int misc_init_r (void)
for (index=0;index<1000;index++)
udelay(1000);
}
-   putc ('\n');
+   putc('\n');
do_reset(NULL, 0, 0, NULL);
}
 
@@ -165,7 +160,7 @@ int misc_init_r (void)
printf("%s ", &(dst[index+1]));
index += len+3;
}
-   putc ('\n');
+   putc('\n');
 
free(dst);
 
@@ -180,29 +175,35 @@ int misc_init_r (void)
/*
 * Reset external DUARTs
 */
-   out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | 
CONFIG_SYS_DUART_RST);
+   out_be32((void*)GPIO0_OR,
+in_be32((void*)GPIO0_OR) | CONFIG_SYS_DUART_RST);
udelay(10);
-   out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) & 
~CONFIG_SYS_DUART_RST);
+   out_be32((void*)GPIO0_OR,
+in_be32((void*)GPIO0_OR) & ~CONFIG_SYS_DUART_RST);
udelay(1000);
 
/*
 * Set NAND-FLASH GPIO signals to default
 */
out_be32((void*)GPIO0_OR,
-in_be32((void*)GPIO0_OR) & ~(CONFIG_SYS_NAND_CLE | 
CONFIG_SYS_NAND_ALE));
-   out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | 
CONFIG_SYS_NAND_CE);
+in_be32((void*)GPIO0_OR) &
+~(CONFIG_SYS_NAND_CLE | CONFIG_SYS_NAND_ALE));
+   out_be32((void*)GPIO0_OR,
+in_be32((void*)GPIO0_OR) | CONFIG_SYS_NAND_CE);
 
/*
 * Setup EEPROM write protection
 */
-   out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | 
CONFIG_SYS_EEPROM_WP);
-   out_be32((void*)GPIO0_TCR, in_be32((void*)GPIO0_TCR) | 
CONFIG_SYS_EEPROM_WP);
+   out_be32((void*)GPIO0_OR,
+in_be32((void*)GPIO0_OR) | CONFIG_SYS_EEPROM_WP);
+   out_be32((void*)GPIO0_TCR,
+in_be32((void*)GPIO0_TCR) | CONFIG_SYS_EEPROM_WP);
 
/*
 * Enable interrupts in exar duart mcr[3]
 */
-   out_8(duart0_mcr, 0x08);
-   out_8(duart1_mcr, 0x08);
+   out_8((void *)DUART0_BA + 4, 0x08);
+   out_8((void *)DUART1_BA + 4, 0x08);
 
/*
 * Enable auto RS485 mode in 2nd external uart
@@ -213,26 +214,25 @@ int misc_init_r (void)
out_8((void *)DUART1_BA + 1, fctr); /* write FCTR */
out_8((void *)DUART1_BA + 3, 0);/* write LCR */
 
-   return (0);
+   return 0;
 }
 
 /*
  * Check Board Identity:
  */
-int checkboard (void)
+int checkboard(void)
 {
char str[64];
-   int i = getenv_r ("serial#", str, sizeof(str));
+   int i = getenv_r("serial#", str, sizeof(str));
 
-   puts ("Board: ");
+   puts("Board: ");
 
-   if (i == -1) {
-   puts ("### No HW ID - assuming PLU405");
-   } else {
+   if (i == -1)

Re: [U-Boot] Please pull u-boot-mpc83xx.git

[Wolfgang Denk]

Dear Kim Phillips,

In message <20090714171545.161c6ff8.kim.phill...@freescale.com> you wrote:
> Wolfgang, please pull some ITX board USB config tweaking, and some
> regular maintenance fixes for 83xx:
> 
> The following changes since commit 7d4450a9773673052fcd7fdf0a4a88c089126ac1:
>   Wolfgang Denk (1):
> mpc5121ads: add JFFS2 and MTDPARTS support; adjust flash map
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-mpc83xx.git master
> 
> Kim Phillips (2):
>   mpc83xx: set 64BIT_VSPRINTF for boards using nand_util
>   mpc83xx: increase MONITOR_LEN to offset growing pains
> 
> Valeriy Glushkov (2):
>   usb: mpc834x: added support of the MPH USB controller in addition to 
> the DR one
>   usb: mpx8349itx: added support of loading images from USB storage 
> (MPH/DR)
> 
>  cpu/mpc83xx/cpu_init.c|2 ++
>  include/asm-ppc/immap_83xx.h  |   11 ++-
>  include/configs/MPC8313ERDB.h |3 ++-
>  include/configs/MPC8315ERDB.h |1 +
>  include/configs/MPC8323ERDB.h |2 +-
>  include/configs/MPC832XEMDS.h |2 +-
>  include/configs/MPC8349EMDS.h |2 +-
>  include/configs/MPC8349ITX.h  |   33 ++---
>  include/configs/MPC8360EMDS.h |2 +-
>  include/configs/MPC8360ERDK.h |1 +
>  include/configs/MPC837XERDB.h |2 +-
>  include/configs/SIMPC8313.h   |1 +
>  include/configs/kmeter1.h |2 +-
>  13 files changed, 53 insertions(+), 11 deletions(-)

Applied, thanks.

> p.s. I cannot reply "applied" to my own patch postings because I don't
> get them any more (even though in mailman, I have "Receive your own
> posts to the list?" set to 'yes').

We had this discussion sevral times before, and I cannot see any
problems on the mailing list server. The messages seem to go out
normally.

There has been speculation that some receiving MTAs automatically and
without notice drop messages for which they have already seen the
message ID - do you have a chance to check your local server logs?

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: w...@denx.de
Were there fewer fools, knaves would starve.  - Anonymous
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add bootstrap command

[Matthias Fuchs]

> On Thursday 16 July 2009 17:00:00 Matthias Fuchs wrote:
> > > > > Any other good ideas
> > > > > about this naming welcome. :)
> > > >
> > > > We called this command "sbe" on our PMC440 (440EPx) and upcoming
> > > > PMC405DE (405EP) board. I must admit that I forget its meaning.
> > > > Probably something like 'setup bootstrap eeprom'.
> > >
> > > If you already forgot what it's supposed to mean, then it definitely is
> > > not a good name. Better a bit longer and more descriptive.
> >
> > I like 'sbe' - it short and I even gave it a meaning :-)
> 
> But unfortunately not specific enough for a "common" command.
I think we are talking about a generic 4xx command to write data into
the EEPROM that is read by the bootstrap controller. But I do not care about 
the name ;-)

> 
> > > > But it works
> > > > a little mit different that the bootstrap command.
> > >
> > > It would be great if you could merge/consolidate such 4xx custom commands
> > > into this common one.
> >
> > I was a little inspired by the sequoia code that also comes with a
> > bootstrap command. So please don't ask me to merge it into common code. But
> > your finger on your own nose.
> 
> OK. But if your "sbe" command is "better" than the current bootstrap one, 
> then 
> let's see if it makes sense to use your command as the common one.
Dirk's approach is very generic. Putting nothing but the EEPROM data and a 
descriptive
table into the board file is what we need. I only suggest to add an additional 
label to each 
entry that is used instead of using numbers and I'd to pass this label as 
argument instead of 
the a number. One could use the numbers as labels also :-)

When you do no pass the argument we could either print the descriptive texts as 
menu
(as DIrk did so far) and wait for input or just print the texts as kind of help 
and the must
supply an argument if he want to change something (I prefer the latter).

> 
> > > Does you command support more features? What's the main
> > > difference?
> >
> > Much simpler. Just call sbe with a descriptive argument like a CPU
> > frequency or something like '667-66' on a 440EPx target with 66Mhz PCI
> > clock or 'sr-test-only' for something you will remove later :-). This has
> > two advantages over just using
> > numbers: You can remove configurations without making the following configs
> > in the table moving to the front and its a little more secure meaning you
> > have to type a couple of valid character to  reconfigure the clocking. Just
> > using "bootstrap 5" is error-prone.
> 
> Ack.
> 
> > Well, I like my syntax and behavior, but I do not want to totally dismiss
> > Dirk's idea as long as I can keep my sbe command :-)
> 
> Seems that "your" command is not so bad. ;) I'll take a look at it tomorrow. 
> Perhaps we can use some of your ideas in such a new common (PPC4xx) 
> implementation. :)
My implementation is nothing but ar if-!strcmp-else-if-!strcmp implementation.
But putting things together is a good idea.

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

Re: [U-Boot] [PATCH 1/2] nand/ppc4xx: Move PPC4xx NAND driver to common NAND driver directory

[Scott Wood]

On Thu, Jul 16, 2009 at 03:12:48PM +0200, Stefan Roese wrote:
> Signed-off-by: Stefan Roese 
> Cc: Scott Wood 
> ---

Applied patches 1-2 to u-boot-nand-flash.

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

Re: [U-Boot] Please pull u-boot-coldfire

[Wolfgang Denk]

Dear TC Liew,

In message  you 
wrote:
> Hi Wolfgang,
> 
> Please pull this change for u-boot-coldfire/next into your branch:
> 
> The following changes since commit 7d4450a9773673052fcd7fdf0a4a88c089126ac1:
>   Wolfgang Denk (1):
> mpc5121ads: add JFFS2 and MTDPARTS support; adjust flash map
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-coldfire.git next
> 
> TsiChung Liew (9):
>   ColdFire: Update configuration file to use flash buffer write
>   ColdFire: Update for M54451EVB
>   ColdFire: Add M5208EVB and MCF520x CPU support
>   ColdFire: Fix M53017EVB flash size
>   ColdFire: Remove compiler warning messages
>   Coldfire: Consolidate DSPI driver
>   ColdFire: Add DSPI support for MCF5227x and MCF5445x
>   Command for accessing serial flash update
>   ColdFire: Update bootargs
> 
>  MAKEALL   |1 +
>  Makefile  |   12 +-
>  board/freescale/m5208evbe/Makefile|   44 
>  board/freescale/m5208evbe/config.mk   |   25 +++
>  board/freescale/m5208evbe/m5208evbe.c |   94 +
>  board/freescale/m5208evbe/u-boot.lds  |  142 +
>  board/freescale/m54451evb/u-boot.spa  |9 +-
>  common/cmd_sf.c   |2 +-
>  cpu/mcf5227x/Makefile |2 +-
>  cpu/mcf5227x/cpu_init.c   |   53 +
>  cpu/mcf5227x/dspi.c   |  261 
>  cpu/mcf52x2/config.mk |4 +
>  cpu/mcf52x2/cpu.c |   66 ++
>  cpu/mcf52x2/cpu_init.c|   89 
>  cpu/mcf52x2/interrupts.c  |8 +-
>  cpu/mcf52x2/speed.c   |   13 +-
>  cpu/mcf52x2/start.S   |   33 +++-
>  cpu/mcf5445x/Makefile |2 +-
>  cpu/mcf5445x/cpu_init.c   |   66 ++
>  cpu/mcf5445x/dspi.c   |  239 --
>  cpu/mcf5445x/start.S  |   81 +---
>  drivers/spi/Makefile  |1 +
>  drivers/spi/cf_spi.c  |  357 
>  include/asm-m68k/coldfire/dspi.h  |  229 ++---
>  include/asm-m68k/immap.h  |   29 +++
>  include/asm-m68k/immap_520x.h |  212 +++
>  include/asm-m68k/m520x.h  |  358 
> +
>  include/configs/M5208EVBE.h   |  223 
>  include/configs/M52277EVB.h   |   26 +--
>  include/configs/M53017EVB.h   |7 +-
>  include/configs/M54451EVB.h   |   73 +++
>  include/configs/M54455EVB.h   |   27 +--
>  lib_m68k/board.c  |2 +-
>  33 files changed, 2039 insertions(+), 751 deletions(-)
>  create mode 100644 board/freescale/m5208evbe/Makefile
>  create mode 100644 board/freescale/m5208evbe/config.mk
>  create mode 100644 board/freescale/m5208evbe/m5208evbe.c
>  create mode 100644 board/freescale/m5208evbe/u-boot.lds
>  delete mode 100644 cpu/mcf5227x/dspi.c
>  delete mode 100644 cpu/mcf5445x/dspi.c
>  create mode 100644 drivers/spi/cf_spi.c
>  create mode 100644 include/asm-m68k/immap_520x.h
>  create mode 100644 include/asm-m68k/m520x.h
>  create mode 100644 include/configs/M5208EVBE.h

Applied, thanks.

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: w...@denx.de
Don't tell me how hard you work.  Tell me how much you get done.
- James J. Ling
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] Fix 2k page size NAND for iMX27

[Scott Wood]

On Wed, Jul 15, 2009 at 05:18:40PM +0200, Eric Benard wrote:
>  static int __init imxnd_probe(struct device_d *dev)
>  {
>   struct nand_chip *this;
> @@ -969,7 +978,7 @@ static int __init imxnd_probe(struct device_d *dev)
>   struct imx_nand_host *host;
>   u16 tmp;
>   int err = 0;
> -#ifdef CONFIG_ARCH_MX27
> +#ifdef CONFIG_ARCH_IMX27
>   PCCR1 |= PCCR1_NFC_BAUDEN;
>  #endif
>   /* Allocate memory for MTD device structure and private data */
> @@ -1050,7 +1059,12 @@ static int __init imxnd_probe(struct device_d *dev)
>   this->ecc.layout = &nand_hw_eccoob_16;
>   }
>  
> - host->pagesize_2k = 0;
> + if (pdata->is2k) {
> + host->pagesize_2k = 1;
> + NFMS |= (1 << NFMS_BIT);
> + this->badblock_pattern = &smallpage_memorybased;

Why are you using the small-page badblock pattern with large pages?

> + } else 
> + host->pagesize_2k = 0;

If you use braces on one side of if/else, use them on the other.

> diff --git a/include/asm-arm/arch-imx/imx-nand.h 
> b/include/asm-arm/arch-imx/imx-nand.h
> index 5ebe0be..500bb1a 100644
> --- a/include/asm-arm/arch-imx/imx-nand.h
> +++ b/include/asm-arm/arch-imx/imx-nand.h
> @@ -8,6 +8,7 @@ void imx_nand_load_image(void *dest, int size, int pagesize, 
> int blocksize);
>  struct imx_nand_platform_data {
>   int width;
>   int hw_ecc;
> -};
> + int is2k;
> + };

That last brace should not be indented.

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

Re: [U-Boot] Initial environment variables

[Ben Warren]

Ron,

Ron Madrid wrote:
> When I submitted patches for my new board SIMPC8313 I recall being told that
> I had inappropriately initialized some of my environment variables.  Most
> specifically I am interested in having default serverip, ipaddr, and ethaddr
> environment variables.  Is this most appropriately done with a specific
> #define (such as #define CONFIG_SERVERIP) or within #define
> CONFIG_EXTRA_ENV_SETTINGS?
>
>   
You can set CONFIGs for all of these things in your own private build 
and they'll work, but they're inappropriate for main-line U-boot.  I 
hope the reasoning is obvious.
> Thanks for the help.
>
> Ron
> 
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [GIT PULL] Please pull asm-generic

[Wolfgang Denk]

Dear Michal Simek,

In message <4a55cdcb.7040...@monstr.eu> you wrote:
> Hi Wolfgang,
> 
> Please pull my asm-generic branch. There is only one patch which
> create asm-generic folder with errno.h.
> I have got ack from ppc40x, blackfin, arm, coldfire and avr custodians.
> 
> Thanks,
> Michal
> 
> 
> 
> The following changes since commit 59869ca72df8bc4e4ffa9dd17cb6673bbe010272:
>   Wolfgang Denk (1):
> Merge branch 'master' of git://git.denx.de/u-boot-video
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-microblaze.git asm-generic
> 
> Michal Simek (1):
>   asm-generic: Consolidate errno.h to asm-generic/errno.h
> 
>  board/Marvell/db64360/mv_eth.h |3 +-
>  board/Marvell/db64460/mv_eth.h |2 +-
>  board/prodrive/p3mx/mv_eth.h   |2 +-
>  include/asm-arm/errno.h|  139 +-
>  include/asm-avr32/errno.h  |  133 +
>  include/asm-blackfin/errno.h   |  157 
> +---
>  .../ppc_error_no.h => include/asm-generic/errno.h  |   47 +++
>  include/asm-m68k/errno.h   |  139 +-
>  include/asm-microblaze/errno.h |1 +
>  include/asm-ppc/errno.h|  139 +-
>  include/asm-sh/errno.h |  157 
> +---
>  include/asm-sparc/errno.h  |  163 
> +---
>  12 files changed, 30 insertions(+), 1052 deletions(-)
>  rename board/Marvell/common/ppc_error_no.h => include/asm-generic/errno.h 
> (87%)
>  create mode 100644 include/asm-microblaze/errno.h

Thanks, applied.

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: w...@denx.de
C++ was an interesting and valuable experiment, but we've learned its
lessons and it's time to move on.
- Peter Curran in 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] nand: fixed failed reads on corrected ECC errors in nand_util.c

[Scott Wood]

On Tue, Jul 14, 2009 at 01:51:10PM +0300, Valeriy Glushkov wrote:
> 
> Signed-off-by: Valeriy Glushkov 
> Signed-off-by: Paulraj, Sandeep 
> ---

Applied to u-boot-nand-flash.

>  drivers/mtd/nand/nand_util.c |   10 +-
>  1 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
> index fc16282..694ead6 100644
> --- a/drivers/mtd/nand/nand_util.c
> +++ b/drivers/mtd/nand/nand_util.c
> @@ -567,10 +567,10 @@ int nand_read_skip_bad(nand_info_t *nand, loff_t 
> offset, size_t *length,
>  
>   if (len_incl_bad == *length) {
>   rval = nand_read (nand, offset, length, buffer);
> - if (rval != 0)
> - printf ("NAND read from offset %llx failed %d\n",
> - offset, rval);
> -
> + if (!rval || rval == -EUCLEAN)
> + return 0;
> + printf ("NAND read from offset %llx failed %d\n",
> + offset, rval);

Out of curiosity, why invert the logic from if (error) print; return to if
(!error) return; print; return?

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

Re: [U-Boot] Typo fix: use CONFIG_SOC_DM644X, not CONFIG_SOC_DM646.

[Scott Wood]

On Mon, Jul 13, 2009 at 04:29:04PM -0700, David Brownell wrote:
> On Tuesday 07 July 2009, Scott Wood wrote:
> > I fixed the obvious merge conflict (missing #endif) in "davinci_nand:
> > cleanup I (minor)", but I'm a little confused since the symbol it refers
> > to (CONFIG_SOC_DM6446) doesn't seem to be defined anywhere.  At first I
> > thought it had been replaced with CONFIG_SOC_DM644X, but that doesn't
> > seem to be the case -- AFAICT, there never was a definition of
> > CONFIG_SOC_DM6446 in the tree.  There is one other place in the tree
> > that ifdefs based on it, though (cpu/arm926ejs/davinci/cpu.c).
> > 
> > David, any thoughts?  If this is in error, could you send a followup
> > patch?
> 
> That should have been CONFIG_SOC_DM644X in the first place, yes.
> 
> 
> == CUT HERE
> From: David Brownell 
> 
> Typo fix: use CONFIG_SOC_DM644X, not CONFIG_SOC_DM646.
> 
> Signed-off-by: David Brownell 

Applied to u-boot-nand-flash.

Wolfgang, I used "Typo fix: use CONFIG_SOC_DM644X, not CONFIG_SOC_DM646."
as the first line of the commit message, which differs from the "Pull
request: nand flash" subject of the outer message that will show up on
the archive list.  Do you want me to resend the patch to the list as an
e-mail with that subject (and if I do, can I then fix the "DM646" typo
and clarify which code the fix is for?), or is the updated subject line
in this e-mail enough?

David, the usage in cpu/arm926ejs/davinci/cpu.c should probably be fixed
as well.

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

Re: [U-Boot] [PATCH] Improve U-Boot Porting Guide in the README

[Wolfgang Denk]

Dear Jerry Van Baren,

In message <20090716004258.ga16...@cideas.com> you wrote:
> Update for...
> * BDI2000 -> BDI3000 (BDI2000 is obsolete).
> * Add a line to read the doc/README.* files
> * Fix coding standard violations
> 
> Signed-off-by: Gerald Van Baren 
> ---
> Dear Wolfgang,
> 
> I was looking at the Porting Guide and realized it needed some updating.
> 
> Thanks,
> gvb
> 
>  README |   60 
>  1 files changed, 36 insertions(+), 24 deletions(-)

Applied, thanks :-)

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: w...@denx.de
God made machine language; all the rest is the work of man.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add bootstrap command

[Wolfgang Denk]

Dear Matthias Fuchs,

In message <200907161547.17433.matthias.fu...@esd.eu> you wrote:
>
> > Hi Dirk,
> > 
> > On Wednesday 15 July 2009 16:46:12 Mike Frysinger wrote:
> > > On Wednesday 15 July 2009 09:48:00 Dirk Eibach wrote:
> > > > This adds a generic command for programming I2C bootstrap eeproms.
> > > > Implementation for Canyonlands board is included.
> > >
> > > "bootstrap" is pretty generic.  can you pick something a little more
> > > descriptive/specific ?
> > 
> > I agree with Mike. Please change the command name and the files to 
> > something 
> > more specific. How about "4xxbootstrap"? Or "4xxstrap"? 
> To long for my taste. 
> 
> > Any other good ideas  
> > about this naming welcome. :)
> We called this command "sbe" on our PMC440 (440EPx) and upcoming 
> PMC405DE (405EP) board. I must admit that I forget its meaning.
> Probably something like 'setup bootstrap eeprom'. But it works

Indeed. "sbe" is not an acceptable name as nobody will know what it's
suppost to mean.

> a little mit different that the bootstrap command.

Actually the name "bootstrap" command itself is something that I
really dislike.

Please find a better description (avoiding "bootstrap"), and then
chose a descriptive name.

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: w...@denx.de
A well-written program is its own heaven; a poorly-written program is
its own hell. -- Geoffrey James, "The Tao of Programming"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv3 3/3] 83xx, kmeter1: added NAND support

[Scott Wood]

On Mon, Jul 13, 2009 at 12:15:12PM +0200, Heiko Schocher wrote:
> +#define read_mode()  in_8((volatile unsigned char __iomem *) \
> + CONFIG_NAND_MODE_REG)
> +#define write_mode(val)  out_8((volatile unsigned char __iomem *) \
> + CONFIG_NAND_MODE_REG, val)
> +#define read_data()  in_8((volatile unsigned char __iomem *) \
> + CONFIG_NAND_DATA_REG)
> +#define write_data(val)  out_8((volatile unsigned char __iomem *) \
> + CONFIG_NAND_DATA_REG, val)

No need for volatile when using accessors.  If you kept a pointer around
instead of casting here, you could reasonably use the accessors directly
without needing wrappers...

If this is purely for U-Boot and not shared with Linux we can drop the
__iomem.

> +static void kpn_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int 
> ctrl)
> +{
> + u8  reg_val = read_mode();

No tab after "u8".

> + if (ctrl & NAND_CTRL_CHANGE) {
> + if ( ctrl & NAND_NCE)

No space after "(".

> + reg_val = reg_val & ~KPN_CE1N;
> + else
> + reg_val = reg_val | KPN_CE1N;
> + write_mode(reg_val);
> + }
> + if (cmd == NAND_CMD_NONE)
> + return;
> +
> + reg_val = reg_val & ~(KPN_ALE + KPN_CLE);
> + if (ctrl & NAND_CLE)
> + reg_val = reg_val | KPN_CLE;
> + if (ctrl & NAND_ALE)
> + reg_val = reg_val | KPN_ALE;

If ALE/CLE is sticky in the hardware mode register, you could probably
move this under NAND_CTRL_CHANGE and simplify things a little.

> diff --git a/include/configs/kmeter1.h b/include/configs/kmeter1.h
> index 811ba88..4de0dfc 100644
> --- a/include/configs/kmeter1.h
> +++ b/include/configs/kmeter1.h
> @@ -324,6 +324,12 @@
>  #define CONFIG_SYS_DTT_HYSTERESIS3
>  #define CONFIG_SYS_DTT_BUS_NUM   (CONFIG_SYS_MAX_I2C_BUS)
> 
> +#if defined(CONFIG_CMD_NAND)
> +#define  CONFIG_NAND_KMETER1

No tab after #define.

> +#define CONFIG_SYS_MAX_NAND_DEVICE   1
> +#define CONFIG_SYS_NAND_BASE CONFIG_SYS_PIGGY_BASE
> +#endif
> +
>  #if defined(CONFIG_PCI)
>  #define CONFIG_CMD_PCI
>  #endif

This file looks a little different in the current tree (2 rather than
CONFIG_SYS_MAX_I2C_BUS), so it wouldn't apply cleanly.

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

Re: [U-Boot] [PATCH] Apollon board use common OneNAND IPL linker

[Scott Wood]

On Sun, Jul 12, 2009 at 02:59:26PM +0200, Jean-Christophe PLAGNIOL-VILLARD 
wrote:
> On 17:11 Sat 11 Jul , Kyungmin Park wrote:
> > Use common OneNAND IPL linker script.
> > 
> > Signed-off-by: Kyungmin Park 
> please number the patch to known the apply order

Numbering won't help here -- they have to go in the same patch
atomically, or else bisect will break.

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

Re: [U-Boot] [PATCH] OneNAND IPL: Move u-boot-onenand linker script to common use

[Scott Wood]

On Mon, Jul 13, 2009 at 09:48:30AM +0900, Kyungmin Park wrote:
> Basically I agree your opinion, however do see the other arch OneNAND
> usage? I mean I can't see the other arch patches.

There was nothing but powerpc in nand_spl at first, but I don't think ARM
developers would have appreciated finding hardcoded powerpc assumptions
when they tried to add their boards.

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

Re: [U-Boot] [PATCH 2/2 v6] KB9202: Add NAND support

[Matthias Kaehlcke]

Add KB9202 NAND driver

Signed-off-by: Matthias Kaehlcke 

---

El Thu, Jul 16, 2009 at 01:45:57PM -0500 Scott Wood ha dit:

> On Sun, Jul 12, 2009 at 09:57:13PM +0200, Jean-Christophe PLAGNIOL-VILLARD 
> wrote:
> > On 15:51 Wed 24 Jun , Scott Wood wrote:
> > > On Wed, Jun 24, 2009 at 05:23:05PM +0200, Matthias Kaehlcke wrote:
> > > > Add NAND support for the KwikByte KB9202
> > > > 
> > > > Signed-off-by: Matthias Kaehlcke 
> > > > 
> > > > ---
> > > > 
> > > > El Tue, Jun 23, 2009 at 04:19:40PM -0500 Scott Wood ha dit:
> > > > 
> > > > > I get conflicts in kb9202.h.  Is this against an arch tree, or does it
> > > > > need to be respun?
> > > > 
> > > > The previous patches were against v2009-03, as i had problems
> > > > building the current git head for the kb9202 when i started working on
> > > > the patch. Did you apply the first patch of this series when you got
> > > > the conflict? This patch is based on the current HEAD.
> > > 
> > > No - if it depends on other patches that go through an arch tree, then 
> > > this
> > > patch should go through that tree as well.
> > > 
> > > Acked-by: Scott Wood 
> > Scott I've not follow this patch but for the arm part it's looks fine so 
> > I'll
> > let you handle
> 
> It still does not apply to the current tree, so I cannot accept it as is. 
> 
> The NAND tree is not an appropriate route for unrelated changes to a
> board config file (such as CONFIG_BOOTARGS/CONFIG_BOOTCOMMAND) to go --
> and even if it were, I don't have an easily applyable version of patch
> 1/2 (the mailing list archives mangle things).
> 
> Matthias, can you resend a patch that just adds the NAND driver (for me),
> and a separate patch that just touches the board config (for the arch
> tree)?

ok, here is a patch that only adds the NAND driver. i'll prepare a
board config patch after my first patch has hit mainline to avoid
further confusion :)

changes regarding v5:

 * only add the NAND driver, without touching the board configuration

 drivers/mtd/nand/Makefile  |1 +
 drivers/mtd/nand/kb9202_nand.c |  150 
 2 files changed, 151 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/nand/kb9202_nand.c

diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index a5680e8..aab3b70 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_DRIVER_NAND_BFIN) += bfin_nand.o
 COBJS-$(CONFIG_NAND_DAVINCI) += davinci_nand.o
 COBJS-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_nand.o
 COBJS-$(CONFIG_NAND_FSL_UPM) += fsl_upm.o
+COBJS-$(CONFIG_NAND_KB9202) += kb9202_nand.o
 COBJS-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o
 COBJS-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o
 COBJS-$(CONFIG_NAND_NOMADIK) += nomadik.o
diff --git a/drivers/mtd/nand/kb9202_nand.c b/drivers/mtd/nand/kb9202_nand.c
new file mode 100644
index 000..b8f46fa
--- /dev/null
+++ b/drivers/mtd/nand/kb9202_nand.c
@@ -0,0 +1,150 @@
+/*
+ * (C) Copyright 2006
+ * KwikByte 
+ *
+ * (C) Copyright 2009
+ * Matthias Kaehlcke 
+ *
+ * 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 
+#include 
+
+#include 
+
+/*
+ *  hardware specific access to control-lines
+ */
+
+#define MASK_ALE(1 << 22)   /* our ALE is A22 */
+#define MASK_CLE(1 << 21)   /* our CLE is A21 */
+
+#define KB9202_NAND_NCE (1 << 28) /* EN* on D28 */
+#define KB9202_NAND_BUSY (1 << 29) /* RB* on D29 */
+
+#define KB9202_SMC2_NWS (1 << 2)
+#define KB9202_SMC2_TDF (1 << 8)
+#define KB9202_SMC2_RWSETUP (1 << 24)
+#define KB9202_SMC2_RWHOLD (1 << 29)
+
+/*
+ * Board-specific function to access device control signals
+ */
+static void kb9202_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int 
ctrl)
+{
+   struct nand_chip *this = mtd->priv;
+
+   if (ctrl & NAND_CTRL_CHANGE) {
+   ulong IO_ADDR_W = (ulong) this->IO_ADDR_W;
+
+   /* clear ALE and CLE bits */
+   IO_ADDR_W &= ~(MASK_ALE | MASK_CLE);
+
+   if (ctrl & NAND_CLE)
+   IO_ADDR_W |= MASK_CLE;
+
+   if (ctrl & NAND_ALE)
+   IO_ADDR_W |= MASK_ALE;
+
+   this->IO_ADDR_W = (void

Re: [U-Boot] [PATCH] MTD: OneNAND: Increase the environment size to 4KiB

[Scott Wood]

On Sat, Jul 11, 2009 at 04:49:55PM +0900, Kyungmin Park wrote:
> Also use mtd operatoin instead of onenand functions
> 
> Signed-off-by: Kyungmin Park 

Applied (with non-subject changelog typo fixed) to u-boot-nand-flash.

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

Re: [U-Boot] Initial environment variables

[Mike Frysinger]

On Thursday 16 July 2009 14:57:10 Ron Madrid wrote:
> When I submitted patches for my new board SIMPC8313 I recall being told
> that I had inappropriately initialized some of my environment variables. 
> Most specifically I am interested in having default serverip, ipaddr, and
> ethaddr environment variables.  Is this most appropriately done with a
> specific #define (such as #define CONFIG_SERVERIP) or within #define
> CONFIG_EXTRA_ENV_SETTINGS?

not CONFIG_EXTRA_ENV_SETTINGS

look at common/env_common.c to see what defines are available to you
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Initial environment variables

[Ron Madrid]

When I submitted patches for my new board SIMPC8313 I recall being told that
I had inappropriately initialized some of my environment variables.  Most
specifically I am interested in having default serverip, ipaddr, and ethaddr
environment variables.  Is this most appropriately done with a specific
#define (such as #define CONFIG_SERVERIP) or within #define
CONFIG_EXTRA_ENV_SETTINGS?

Thanks for the help.

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

Re: [U-Boot] [PATCH 2/2 v5] KB9202: Add NAND support

[Scott Wood]

On Sun, Jul 12, 2009 at 09:57:13PM +0200, Jean-Christophe PLAGNIOL-VILLARD 
wrote:
> On 15:51 Wed 24 Jun , Scott Wood wrote:
> > On Wed, Jun 24, 2009 at 05:23:05PM +0200, Matthias Kaehlcke wrote:
> > > Add NAND support for the KwikByte KB9202
> > > 
> > > Signed-off-by: Matthias Kaehlcke 
> > > 
> > > ---
> > > 
> > > El Tue, Jun 23, 2009 at 04:19:40PM -0500 Scott Wood ha dit:
> > > 
> > > > I get conflicts in kb9202.h.  Is this against an arch tree, or does it
> > > > need to be respun?
> > > 
> > > The previous patches were against v2009-03, as i had problems
> > > building the current git head for the kb9202 when i started working on
> > > the patch. Did you apply the first patch of this series when you got
> > > the conflict? This patch is based on the current HEAD.
> > 
> > No - if it depends on other patches that go through an arch tree, then this
> > patch should go through that tree as well.
> > 
> > Acked-by: Scott Wood 
> Scott I've not follow this patch but for the arm part it's looks fine so I'll
> let you handle

It still does not apply to the current tree, so I cannot accept it as is. 

The NAND tree is not an appropriate route for unrelated changes to a
board config file (such as CONFIG_BOOTARGS/CONFIG_BOOTCOMMAND) to go --
and even if it were, I don't have an easily applyable version of patch
1/2 (the mailing list archives mangle things).

Matthias, can you resend a patch that just adds the NAND driver (for me),
and a separate patch that just touches the board config (for the arch
tree)?

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

Re: [U-Boot] [PATCH 17/30] lan91c96/smc91111/smc911x: get mac address from environment

[Mike Frysinger]

On Thursday 16 July 2009 13:41:30 Ben Warren wrote:
> Mike Frysinger wrote:
> > the smsc drivers however are not in the NET_MULTI category -- they dont
> > use any of the common ethernet stack.  so once they are converted to
> > NET_MULTI, they'll get this functionality for free (when exactly were we
> > adding #warning about non-NET_MULTI usage ?).  so rather than expend
> > effort on restoring duplicate code, how about interested parties convert
> > the driver ;). -mike
>
> The #warning patch is done but not submitted.  Pretty lame, I know, but
> it's been a crazy summer.  I have the SMSC driver mostly ported but
> don't have any hardware to test on.  I guess there are 3 days left in
> this merge window to get the ball rolling...  If anybody else has
> already done this, please submit.

i can test SMC911X and SMC9 with real hardware
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add bootstrap command

[Stefan Roese]

On Thursday 16 July 2009 17:00:00 Matthias Fuchs wrote:
> > > > Any other good ideas
> > > > about this naming welcome. :)
> > >
> > > We called this command "sbe" on our PMC440 (440EPx) and upcoming
> > > PMC405DE (405EP) board. I must admit that I forget its meaning.
> > > Probably something like 'setup bootstrap eeprom'.
> >
> > If you already forgot what it's supposed to mean, then it definitely is
> > not a good name. Better a bit longer and more descriptive.
>
> I like 'sbe' - it short and I even gave it a meaning :-)

But unfortunately not specific enough for a "common" command.

> > > But it works
> > > a little mit different that the bootstrap command.
> >
> > It would be great if you could merge/consolidate such 4xx custom commands
> > into this common one.
>
> I was a little inspired by the sequoia code that also comes with a
> bootstrap command. So please don't ask me to merge it into common code. But
> your finger on your own nose.

OK. But if your "sbe" command is "better" than the current bootstrap one, then 
let's see if it makes sense to use your command as the common one.

> > Does you command support more features? What's the main
> > difference?
>
> Much simpler. Just call sbe with a descriptive argument like a CPU
> frequency or something like '667-66' on a 440EPx target with 66Mhz PCI
> clock or 'sr-test-only' for something you will remove later :-). This has
> two advantages over just using
> numbers: You can remove configurations without making the following configs
> in the table moving to the front and its a little more secure meaning you
> have to type a couple of valid character to  reconfigure the clocking. Just
> using "bootstrap 5" is error-prone.

Ack.

> Well, I like my syntax and behavior, but I do not want to totally dismiss
> Dirk's idea as long as I can keep my sbe command :-)

Seems that "your" command is not so bad. ;) I'll take a look at it tomorrow. 
Perhaps we can use some of your ideas in such a new common (PPC4xx) 
implementation. :)

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

Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPU9260 SBC

[Eric Bénard]

Hi Alessandro,

Alessandro Rubini a écrit :
> So, with the current code base, you can't autodetect ram size on the
> atmel 926x.
> 
> I have the same problem, as I have boards that ship as either 64M or
> 128M.  I'd configure for 128M and look for aliases, reconfiguring for
> 64M if needed.  This can be done in lowlevel_init.S or by setting up a
> temporary C environment with sp in static RAM and doing it in C.
> 
> In both cases, this doesn't fit the current code base and some
> refactoring would be needed to go mainline.
> 
OK, in our case auto detection is not required so my updated patch gives 
the choice between both configurations through the Makefile.

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

[U-Boot] [PATCH v2 1/1] Add support for Eukrea CPU9260 SBC

[Eric Benard]

CPUAT91 is built around Atmel's AT91SAM9260 and has up to 64MB of NOR
flash, up to 128MB of SDRAM, up to 2GB of NAND and includes a 10/100
Ethernet PHY in RMII mode.

Signed-off-by: Eric Benard 
---
 MAINTAINERS|4 +
 MAKEALL|1 +
 Makefile   |   13 ++
 board/eukrea/cpu9260/Makefile  |   59 +++
 board/eukrea/cpu9260/config.mk |1 +
 board/eukrea/cpu9260/cpu9260.c |  211 ++
 board/eukrea/cpu9260/cpu9260_led.c |   46 +
 cpu/arm926ejs/at91/lowlevel_init.S |2 +-
 include/configs/cpu9260.h  |  339 
 9 files changed, 675 insertions(+), 1 deletions(-)
 create mode 100644 board/eukrea/cpu9260/Makefile
 create mode 100644 board/eukrea/cpu9260/config.mk
 create mode 100644 board/eukrea/cpu9260/cpu9260.c
 create mode 100644 board/eukrea/cpu9260/cpu9260_led.c
 create mode 100644 include/configs/cpu9260.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 575a7ec..b8d701a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -515,6 +515,10 @@ Dirk Behme 
 
omap3_beagleARM CORTEX-A8 (OMAP3530 SoC)
 
+Eric Benard 
+
+   cpu9260 ARM926EJS (AT91SAM9260 SoC)
+
 Rishi Bhattacharya 
 
omap5912osk ARM926EJS
diff --git a/MAKEALL b/MAKEALL
index 020ff73..bdc80fa 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -592,6 +592,7 @@ LIST_at91=" \
at91sam9m10g45ek\
at91sam9rlek\
cmc_pu2 \
+   cpu9260 \
csb637  \
kb9202  \
meesc   \
diff --git a/Makefile b/Makefile
index 090e645..7ae2bfe 100644
--- a/Makefile
+++ b/Makefile
@@ -2813,6 +2813,19 @@ at91sam9rlek_config  :   unconfig
fi;
@$(MKCONFIG) -a at91sam9rlek arm arm926ejs at91sam9rlek atmel at91
 
+cpu9260_64m_config \
+cpu9260_config :   unconfig
+   @$(MKCONFIG) -a cpu9260 arm arm926ejs cpu9260 eukrea at91
+   @if [ "$(findstring _64m,$@)" ] ; then \
+   echo "#define CONFIG_SYS_SDRC_CR_VAL 
CONFIG_SYS_SDRC_CR_VAL_64MB" \
+   >>$(obj)include/config.h ; \
+   $(XECHO) "... with 64MB SDRAM" ; \
+   else \
+   echo "#define CONFIG_SYS_SDRC_CR_VAL 
CONFIG_SYS_SDRC_CR_VAL_128MB" \
+   >>$(obj)include/config.h ; \
+   $(XECHO) "... with 128MB SDRAM" ; \
+   fi;
+
 meesc_config   :   unconfig
@$(MKCONFIG) $(@:_config=) arm arm926ejs meesc esd at91
 
diff --git a/board/eukrea/cpu9260/Makefile b/board/eukrea/cpu9260/Makefile
new file mode 100644
index 000..5b1acdc
--- /dev/null
+++ b/board/eukrea/cpu9260/Makefile
@@ -0,0 +1,59 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2008
+# Stelian Pop 
+# Lead Tech Design 
+# Ilko Iliev 
+#
+# (C) Copyright 2009
+# Eric Benard 
+#
+# 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 $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y += $(BOARD).o
+COBJS-y += $(BOARD)_led.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y) $(SOBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/eukrea/cpu9260/config.mk b/board/eukrea/cpu9260/config.mk
new file mode 100644
index 000..9ce161e
--- /dev/null
+++ b/board/eukrea/cpu9260/config.mk
@@ -0,0 +1 @@
+TEXT_BASE = 0x21f0
diff --git a/board/eukrea/cpu9260/cpu9260.c b/board/eukrea/cpu9260/cpu9260.c
new file mode 100644
index 000..1d95f96
--- /dev/null
+++ b/board/eukrea/cpu9260/cpu9260.c
@@ -0,0 +1,211 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop 
+ * Lead Tech Design 
+ * Ilko Iliev 
+ *
+ * (C) Copyright 2009
+ * Eric Be

Re: [U-Boot] [PATCH] Add bootstrap command

[Stefan Roese]

On Thursday 16 July 2009 16:16:36 Felix Radensky wrote:
> >> But it works
> >> a little mit different that the bootstrap command.
> >
> > It would be great if you could merge/consolidate such 4xx custom commands
> > into this common one. Does you command support more features? What's the
> > main difference?
>
> BTW, there's also pllalter command for kilauea, that provides similar
> functionality.

Correct. Thanks for reminding me. I'll do some Kilauea work in the next days 
and so I'll probably change this command to the new 4xx-common bootstrap 
command (whatever this will be).

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

Re: [U-Boot] Possible bug in NAND driver

[Scott Wood]

On Mon, Jul 13, 2009 at 02:34:42PM -0500, Paulraj, Sandeep wrote:
> I see that changing
> 
> if (rval != 0)
> 
> 
> to
> 
> if (rval != 0 && rval != -EUCLEAN )
> 
> 
> solves the problem.
> 
> I can submit a patch if required.

Yes, please submit a patch.  Thanks!

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

Re: [U-Boot] [PATCH 17/30] lan91c96/smc91111/smc911x: get mac address from environment

[Ben Warren]

Hi Mike,

Mike Frysinger wrote:
> 
>>> not specific to either of these drivers, so if we did choose to make this
>>> behavior optional via some define, it would make more sense to do it in
>>> the common eth code rather than copying & pasting it everywhere.
>>>   
>> Agreed.  Do you think you have time and resources to craft such a patch?
>> 
>
> net/eth.c:eth_initialize() already has the logic to handle this, but that 
> only 
> applies to NET_MULTI drivers.  and most do not take advantage of it.  i think 
> the documentation should be updated like so:
>   in the driver function that calls eth_register(), the driver should
>   initialize dev->enetaddr to the MAC found in the hardware (if possible)
> and then applicable drivers should be fixed.  if we agree on this route, i 
> can 
> do a quick scan of the net drivers and post relevant patches.
>
>   
That'd be great.  You've done good work bringing consistency to the code. 
> in the case of a mismatch, we would see from the common eth code:
> Warning: Blackfin EMAC MAC addresses don't match:
> Address in SROM is 0a:0a:0a:0a:0a:0a
> Address in environment is  00:e0:22:fe:44:ec
>
>   
> the smsc drivers however are not in the NET_MULTI category -- they dont use 
> any of the common ethernet stack.  so once they are converted to NET_MULTI, 
> they'll get this functionality for free (when exactly were we adding #warning 
> about non-NET_MULTI usage ?).  so rather than expend effort on restoring 
> duplicate code, how about interested parties convert the driver ;).
> -mike
>   
The #warning patch is done but not submitted.  Pretty lame, I know, but 
it's been a crazy summer.  I have the SMSC driver mostly ported but 
don't have any hardware to test on.  I guess there are 3 days left in 
this merge window to get the ball rolling...  If anybody else has 
already done this, please submit.

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

Re: [U-Boot] eth/net driver documentation

[Ben Warren]

Hi Mike,
Mike Frysinger wrote:
> is there any documentation that covers the NET_MULTI driver stack ?  i.e. if  
> i was a network chip vendor and wanted to write a u-boot driver for my part, 
> where would i look ?  or is it a matter of "the code is the documentation" ?  
> i can start a small doc that covers the existing stack if that is the case 
> ... 
> more to keep my sanity so i dont have to keep going through the ethernet 
> stack 
> to remind myself of how things fit together ;).
> -mike
>   
Isn't the code nicely self-documenting? :)  I think yours is a great 
idea.  It's a pretty simple interface, but not necessarily intuitive.  
I'll be glad to help if needed.

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

Re: [U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet.

[Ben Warren]

Mike Frysinger wrote:
> On Tuesday 14 July 2009 04:08:35 Piotr Ziecik wrote:
>   
>> When packets arrive on the interface that are larger than the buffer
>> being passed to U-Boot from a standalone application, then the
>> eth_receive() returns -1 and leaves the packet saved. The next call to
>> eth_receive() will find that same packet and can fail for the exact same
>> reason. A typical scenario is the loader doing ARP with a buffer of 66
>> bytes. The end result is that the ARP will fail and the loader panics.
>>
>> This patch fixes above problem by allowing partial packet read.
>> 
>
> seems like it could easily introduce incorrect behavior in existing 
> applications.  the code also sounds a bit risky ... your change would mean 
> people could read the leading part, but the rest is lost ?
>
> probably better to add a new function with explicit semantics -- 
> eth_receive_partial() or something.
> -mike
>   
I've read this whole thread, but this seems the most appropriate place 
to respond. 

I don't like changing the behavior of an existing call to truncation 
from an error, since who knows what will break.  Adding another call 
with different, documented behavior seems more appropriate.  I agree 
with Wolfgang that this really needs to be simple and personally don't 
see the burdens involved in allocating full MTU-sized buffers, but 
obviously can't envision all usage scenarios.

The talk of jumbo frames is currently moot, as the buffer size is fixed 
in U-boot @ 1518 (#define PKTSIZE 1518).  This should probably be 
configurable, but that's another matter.

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

Re: [U-Boot] [PATCH] - save the server's mac address...

[Ben Warren]

Mike Frysinger wrote:
> On Monday 13 July 2009 16:19:51 Robin Getz wrote:
>   
>> +CONFIG_KEEP_SERVERADDR
>> +
>> +Keeps the server's MAC address, in the env 'serveraddr'
>> +for passing to bootargs (like Linux's netconsole option)
>> 
>
> is a config option really necessary ?  i'd say just add it for everyone
> -mike
>   
ACK
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet.

[Marcel Moolenaar]

On Jul 16, 2009, at 8:39 AM, Wolfgang Denk wrote:
>> Now, one approach would be to ignore packets that don't
>> fit the buffer. This seems unflexible, because it makes
>> it impossible to employ flexible buffer allocation in
>> the application. What's left? The only thing left is that
>
> "flexible buffer allocation"? May I ask what sort of applications you
> have in mind? We're talking about applications running in the context
> of a boot loader, right? For anything fancy you should probably rather
> use an operating system.

Nothing particular. It was just a random thought that
popped in my head while I was typing. I very much doubt
that anything will be implemented, but it does illustrate
(at least to me :-) how one approach makes assumptions
and thereby eliminating a class of implementations (this
being the "ignore packet" behaviour) while the other
does not, allows that same class of applications, but
does so at the "cost" of having applications check more.

Since we are talking about raw packets, the application
(in this case a boot loader) must check anyway, so the
cost is nihil.

>> you return whatever arrived on the interface truncated
>> to the buffer size. That way the application can discard
>> and call read again if headers don't match, or it can
>> allocate a bigger buffer and retry.
>
> Allocate a bigger buffer? What for? The packet has been dropped
> already and is not recoverable.

The scenario in question is when the truncated packet is
passed to the application. There's no dropping. Depending
on the application it surely can wait for the retransmit
or it can ask for one. Both cases (wait or ask) can be
considered retries...

>> The question is not of effort -- there's virtually none.
>> The question is whether this is good engineering. Worst
>> case buffer allocation doesn't strike me as portable nor
>> reasonable.
>
> Not portable? In which way do you see any porting  issues  here?  Not
> reasonable?  How many such buffers do you need, then? All it takes is
> a different size  in  simple  call  to  malloc(),  or  am  I  missing
> something?

Wolfgang,

It seems to me that these questions stem from an assumption
about how applications are written. That is, I always interpret
these questions as an inquiry into the use of an API so as to
argue about how an API is used, rather than how the API should
behave. Personally, I don't think this is the right approach
when discussing an API, because it the API comes with an assumed
use case.

Anyway: I'll answer your question given above beneath the
following...

> Please let's keep in mind: this is a boot loader, and a very  minimal
> network  stack.  It  is  not an OS, and we don't claim to implement a
> TCP/IP stack.

The application in question is a boot loader. One that does not
implement a TCP/IP stack either. I would argue that it's exactly
the application one would expect to run under U-Boot.

As to the porting issues you were asking about: the FreeBSD boot
loader runs in many environments: PC BIOS, EFI, Open Firmware,
U-Boot, ARC (obsolete), etc.
If The U-Boot APIs requires the FreeBSD loader to allocate 9K
buffers just so that it can receive a tiny ARP response, then
it's the only environment to do so. Changing the FreeBSD loader
to work with U-Boot affects the loader in the other environments
as well. This by itself shows that there's a portability issue.

As for the number of buffers: we need 1 for ARP. A small one I
might add. However, BOOTP/DHCP also needs a buffer. That's one
more. TFTP needs a buffer. etc, etc...
The question as to how many buffers we need cannot really be
answered without digressing in "why don't you restructure your
code so that you only need 1". It all depends on how code is
organized, designed, modularized or combined. In the case of
the FreeBSD loader we a few places to change. This does not
include all the non-open features that people have added to the
loader.


Let me try to spin it differently:

The U-Boot APIs were intended and designed to work with any
application. More to the point: they we designed, implemented
and added to U-Boot *because* of the need arising from wanting
to use the FreeBSD loader under U-Boot.
A such, the APIs were designed with the loader in mind and
they were tested with the FreeBSD loader. Besides adding a
U-Boot interface layer to the loader, no loader changes were
made.

Ok, there's bug. Or at least a scenario that wasn't really
thought about or considered. The pivotal application, key
in designing and implementing the APIs, shows that the API
in U-Boot can hang. [The hang being caused by the reception
of a packet that is larger than the buffer the application
provides]. There are 2 simple fixed that would fix the API:
1) just drop the packet. 2) return a truncated packet.

However, I'm currently in a discussion that suggests that
the application should use bigger buffers. That strikes me
as odd, because by intend and design the API was to support
the application without requiri

Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPU9260 SBC

[Alessandro Rubini]

> I've tried something very close to what is done in tqm8xx but I don't 
> manage to get something reliable : either it hangs or I get data abort.
>
> After checking the datasheet, I don't understand how we can change the  
> geometry of this SDRAM controler while running from SDRAM

No, you can't. That part must be done while you run from flash.
Actually, this is done in cpu/arm926ejs/at91/lowlevel_init.S,
in the table SMRDATA1.

So, with the current code base, you can't autodetect ram size on the
atmel 926x.

I have the same problem, as I have boards that ship as either 64M or
128M.  I'd configure for 128M and look for aliases, reconfiguring for
64M if needed.  This can be done in lowlevel_init.S or by setting up a
temporary C environment with sp in static RAM and doing it in C.

In both cases, this doesn't fit the current code base and some
refactoring would be needed to go mainline.

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

Re: [U-Boot] [PATCH][repost] mkimage support ( bin_dep.sh Support)

[Prafulla Wadaskar]

 

> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de] 
> Sent: Thursday, July 16, 2009 4:55 PM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH][repost] mkimage support ( 
> bin_dep.sh Support)
> 
> Dear Prafulla Wadaskar,
> 
> In message 
> <73173d32e9439e4abb5151606c3e19e202ddf26...@sc-vexch1.marvell.
> com> you wrote:
> > 
> > > > The code really needs to be rewritten in a clean fashion  using 
> > > > common programming metaphors, style and library functions (i.e. 
> > > > use getopt(3), etc.).
> >
> > During restructuring activity for this utility, I found 
> that most of 
> > the code and algorithm is common between mkimage and 
> kwimage (old name doimage).
> 
> I'm not really surprised.
> 
> > I have studied mkimage code.
> > kwimage requirements can be well supported by adding one 
> more type support to the mkimage (i.e. "bootrom").
> 
> "bootrom" is a way to generic name. You have a specific data 
> format in mind, so please use a more specific name.

Kirkwood Specs call it as "boot image" which is a post processed binary bundled 
with BootRom header and optional header extension so that Kirkwood's internal 
bootRom loads it from specific media to DRAM and starts execution.
Ref: (Section 24.2.4) 
http://www.marvell.com/files/products/embedded_processors/kirkwood/FS_88F6180_9x_6281_OpenSource.pdf

So I will name this as "kwbimage" and target will be u-boot.kwb

Further boot image could be different for "boot from SF/NANDF/UART/SATA" etc...
This information will be abstracted form board specific config.mk.

> 
> > The bootrom image file generation generic abstraction can 
> be provided with new file ./common/bootrom.c internally 
> supported by Arch specific macros/code.
> 
> Hm... I guess this would make it even more complicated to 
> separate the mkimage tool from the rest of the U-Boot code. 
> There have been repeated requests to make it more independent 
> or even integrate in into the Linux kernel code tree. We 
> should keep this in mind.
So I will limit my self not to disturb current mkimage architecture.
I will add additional kwbimage type support the related code will be abstracted 
to ./tools/kwbimage.c
 
> 
> Note that this is not an argument against your proposal - 
> just a note that we should keep this aspect in mind when 
> implementing and reviewing the new code.
Thanks...If this find useful for others we can think of expanding it latter.
For ex. Type = bimage and abstraction in bimage.c/h

> 
> > With this-
> > 1. mkimage can be reused for kwimage generation.
> 
> Sounds good to me.
> 
> > 2. Kwimage generation can be supported in a generic way under 
> > "bootrom" image type
> 
> This doesn't sound such a  good  idea  to  me.  As  mentioned 
>  above, "bootrom"  is  a very generic name which can be 
> anything - but if you assign this name to a specific format, 
> it  should  be  exactly  _one_ speific format.
Cool. In sync... Type renamed "kwbimage", abstraction in ./tools/kwbimage.c/h
 
> 
> > 3. In future the same interface can be used by other 
> Marvell and non Marvell socs for similar kind of requirements.
> >
> > Shall I go ahead with this approach?
> > or I should not disturb mkimage at all?
> > What is your opinion?
> 
> I think this is a pretty good plan. Please go ahead.
Thanks a lot :-D

Regards..
Prafulla . .

> 
> 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: 
> w...@denx.de After a heated argument on some trivial matter 
> Nancy [Astor]  .  .  .
> shouted,  ``If  I were your wife I would put poison in your coffee!''
> Whereupon Winston Churchill with equal heat and  sincerity  
> answered, ``And if I were your husband I would drink it.''
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet.

[Marcel Moolenaar]

On Jul 16, 2009, at 5:39 AM, Wolfgang Denk wrote:

> Dear Piotr =?iso-8859-2?q?Zi=EAcik?=,
>
> In message <200907161151.59353.ko...@semihalf.com> you wrote:
>>
 This patch fixes above problem by allowing partial packet read.
>>>
>>> seems like it could easily introduce incorrect behavior in existing
>>> applications.  the code also sounds a bit risky ... your change  
>>> would mean
>>> people could read the leading part, but the rest is lost ?
>>
>> discaded, if buffer is too small. This behaviour is similar to  
>> Linux recv()
>
> But recv() is on another level. Here we are dealing with receiving raw
> ethernet frames.

Yes. As such truncation and other protocol errors need
to be checked for. Including the reception of packets
you're not waiting for.

If an application prepares a 100-byte buffer, then it does
so under the assumption that what it's waiting for is not
larger than 100 bytes. This is a fair assumption, because
applications wait for specific packets. In the trigger case:
an ARP response.

This is also the crux of the problem. The application
waits for a specific response, but there's no guarantee
(due to broadcast or multicast packets on the LAN) that
the next packet to arrive on the interface is the one
that we're waiting for.

Now, one approach would be to ignore packets that don't
fit the buffer. This seems unflexible, because it makes
it impossible to employ flexible buffer allocation in
the application. What's left? The only thing left is that
you return whatever arrived on the interface truncated
to the buffer size. That way the application can discard
and call read again if headers don't match, or it can
allocate a bigger buffer and retry.

>
>> function. I do not see why we have to force application to prepare  
>> 1,5kB
>> buffer for received packets when for example it waits for ARP reply.
>
> Come on - what exactly is the extra effort you have to spend to
> prepare a bigger buffer?

The problem with this approach is that theoretically
an application needs to use a buffer that is as large
as the maximum size of a packet that can appear on the
interface. For example, with jumbo frames this means
that any application, module or function that wants to
receive even the smallest amount of data (say an ARP
response) needs to allocate a 9K buffer.

The question is not of effort -- there's virtually none.
The question is whether this is good engineering. Worst
case buffer allocation doesn't strike me as portable nor
reasonable.

My $0.02.

-- 
Marcel Moolenaar
xcl...@mac.com



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

Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPU9260 SBC

[Eric Bénard]

Dear Wolfgang,

Wolfgang Denk a écrit :
>> I'm not sure it's possible to use a generic geometry/timings there else 
>> u-boot may never relocate.
>> How would you do this ?
> 
> Well, normally you have 2 or 3 row/col combinations that have to be
> considered; you try these in turn until you find one where
> get_ram_size() returns a non-zero size; if several work, you use that
> which returns the biggest size.
> 
> See for example "board/tqc/tqm8xx/tqm8xx.c" - it tries 8, 9 and 10
> column mode...
> 
I've tried something very close to what is done in tqm8xx but I don't 
manage to get something reliable : either it hangs or I get data abort.

After checking the datasheet, I don't understand how we can change the 
geometry of this SDRAM controler while running from SDRAM : each time we 
increase the colum number, the address are modified thus we can't 
execute any more u-boot's code as it's no more where we are expecting it.

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

Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Scott Wood]

On Thu, Jul 16, 2009 at 05:42:27PM +0200, Wolfgang Denk wrote:
> Dear Scott Wood,
> 
> In message <4a5f4913.5030...@freescale.com> you wrote:
> > 
> > So how do you propose that illegal divide operations be reported to the 
> > application?
> 
> In the same way as Linux is doing it (i. e. usually nothing at all) ?

Yay bugs.

> > What is so unreasonable about having a function to print a message and 
> > dump registers?
> 
> We didn't need one for the so far. What exactly do we need it for now?

For the same reason we have cpu/*/traps.c.

> > You could even make it a weak symbol that stays at NULL, so any attempt 
> > to call it will trap that way (assuming NULL pointers are trapped in 
> > U-Boot on that architecture...).
> 
> As you know, they are not.

If you're happy with not making it debuggable, then there's no need to
trap on the NULL -- just make sure it never happens. :-)

I'd much rather spend the handful of bytes on at least a
__builtin_trap(), though.

Or do compiler implementation specific things such as reimplementing
libgcc functions or carefully avoiding generating calls to them, if you
prefer.  Whatever.

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

Re: [U-Boot] [PATCH 5/6] net: Kirkwood_egiga: forced interface speed config support

[Prafulla Wadaskar]

 

> -Original Message-
> From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] 
> Sent: Thursday, July 16, 2009 8:15 PM
> To: u-boot@lists.denx.de
> Cc: Prafulla Wadaskar; Manas Saksena; Ronen Shitrit; Nicolas 
> Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek
> Subject: Re: [U-Boot] [PATCH 5/6] net: Kirkwood_egiga: forced 
> interface speed config support
> 
> Hi Prafulla, hi Marvell engineers,
> 
> 
> > By default Auto Negotiation is enabled for interface speed 
> but on some 
> > platforms like RD6281A it does not work.
> > If you want to forced program it to desired speed, this patch helps-
> 
> do you have some information why auto negotiation doesn't 
> work on RD6281A?
Hi Dieter
I do not have good answer for this with me :-(
On RD6281A I thought Auto negotiation should work, but it did not.
During my debugging, I performed several trial and error methods and forcing 
PHY interface speed to 1000BPs worked for me.

So I exposed this configuration through this patch.

I will certainly look for better answer for you

Regards..
Prafulla . .
 
> I'm working on custom hardware and don't want to do the same 
> mistake :)
> 
> Many thanks,
> Dieter
> 
> 
> 
> > 
> > Through this patch Auto negotiation can be disabled and desired 
> > interface speed can be configured
> > 
> > This patch is tested on RD6281A Kirkwood board
> > 
> > Signed-off-by: Prafulla Wadaskar 
> > ---
> >  drivers/net/kirkwood_egiga.c |   24 
> >  1 files changed, 24 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/net/kirkwood_egiga.c 
> > b/drivers/net/kirkwood_egiga.c index 3c5db19..1dfd567 100644
> > --- a/drivers/net/kirkwood_egiga.c
> > +++ b/drivers/net/kirkwood_egiga.c
> > @@ -415,7 +415,31 @@ static int kwgbe_init(struct eth_device *dev)
> > /* Assign port configuration and command. */
> > KWGBEREG_WR(regs->pxc, PRT_CFG_VAL);
> > KWGBEREG_WR(regs->pxcx, PORT_CFG_EXTEND_VALUE);
> > +   /*
> > +* Forced 10/100/1000BASE-T interface speed configuration
> > +* By default Auto Negotiation of interface speed is enabled
> > +* This can be forced disabled and desired speed can be 
> configured
> > +*/
> > +#ifdef CONFIG_DIS_AUTO_NEG_SPEED_GMII #if (!defined 
> > +(CONFIG_PHY_SPEED) || (CONFIG_PHY_SPEED == _1000BASET))
> > +   KWGBEREG_WR(regs->psc0, PORT_SERIAL_CONTROL_VALUE
> > +   | KWGBE_DIS_AUTO_NEG_SPEED_GMII
> > +   | KWGBE_SET_GMII_SPEED_TO_1000);
> > +#elif (CONFIG_PHY_SPEED == _100BASET)
> > +   KWGBEREG_WR(regs->psc0, PORT_SERIAL_CONTROL_VALUE
> > +   | KWGBE_DIS_AUTO_NEG_SPEED_GMII
> > +   | KWGBE_SET_GMII_SPEED_TO_10_100
> > +   | KWGBE_SET_MII_SPEED_TO_100);
> > +#elif (CONFIG_PHY_SPEED == _10BASET)
> > +   KWGBEREG_WR(regs->psc0, PORT_SERIAL_CONTROL_VALUE
> > +   | KWGBE_DIS_AUTO_NEG_SPEED_GMII
> > +   | KWGBE_SET_GMII_SPEED_TO_10_100
> > +   | KWGBE_SET_MII_SPEED_TO_10);
> > +#endif /* CONFIG_PHY_SPEED == _10BASET */ #else
> > KWGBEREG_WR(regs->psc0, PORT_SERIAL_CONTROL_VALUE);
> > +#endif /* CONFIG_DIS_AUTO_NEG_SPEED_GMII */
> > +
> > /* Disable port initially */
> > KWGBEREG_BITS_SET(regs->psc0, KWGBE_SERIAL_PORT_EN);
> >  
> 
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot doesn't compile for M54455EVB_intel_config

[TC Liew]

Matt,

In asm-m68k/io.h, please add

#ifndef _IO_BASE
#define _IO_BASE 0
#endif

Regards,
TsiChung

On Wed, Jul 15, 2009 at 9:43 AM, Matthew Lear wrote:
> Hi TsiChung / Wolfgang,
>
> I just pulled u-boot.git to re-sync and tried to configure and build it
> for M54455EVB_intel_config but the compilation failed. I tried a fresh
> clone just to be sure and it was the same.
>
> [snip]
>
> m68k-linux-gnu-gcc  -g  -Os   -ffixed-d7 -msep-data -D__KERNEL__
> -DTEXT_BASE=0x -I/home/matt/nht/git-uboot-master/u-boot/include
> -fno-builtin -ffreestanding -nostdinc -isystem
> /opt/freescale/usr/local/gcc-4.2.35-eglibc-2.5.35/m68k-linux/lib/gcc/m68k-linux-gnu/4.2.0/include
> -pipe  -DCONFIG_M68K -D__M68K__ -mcpu=54455 -fPIC -DTEXT_BASE=0x
> -Wall -Wstrict-prototypes -fno-stack-protector   -o cmd_ide.o cmd_ide.c -c
> cmd_ide.c: In function '__ide_outb':
> cmd_ide.c:529: error: '_IO_BASE' undeclared (first use in this function)
> cmd_ide.c:529: error: (Each undeclared identifier is reported only once
> cmd_ide.c:529: error: for each function it appears in.)
> cmd_ide.c: In function '__ide_inb':
> cmd_ide.c:538: error: '_IO_BASE' undeclared (first use in this function)
> cmd_ide.c: In function 'output_data':
> cmd_ide.c:942: error: '_IO_BASE' undeclared (first use in this function)
> cmd_ide.c: In function 'input_data':
> cmd_ide.c:1000: error: '_IO_BASE' undeclared (first use in this function)
> cmd_ide.c: In function 'output_data_shorts':
> cmd_ide.c:1705: error: '_IO_BASE' undeclared (first use in this function)
> cmd_ide.c: In function 'input_data_shorts':
> cmd_ide.c:1711: error: '_IO_BASE' undeclared (first use in this function)
> make[1]: *** [cmd_ide.o] Error 1
> make[1]: Leaving directory `/home/matt/nht/git-uboot-master/u-boot/common'
> make: *** [common/libcommon.a] Error 2
>
>
> Is this expected at the current time?
>
> Rgds,
> --  Matt
> ___
> 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