date:20110210

Dear Marcel,

In message 201102100846.49072.korg...@home.nl you wrote:
 
 I did create a new command dfu that activates the controller and DFU.
 I than used the GPBR register of the AT91 to make u-boot know that it has to 
 activate DFU by script. Basically the value of the GPBR register either tells 
 u-boot to wait for TFTP or DFU ways to upgrade.

Hm... Please keep in mind that DFU support is supposed to be
completely hardware independent - it should not only work on AT91
systems, and not even be restricted to ARM, but instead be usabel on
all architectures and boards.

 I'm on a real deadline for my project. I have to go on business trip end of 
 next week and very limited in time. I finished u-boot for my companies 
 products 
 and I can post a full diff of it. I was hoping someone could help me out 

I'm not sure what you mean by full diff. If you think about posting
all your changes in a single patch, then please don't.  You have to
split the stuff into independent parts - DFU support is then just one
patch in your patch series.

 testing the patch on their board (either sam9g45 or using at91_udc ) and help 
 me to post the changes to u-boot.

Thn it is all the more important to correctly split your changes into
independent (orthogonal) patches.

 I can also post a full diff the the forum, but it's rather large I think. I 
 never posted changes before, so I have no idea yet how to do it. I know 
 there's reading info about it, but had no time yet to look into it (shame on 
 me :-) ).

see http://www.denx.de/wiki/U-Boot/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 typical page layout program is nothing more  than  an  electronic
light table for cutting and pasting documents.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] NOR sectors are not all protected as they should be.

Dear Wolfgang,

Thanks for your reply and your help.

On 02/09/2011 07:50 PM, Wolfgang Denk wrote:

 The first sectors #0,1,2,3 are protected and sectors #8,9 (U-Boot
 environment) are protected.
 It should be sectors #0,1,2,3,4,5,6,7 and sectors #8,9.
 No, it should not.  Only the sectors that actually contain the U-Boot
 code and environment are protected.  Obviously your image is small
 enough to fit in the first 4 sectors (= 256 KiB).  Actually this is a
 perfectly normal size, and your reservation of 512 KiB was just a
 waste of memory.  You can see that the following sectors are unused
 from the 'E' (= empty) flag.
Even if the first 4 sectors are empty they are protected (see below). So 
the protected sectors are not selected depending on if U-Boot is burnt 
in them, isn't it ?

  Sector Start Addresses:
   A000 E RO   A001 E RO   A002 E RO   A003 E RO   
A004 E
   A005 E  A006 E  A007 E  A008   RO   
A009 E RO
   A00A E  A00B E  A00C E  A00D E  
A00E E
   A00F E  A010 E  A011 E  A012 E  
A013 E
   A014 E  A015 E  A016 E  A017 E  
A018 E
   A019 E  A01A E  A01B E  A01C E  
A01D E
   A01E E  A01F E  A020 E  A021 E  
A022 E

I know my image fit in 256KiB, my image is 220KiB that I reserved more 
space just in case for the future releases.

 When they don't contain any code, there is also no need to pretect
 them, right?
It should be, but it's not completely true.

Best regards.

 Best regards,

 Wolfgang Denk

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

Re: [U-Boot] Can't erase or read NOR using mtd part-id

Dear Wolfgang,

Thanks for this explanation.

Best regards
Alex

On 02/09/2011 07:50 PM, Wolfgang Denk wrote:
 Dear Alexandre Gambier,

 In message4d52b843.5010...@ftemaximal.fr  you wrote:
 I'm using u-boot to boot a Linux-based device.
 I created some MTD partitions for my NOR and NAND flashes.

 Here is the configuration:

 device nor0NOR, # parts = 4
#: namesizeoffset  mask_flags
0: U-Boot  0x0008  0x  0
1: Environment 0x0002  0x0008  0
2: Kernel  0x0040  0x000a  0
3: FreeNOR 0x0036  0x004a  0

 ...
 When I want to erase the U-Boot partition I can't use the command `erase
 U-Boot`, the following error occurs : incorrect device type in U-Boot.
 I must use the command `erase 1:0-7`.

 Is-it normal ?
 There are many ways to specify a flash area. When referring to MTD
 partitions, the synatx is device name,partition number, i. e.
 for the partition named U-Boot above you use

   erase nor0,0

 So yes, the behaviour is normal.

 My second question is when I try to read the Environment partition with
 the command `md.b Environment 128` I get the following dump (which is
 not correct).

 000e: 0e 40 ff e0 18 40 c0 cb 18 40 18 40 0c cb 03 61
 .@...@...@.@...a
 ...

 Only very few commands (and only flash related ones) accept MTD
 partition specifications for addresses.  md does not. What happpens
 here is that the argument Environment gets parsed as a hex number.
 Only the first character, 'E', can successfully be converted, then the
 conversion stops (without error message).  Then you get the dump
 starting at 0x000E.

 Is-it normal as well ?
 Yes, it is.

 Best regards,

 Wolfgang Denk

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

Re: [U-Boot] Altering cpu/mpc85xx/start.S to set GPIO


On Feb 10, 2011, at 1:20 AM, Rick Ramstetter wrote:

 I am testing on an e500 core P2020 QorIQ (mpc85xx). As part of this testing,
 I would like to set a GPIO pin high (aka turn on an led) during extremely
 early U-boot code.
 
 I have modified cpu/mpc85xx/start.S to (1) set GPIMR for one gpio pin, (2)
 set GPDIR for the same gpio pin, and (3) set GPDAT for the same gpio pin.
 The writes I have introduced(to GPDAT etc) occur directly after the PPC
 exception vectors are set. The relevant portion of my modified start.S is
 attached below.
 
 The problem I'm having is that the first stw instruction (specifically,
 stw 1,0(9)) sends the core into the e00 exception vector. This exception
 is set in start.S as STD_EXCEPTION(0x0e00, InstructionTLBError,
 UnknownException). After the exception occurs, the processor halts at
 0xfff80e00.
 
 As per the P2020 QoriQ manual's section 4.5.3 (p. 4-48, QorIQ P2020
 Integrated Processor Reference Manual), I ought to be able to access
 CCSRBAR without mapping it through a TLB; the board in question is
 configured to boot from eSPI. As the memory mapped gpio pins are in ccsr
 space, I am left quite confused as to why such accesses are causing a TLB
 exception.
 
 Can anyone offer any pointers on what I'm doing wrong?
 
 Thank you,
 -Rick
 
 Modified start.s follows:
 ---
 
 start_e500:
/* L1 */
 li r0,2
 mtspr L1CSR0,r0 /* invalidate d-cache */
 mtspr L1CSR1,r0 /* invalidate i-cache */
 mfspr r1,DBSR
 mtspr DBSR,r1 /* Clear all valid bits */
 
 /* Enable L1 Caches early  */
 lis r2,L1CSR0_CPE@H /* enable parity */
 ori r2,r2,L1CSR0_DCE
 mtspr L1CSR0,r2 /* enable L1 Dcache */
 isync
 mtspr L1CSR1,r2 /* enable L1 Icache */
 isync
 msync
/* Setup interrupt vectors */
 lis r1,TEXT_BASE@h
 mtspr IVPR,r1
 
 li r1,0x0100
 mtspr IVOR0,r1 /* 0: Critical input */
 li r1,0x0200
 mtspr IVOR1,r1 /* 1: Machine check */
 li r1,0x0300
 mtspr IVOR2,r1 /* 2: Data storage */
 li r1,0x0400
 mtspr IVOR3,r1 /* 3: Instruction storage */
 li r1,0x0500
 mtspr IVOR4,r1 /* 4: External interrupt */
 li r1,0x0600
 mtspr IVOR5,r1 /* 5: Alignment */
 li r1,0x0700
 mtspr IVOR6,r1 /* 6: Program check */
 li r1,0x0800
 mtspr IVOR7,r1 /* 7: floating point unavailable */
 li r1,0x0900
 mtspr IVOR8,r1 /* 8: System call */
 /* 9: Auxiliary processor unavailable(unsupported) */
 li r1,0x0a00
 mtspr IVOR10,r1 /* 10: Decrementer */
 li r1,0x0b00
 mtspr IVOR11,r1 /* 11: Interval timer */
 li r1,0x0c00
 mtspr IVOR12,r1 /* 12: Watchdog timer */
 li r1,0x0d00
 mtspr IVOR13,r1 /* 13: Data TLB error */
 li r1,0x0e00
 mtspr IVOR14,r1 /* 14: Instruction TLB error */
 li r1,0x0f00
 mtspr IVOR15,r1 /* 15: Debug */
 
 /* Clear and set up some registers. */
 li  r0,0x
 lis r1,0x
 mtspr DEC,r0 /* prevent dec exceptions */
 mttbl r0 /* prevent fit  wdt exceptions */
 mttbu r0
 mtspr TSR,r1 /* clear all timer exception status */
 mtspr TCR,r0 /* disable all */
 mtspr ESR,r0 /* clear exception syndrome register */
 mtspr MCSR,r0 /* machine check syndrome register */
 mtxer r0 /* clear integer exception register */
 
 
 /* BEGIN MODIFICATIONS */
 /* TURN ON THE LED */
 s 9,0xff70

is this a typo?

 lis 11,0xff70
 lis 10,0xff70
 lis 1,0x1
 
 /* set low 16 bits of r9,r10,r11 */
 ori 9,9,64512  /* 0xfc00 */
 ori 10,10,64520/* 0xfc08 */
 ori 11,11,64528/* 0xfc10 */
 
 /* push contents of r1 to r9,r10,r11 */
 stw 1,0(9)
 stw 1,0(11)
 stw 1,0(10)
 
/* for purposes of this message, you can assume the following loop
 exists (or not) */
  b .
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

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

Re: [U-Boot] Altering cpu/mpc85xx/start.S to set GPIO

2011-02-10 Thread Rick Ramstetter

On Thu, Feb 10, 2011 at 12:24 AM, Kumar Gala ga...@kernel.crashing.org
 wrote:

  /* BEGIN MODIFICATIONS */
  /* TURN ON THE LED */
  s 9,0xff70

 is this a typo?


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

Re: [U-Boot] NOR sectors are not all protected as they should be.

Dear Alexandre Gambier,

In message 4d539e01.6070...@ftemaximal.fr you wrote:
 
  waste of memory.  You can see that the following sectors are unused
  from the 'E' (= empty) flag.
 Even if the first 4 sectors are empty they are protected (see below). So 
 the protected sectors are not selected depending on if U-Boot is burnt 
 in them, isn't it ?

No, they are selected based on the real size of the (running) U-Boot
image.

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
Of course there's no reason for it, it's just our policy.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] NOR sectors are not all protected as they should be.

Ok.

Thank you very much.

On 02/10/2011 10:48 AM, Wolfgang Denk wrote:
 Dear Alexandre Gambier,

 In message4d539e01.6070...@ftemaximal.fr  you wrote:
 waste of memory.  You can see that the following sectors are unused
 from the 'E' (= empty) flag.
 Even if the first 4 sectors are empty they are protected (see below). So
 the protected sectors are not selected depending on if U-Boot is burnt
 in them, isn't it ?
 No, they are selected based on the real size of the (running) U-Boot
 image.

 Best regards,

 Wolfgang Denk

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

Re: [U-Boot] Altering cpu/mpc85xx/start.S to set GPIO

2011-02-10 Thread Aggrwal Poonam-B10812

 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
 On Behalf Of Kumar Gala
 Sent: Thursday, February 10, 2011 1:54 PM
 To: Rick Ramstetter
 Cc: u-boot@lists.denx.de; Thomas Taranowski
 Subject: Re: [U-Boot] Altering cpu/mpc85xx/start.S to set GPIO

 On Feb 10, 2011, at 1:20 AM, Rick Ramstetter wrote:

  I am testing on an e500 core P2020 QorIQ (mpc85xx). As part of this
  testing, I would like to set a GPIO pin high (aka turn on an led)
  during extremely early U-boot code.

  I have modified cpu/mpc85xx/start.S to (1) set GPIMR for one gpio pin,
  (2) set GPDIR for the same gpio pin, and (3) set GPDAT for the same
 gpio pin.
  The writes I have introduced(to GPDAT etc) occur directly after the
  PPC exception vectors are set. The relevant portion of my modified
  start.S is attached below.

  The problem I'm having is that the first stw instruction
  (specifically, stw 1,0(9)) sends the core into the e00 exception
  vector. This exception is set in start.S as STD_EXCEPTION(0x0e00,
  InstructionTLBError, UnknownException). After the exception occurs,
  the processor halts at 0xfff80e00.

  As per the P2020 QoriQ manual's section 4.5.3 (p. 4-48, QorIQ P2020
  Integrated Processor Reference Manual), I ought to be able to access
  CCSRBAR without mapping it through a TLB; the board in question is
  configured to boot from eSPI. As the memory mapped gpio pins are in
  ccsr space, I am left quite confused as to why such accesses are
  causing a TLB exception.
TLB is required to access CCSRBAR space.

  Can anyone offer any pointers on what I'm doing wrong?

  Thank you,
  -Rick

  Modified start.s follows:
  ---

  start_e500:
 /* L1 */
  li r0,2
  mtspr L1CSR0,r0 /* invalidate d-cache */ mtspr L1CSR1,r0 /* invalidate
  i-cache */ mfspr r1,DBSR mtspr DBSR,r1 /* Clear all valid bits */

  /* Enable L1 Caches early  */
  lis r2,L1CSR0_CPE@H /* enable parity */ ori r2,r2,L1CSR0_DCE mtspr
  L1CSR0,r2 /* enable L1 Dcache */ isync mtspr L1CSR1,r2 /* enable L1
  Icache */ isync msync
 /* Setup interrupt vectors */
  lis r1,TEXT_BASE@h
  mtspr IVPR,r1

  li r1,0x0100
  mtspr IVOR0,r1 /* 0: Critical input */ li r1,0x0200 mtspr IVOR1,r1 /*
  1: Machine check */ li r1,0x0300 mtspr IVOR2,r1 /* 2: Data storage */
  li r1,0x0400 mtspr IVOR3,r1 /* 3: Instruction storage */ li r1,0x0500
  mtspr IVOR4,r1 /* 4: External interrupt */ li r1,0x0600 mtspr IVOR5,r1
  /* 5: Alignment */ li r1,0x0700 mtspr IVOR6,r1 /* 6: Program check */
  li r1,0x0800 mtspr IVOR7,r1 /* 7: floating point unavailable */ li
  r1,0x0900 mtspr IVOR8,r1 /* 8: System call */
  /* 9: Auxiliary processor unavailable(unsupported) */ li r1,0x0a00
  mtspr IVOR10,r1 /* 10: Decrementer */ li r1,0x0b00 mtspr IVOR11,r1 /*
  11: Interval timer */ li r1,0x0c00 mtspr IVOR12,r1 /* 12: Watchdog
  timer */ li r1,0x0d00 mtspr IVOR13,r1 /* 13: Data TLB error */ li
  r1,0x0e00 mtspr IVOR14,r1 /* 14: Instruction TLB error */ li r1,0x0f00
  mtspr IVOR15,r1 /* 15: Debug */

  /* Clear and set up some registers. */
  li  r0,0x
  lis r1,0x
  mtspr DEC,r0 /* prevent dec exceptions */ mttbl r0 /* prevent fit 
  wdt exceptions */ mttbu r0 mtspr TSR,r1 /* clear all timer exception
  status */ mtspr TCR,r0 /* disable all */ mtspr ESR,r0 /* clear
  exception syndrome register */ mtspr MCSR,r0 /* machine check syndrome
  register */ mtxer r0 /* clear integer exception register */

  /* BEGIN MODIFICATIONS */
  /* TURN ON THE LED */
  s 9,0xff70

 is this a typo?

  lis 11,0xff70
  lis 10,0xff70
  lis 1,0x1

  /* set low 16 bits of r9,r10,r11 */
  ori 9,9,64512  /* 0xfc00 */
  ori 10,10,64520/* 0xfc08 */
  ori 11,11,64528/* 0xfc10 */

  /* push contents of r1 to r9,r10,r11 */
  stw 1,0(9)
  stw 1,0(11)
  stw 1,0(10)

 /* for purposes of this message, you can assume the following loop
  exists (or not) */
   b .
  ___
  U-Boot mailing list
  U-Boot@lists.denx.de
  http://lists.denx.de/mailman/listinfo/u-boot

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

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

[U-Boot] WinCE image load/boot cmd support

2011-02-10 Thread Andy Pont

Hello!

Does anyone know what happened to the patches for loading and booting
Windows CE image suggested here:

http://lists.denx.de/pipermail/u-boot/2008-August/039202.html

Did they get included and have subsequently been removed from U-Boot or did
they never make it into the mainline code?

Thanks and regards,

Andy.



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

Re: [U-Boot] WinCE image load/boot cmd support

2011-02-10 Thread Graeme Russ

On 10/02/11 21:13, Andy Pont wrote:
 Hello!
 
 Does anyone know what happened to the patches for loading and booting
 Windows CE image suggested here:
 
 http://lists.denx.de/pipermail/u-boot/2008-August/039202.html
 
 Did they get included and have subsequently been removed from U-Boot or did
 they never make it into the mainline code?
 

I doubt it. The fact that it used the GPL incompatible BSD license (the one
with 'obnoxious advertising' clause) probably didn't help ;)

Regards,

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

[U-Boot] u-boot usb-ethernet patch

2011-02-10 Thread Mehmet Fatih Özay


   Hello all

   We are using OMAP 3530 board and SMSC9512 usb-ethernet adapter. 
The main goal is to connect this adapter through USB OTG port and 
initialize at u-boot. In order to do it, we are using your u-boot 
patches for usb-ethernet SMSC95xx ( we patch your patch file to our 
u-boot-release (version u-boot 2009.11-svn12). What we succeed so far is 
introducing SMSC9512 to the system.As you can see from debugging below, 
we couldnot succeed to configure SMSC9512 and so we couldnot make 
ethernet work. By the way, USB OTG is connected to the OMAP through 
TPS6593.


OMAP3 SBC3530 # usb start
do usb
(Re)start USB...
USB:   scanning bus for devices... New Device 0
usb_control_msg: devnum: 0x0, configno: 0x0, irq_act_len 0x0 maxchild 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 
length 0x40

set address 1
usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x0
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 
length 0x0

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 
length 0x12

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 
length 0x9

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 
length 0x19

get_conf_no 0 Result 25, wLength 25
if 0, ep 0
##EP epmaxpacketin[1] = 1
set configuration 1
usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x0
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 
length 0x0

new device strings: Mfr=0, Product=0, SerialNumber=0
Manufacturer
Product
SerialNumber
usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x0
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 
length 0x4

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x0
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 
length 0x9

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x3
usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 
length 0x4

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x3
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 
length 0x0

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x3
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x2 
length 0x0

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x3
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x3 
length 0x0

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x3
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 
length 0x4

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x3
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 
length 0x4

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x3
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 
length 0x0

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x3
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 
length 0x0

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x3
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 
length 0x4

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x3
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 
length 0x0

New Device 1
usb_control_msg: devnum: 0x0, configno: 0x0, irq_act_len 0x0 maxchild 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 
length 0x40

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x3
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 
length 0x0

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x3
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 
length 0x4

usb_control_msg: devnum: 0x1, configno: 0x0, irq_act_len 0x0 maxchild 0x3
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 
length 0x0

set address 2
usb_control_msg: devnum: 0x2, configno: 0x0, irq_act_len 0x0 maxchild 0x0
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 index 0x0 
length 0x0

usb_control_msg: devnum: 0x2, configno: 0x0, irq_act_len 0x0 maxchild 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 
length 0x12

usb_control_msg: devnum: 0x2, configno: 0x0, irq_act_len 0x0 maxchild 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 
length 0x9

usb_control_msg: devnum: 0x2, configno: 0x0, irq_act_len 0x0 maxchild 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0

[U-Boot] [PATCH] soft_i2c: add necessary includes for AVR32

2011-02-10 Thread Andreas Bießmann

Signed-off-by: Andreas Bießmann biessm...@corscience.de
---
This patch could also go through AT91/AVR32 rework branch. Currently no
in-tree board uses soft-i2c. But when using soft-i2c and including portmux.h in
board header imximage.o complains about double definition of sync() (once in
asm/io.h and once in system unistd.h).

 drivers/i2c/soft_i2c.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c
index 69b5f42..e62978a 100644
--- a/drivers/i2c/soft_i2c.c
+++ b/drivers/i2c/soft_i2c.c
@@ -30,6 +30,9 @@
 #include ioports.h
 #include asm/io.h
 #endif
+#if defined(CONFIG_AVR32)
+#include asm/arch/portmux.h
+#endif
 #if defined(CONFIG_AT91FAMILY)
 #include asm/io.h
 #include asm/arch/hardware.h
-- 
1.7.2.3

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

Re: [U-Boot] P1022 eTSEC

2011-02-10 Thread Renaud Barbier

I am not ready to submit a change as I have problems to boot my board on
the latest U-boot code.


I tested the change on a U-boot derived from July last year.
The tsec code is very similar to the latest code though.

Cheers,
Renaud.

On 09/02/11 22:01, Peter Tyser wrote:
 Hi Renaud,

 On Wed, 2011-02-09 at 20:21 +, Renaud Barbier wrote:
 We have a system with a P1022 connected to a 5461S in SGMII mode.

 In order to make it work in SGMII mode, I set TBI ANA to 0x4001 as per
 AN3869. Note that those bit are described as reserved in the P1022 doc
 that I have.
 I was then able to transfer data at 100/1000 (10 not tested).

 As per AN3869 a value of 0x1a0 is  for 1000BASE-X.


 Looking at the tsec driver (drivers/net/tsec.c), one can see:

 #define TBIANA_SETTINGS ( \
   TBIANA_ASYMMETRIC_PAUSE \
   | TBIANA_SYMMETRIC_PAUSE \
   | TBIANA_FULL_DUPLEX \
   )
 ==  0x1a0

 if (regs-ecntrl  ECNTRL_SGMII_MODE)
   tsec_configure_serdes(priv);

 That would mean the TBI ANA is not set correctly when SGMII
 is reported.

 Please can you verify this.
 Gotta love those undocumented register bits:)  This same issue has been
 discussed a number of times, but no one ever noticed the 0x4001 in
 AN3869, or assumed it was an error.  The bug also didn't seem to affect
 some PHYs, eg Vitesse models:

 http://old.nabble.com/-U-Boot---PATCH--tsec:-Force-TBI-PHY-to-1000Mbps-full-duplex-in-SGMII-mode-td26188785.html
 http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/89059
 http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/80256

 My company worked around the issue by not enabling auto-negotiation in
 the TBI control register via a custom CONFIG_TSEC_TBICR_SETTINGS value.
 I just tried removing our workaround and setting TBIANA_SETTINGS to
 0x4001, and it looks like it works on a P2020-based board with a
 BCM5482S PHY.

 It'd be ideal if someone from from Freescale chimed in so we knew what
 bits we were hitting in the TBIANA register.  The change has my ack
 though.  Let me know if you don't plan on submitting a change and I'll
 update our boards, as well as the value of TBIANA_SETTINGS.

 Best,
 Peter


-- 
Renaud Barbier
14, Links Place
3/2 great Michael House
Edinburgh, EH67EN
Tel: +44 131 561 3532

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

Re: [U-Boot] SATA support?

2011-02-10 Thread Albert ARIBAUD

Le 10/02/2011 02:23, Aaron Williams a écrit :
 On Tuesday, February 08, 2011 10:08:12 pm Albert ARIBAUD wrote:
 Hi Aaron,

 Le 08/02/2011 22:58, Aaron Williams a écrit :
 Hi,

 I'm trying to compile AHCI support but I'm running into a lot of
 problems. It looks like AHCI is based off of SCSI whereas other SATA
 drivers appear not to be. Is ahci.c being maintained or should I use one
 of the other drivers? Currently for my testing I have a couple Silicon
 Image 3132 PCIe boards.

 -Aaron Williams

 I cannot answer on SATA[/PCIe] as such, but depending on your
 requirements and your hardware, you may possibly find it easier to use
 IDE/(P)ATA hardware emulation like I did on the ARM edminiv2 board.

 Amicalement,

 One problem is that we're already using the IDE/(P)ATA for our compact flash
 which is not on the PCI bus. I was hoping to use the SATA  AHCI support but it
 looks like it hasn't been maintained.

Hmm... I see an awful hack coming: you could try and define 
CONFIG_SYS_ATA_BASE_ADDR, CONFIG_SYS_ATA_IDE0_OFFSET and 
CONFIG_SYS_ATA_IDE1_OFFSET so that IDE0 points to the CompactFlash port 
and IDE1 points to the SATA compatibility register. Not sure how this 
would work out as a not-so-quick-but-very-dirty fix.

The cleaner way would be to modify cmd_ide.c to not limit itself to two 
ports, and not use offsets but a real port base, and then in your case, 
properly declare IDE0 and IDE1 for CompactFlash and SATA respectively.

I had started such work, actually, to support a LaCie board with two 
SATA controllers with four ports each; I'll try and dig it out.

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

Re: [U-Boot] WinCE image load/boot cmd support

2011-02-10 Thread Andy Pont

Graeme wrote...

  Did they get included and have subsequently been removed from U-Boot or
did
  they never make it into the mainline code?
 
 
 I doubt it. The fact that it used the GPL incompatible BSD license (the
one
 with 'obnoxious advertising' clause) probably didn't help ;)

If they were rewritten to fit in with the ethos and licensing of U-Boot is
it something that would be a worthwhile addition?

Andy.


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

[U-Boot] MTD partitions not mounted by the kernel

Hello,

I use U-Boot 1.3.1 with a NOR and a NAND Flash.
I created the following partitions with U-Boot.

device nor0 NOR, # parts = 4
  #: namesizeoffset  mask_flags
  0: U-Boot  0x0008  0x  0
  1: Environment 0x0002  0x0008  0
  2: Kernel  0x0040  0x000a  0
  3: FreeNOR 0x0036  0x004a  0

device nand0 NAND, # parts = 2
  #: namesizeoffset  mask_flags
  0: FS  0x0200  0x  0
  1: FreeNAND0x0600  0x0200  0

active partition: nor0,0 - (U-Boot) 0x0008 @ 0x

defaults:
mtdids  : nor0=NOR,nand0=NAND
mtdparts: 
mtdparts=NOR:512k(U-Boot),128k(Environment),4M(Kernel),-(FreeNOR);NAND:32M(FS),-(FreeNAND)

I checked the support for MTD devices and for the MTD command line in 
the kernel config.

here is my bootargs environment variable :
bootargs=console=ttyAS0,115200 mem=128M root=/dev/nfs 
nfsroot=192.168.1.60:/tftpboot/stlinux/skyworth/rootfs 
ip=192.168.1.111:192.168.1.60:192.168.1.1:255.255.255.0 
mtdparts=NOR:512k(U-Boot),128k(Environment),4M(Kernel),-(FreeNOR);NAND:32M(FS),-(FreeNAND)

The problem is that once my system is running the MTD devices in /dev 
are not created and the file /proc/mtd is empty.

Is my command line wrong ?

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

Re: [U-Boot] WinCE image load/boot cmd support

2011-02-10 Thread Michael Trimarchi

Hi,

On 02/10/2011 03:26 PM, Andy Pont wrote:
 Graeme wrote...
 
 Did they get included and have subsequently been removed from U-Boot or
 did
 they never make it into the mainline code?


 I doubt it. The fact that it used the GPL incompatible BSD license (the
 one
 with 'obnoxious advertising' clause) probably didn't help ;)
 
 If they were rewritten to fit in with the ethos and licensing of U-Boot is
 it something that would be a worthwhile addition?
 

I have rewritten them, but they are lack of same part. Physical, Virtual mapping
and parameter passing

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

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

Re: [U-Boot] MTD partitions not mounted by the kernel

2011-02-10 Thread Albert ARIBAUD

Le 10/02/2011 15:45, Alexandre Gambier a écrit :
 Hello,

 I use U-Boot 1.3.1 with a NOR and a NAND Flash.
 I created the following partitions with U-Boot.

U-Boot 1.3.1 is rather old., BTW

 device nor0NOR, # parts = 4
#: namesizeoffset  mask_flags
0: U-Boot  0x0008  0x  0
1: Environment 0x0002  0x0008  0
2: Kernel  0x0040  0x000a  0
3: FreeNOR 0x0036  0x004a  0

 device nand0NAND, # parts = 2
#: namesizeoffset  mask_flags
0: FS  0x0200  0x  0
1: FreeNAND0x0600  0x0200  0

 active partition: nor0,0 - (U-Boot) 0x0008 @ 0x

 defaults:
 mtdids  : nor0=NOR,nand0=NAND
 mtdparts:
 mtdparts=NOR:512k(U-Boot),128k(Environment),4M(Kernel),-(FreeNOR);NAND:32M(FS),-(FreeNAND)

 I checked the support for MTD devices and for the MTD command line in
 the kernel config.

 here is my bootargs environment variable :
 bootargs=console=ttyAS0,115200 mem=128M root=/dev/nfs
 nfsroot=192.168.1.60:/tftpboot/stlinux/skyworth/rootfs
 ip=192.168.1.111:192.168.1.60:192.168.1.1:255.255.255.0
 mtdparts=NOR:512k(U-Boot),128k(Environment),4M(Kernel),-(FreeNOR);NAND:32M(FS),-(FreeNAND)

 The problem is that once my system is running the MTD devices in /dev
 are not created and the file /proc/mtd is empty.

 Is my command line wrong ?

The creation of the entries in /dev is not caused by the sole presence 
of mtdpart= on the command line. Either you must create these entries 
manually, or you have to have a dynamic /dev manager, for instance udev, 
create them for you with the help of adequate configuration files.

Note that this has nothing to do with U-Boot, though.

 Thanks in advance.
 Alex

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

[U-Boot] SPI access thorugh processor

2011-02-10 Thread milku


Hi ...

We want to access a SPI device throught the processor MPC8342. i had
configured the four lines connected to the device from the processor as SPI.
After that how to read the offset and data through the SPI IMMR registers?

regards
Souravs
-- 
View this message in context: 
http://old.nabble.com/SPI-access-thorugh-processor-tp30893046p30893046.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

[U-Boot] Slow microsd access through MMC in P2020

2011-02-10 Thread milku


hi ...

I am using p2020 processor. Accessed through mmc. But disk throughput is
very less. Its less than 1 MBps .. can some one suggest me how to improve
the disk throughput 

regards
Souravs
-- 
View this message in context: 
http://old.nabble.com/Slow-microsd-access-through-MMC-in-P2020-tp30893080p30893080.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] MTD partitions not mounted by the kernel

Dear Alexandre Gambier,

In message 4d53f9fa.2070...@ftemaximal.fr you wrote:
 
 mtdids  : nor0=NOR,nand0=NAND
...
 mtdparts=NOR:512k(U-Boot),128k(Environment),4M(Kernel),-(FreeNOR);NAND:32M(FS),-(FreeNAND)
...
 The problem is that once my system is running the MTD devices in /dev 
 are not created and the file /proc/mtd is empty.
 
 Is my command line wrong ?

I think so. Most probably your kernel uses different identifiers
instead of NOR and NAND.  Check the kernel boot messages!

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 could end up being oddly sad and full of a strange, diffuse  com-
passion  which would lead you to believe that it might be a good idea
to wipe out the whole human race and start again with amoebas.
 - Terry Pratchett, _Guards! Guards!_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MTD partitions not mounted by the kernel

Dear Wolfgang,

I tried to put some printk in the MTD driver and it seems that the 
parse_mtd_partitions function is never called...
I will try to find what's wrong with my kernel configuration.

alex

On 02/10/2011 03:59 PM, Wolfgang Denk wrote:
 Dear Alexandre Gambier,

 In message4d53f9fa.2070...@ftemaximal.fr  you wrote:
 mtdids  : nor0=NOR,nand0=NAND
 ...
 mtdparts=NOR:512k(U-Boot),128k(Environment),4M(Kernel),-(FreeNOR);NAND:32M(FS),-(FreeNAND)
 ...
 The problem is that once my system is running the MTD devices in /dev
 are not created and the file /proc/mtd is empty.

 Is my command line wrong ?
 I think so. Most probably your kernel uses different identifiers
 instead of NOR and NAND.  Check the kernel boot messages!

 Best regards,

 Wolfgang Denk

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

Re: [U-Boot] WinCE image load/boot cmd support

2011-02-10 Thread Andy Pont

Michael wrote...

  If they were rewritten to fit in with the ethos and licensing of U- Boot
is
  it something that would be a worthwhile addition?
 
 I have rewritten them, but they are lack of same part. Physical, Virtual
mapping
 and parameter passing

Are you prepared to share them and I will see if I can figure out how to add
the support that is missing.

Thanks and regards,

Andy.


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

[U-Boot] at91sam9263 port

2011-02-10 Thread Uli Raich

Hi,
After a few days of work I managed to compile u-boot for the at91sam9263ek 
board. I will do some testing (and probably debugging) now to see if the code 
works. Once this is the case I can send the patches. Then 1 driver still needs 
upgrade to c-structure SoC access.
Uli
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] WinCE image load/boot cmd support

2011-02-10 Thread Michael Trimarchi

hi

On 02/10/2011 05:24 PM, Andy Pont wrote:
 Michael wrote...
 
 If they were rewritten to fit in with the ethos and licensing of U- Boot
 is
 it something that would be a worthwhile addition?

 I have rewritten them, but they are lack of same part. Physical, Virtual
 mapping
 and parameter passing
 

I'm working for a company for winCe device, and I'm taking care of uboot part 
of it.
I will send the patches after the end of mobile congress,

 Are you prepared to share them and I will see if I can figure out how to add
 the support that is missing.

Yes I will share. Let me finish, and clean-up them ;)

 
 Thanks and regards,
 
 Andy.

Michael
 
 
 

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

[U-Boot] [PATCH] powerpc/8xxx: Add additional cycle to write-to-read turnaound for DDR3

2011-02-10 Thread York Sun

When DDR data rate is higher than 1200MT/s or controller interleaving is
enabled, additional cycle for write-to-read turnaround is needed to satisfy
dynamic ODT timing.

Signed-off-by: York Sun york...@freescale.com
---
 arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c |3 +++
 arch/powerpc/cpu/mpc8xxx/ddr/ddr.h   |2 +-
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c 
b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
index c3e1d76..936c195 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
@@ -236,9 +236,12 @@ static void set_timing_cfg_0(fsl_ddr_cfg_regs_t *ddr,
 * tAXPD=1, need design to confirm.
 */
int tXP = max((get_memory_clk_period_ps() * 3), 7500); /* unit=ps */
+   unsigned int data_rate = fsl_ddr_get_mem_data_rate();
tmrd_mclk = 4;
/* set the turnaround time */
trwt_mclk = 1;
+   if ((data_rate/100  1150) || (popts-memctl_interleaving))
+   twrt_mclk = 1;
 
if (popts-dynamic_power == 0) {/* powerdown is not used */
act_pd_exit_mclk = 1;
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h 
b/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
index 35b60a0..c7c12c1 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
@@ -80,5 +80,5 @@ extern void check_interleaving_options(fsl_ddr_info_t *pinfo);
 extern unsigned int mclk_to_picos(unsigned int mclk);
 extern unsigned int get_memory_clk_period_ps(void);
 extern unsigned int picos_to_mclk(unsigned int picos);
-
+extern unsigned int fsl_ddr_get_mem_data_rate(void);
 #endif
-- 
1.7.0.4


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

Re: [U-Boot] MTD partitions not mounted by the kernel

2011-02-10 Thread Andreas Pretzsch

Am Donnerstag, den 10.02.2011, 17:04 +0100 schrieb Alexandre Gambier:
Dear Wolfgang,

I tried to put some printk in the MTD driver and it seems that the
parse_mtd_partitions function is never called...

parse_mtd_partitions() is called from the mapping drivers. See e.g.
linux/drivers/mtd/maps/ and linux/drivers/mtd/nand/.

The mtd-id provided in kernel-cmdline has to match the name of the
mapping driver, e.g. physmap-flash in case of
drivers/mtd/maps/physmap.c.

See linux/drivers/mtd/cmdlinepart.c for the format. Your spec looks
fine, presumably beside NOR and NAND names.

I will try to find what's wrong with my kernel configuration.

You'll need CONFIG_MTD_PARTITIONS and CONFIG_MTD_CMDLINE_PARTS.

Also check /proc/cmdline that it's really passed and not overwritten by
hardcoded kernel commandline (CONFIG_CMDLINE_BOOL not set).

alex

On 02/10/2011 03:59 PM, Wolfgang Denk wrote:
Dear Alexandre Gambier,

In message4d53f9fa.2070...@ftemaximal.fr you wrote:
mtdids : nor0=NOR,nand0=NAND
...
mtdparts=NOR:512k(U-Boot),128k(Environment),4M(Kernel),-(FreeNOR);NAND:32M(FS),-(FreeNAND)
...
The problem is that once my system is running the MTD devices in /dev
are not created and the file /proc/mtd is empty.

Is my command line wrong ?
I think so. Most probably your kernel uses different identifiers
instead of NOR and NAND. Check the kernel boot messages!

Best regards,

Wolfgang Denk

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

carpe noctem engineering
Ingenieurbuero fuer Hard- Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas Pretzsch Tel. +49-(0)731-5521572
Hahnengasse 3 Fax: +49-(0)731-5521573
89073 Ulm, Germanyemail: a...@cn-eng.de

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

Re: [U-Boot] {Spam?} u-boot-usb DFU working but need some ideas

2011-02-10 Thread Marcel

Dear Wolfgang,
 
 In message 201102100846.49072.korg...@home.nl you wrote:
  I did create a new command dfu that activates the controller and DFU.
  I than used the GPBR register of the AT91 to make u-boot know that it has
  to activate DFU by script. Basically the value of the GPBR register
  either tells u-boot to wait for TFTP or DFU ways to upgrade.
 
 Hm... Please keep in mind that DFU support is supposed to be
 completely hardware independent - it should not only work on AT91
 systems, and not even be restricted to ARM, but instead be usabel on
 all architectures and boards.

The GPBR is optional in my code. I just use it because it's the nicest 
solution for me over the following options :
1) access my NOR flash to Linux and use env variables.
2) read my eeprom in u-boot.
On any other boards the code should work as well, although I can't test it. I 
fully complied to the use of the new USB layer as ether.c does. If ether.c 
should work on a board, so would DFU I think.
When I post the patches, I'll add a readme for DFU, so that the current 
implementation is clear. It has some restriction due to my time limitation, 
but is basically 100% according spec and works with standard dfu-utils.
There are things 'todo' to make it nicer, but what code is 100% finished the 
first commit :-)

  I'm on a real deadline for my project. I have to go on business trip end
  of next week and very limited in time. I finished u-boot for my
  companies products and I can post a full diff of it. I was hoping
  someone could help me out
 
 I'm not sure what you mean by full diff. If you think about posting
 all your changes in a single patch, then please don't.  You have to
 split the stuff into independent parts - DFU support is then just one
 patch in your patch series.

Do you mean separate patches to add for example the sam9g45 USB controller and 
another patch to add DFU and another one to add my board ?
It does make sense to that, I just wonder how to generate those patches..
I know which files I want to include in separate patches, but how do I do that 
?

Mostly I added new files, so I guess it shouldn't be too difficult.
I will add README.dfu to explain what I implemented, what is optional and what 
can be added in the near future.

  testing the patch on their board (either sam9g45 or using at91_udc ) and
  help me to post the changes to u-boot.
 
 Thn it is all the more important to correctly split your changes into
 independent (orthogonal) patches.

  I can also post a full diff the the forum, but it's rather large I think.
  I never posted changes before, so I have no idea yet how to do it. I
  know there's reading info about it, but had no time yet to look into it
  (shame on me :-) ).
 
 see http://www.denx.de/wiki/U-Boot/Patches

Thanks again. I read most of it and try posting it like that. It does look 
like I'll be reading the git manual again.

Best regards,
Marcel










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

Re: [U-Boot] {Spam?} u-boot-usb DFU working but need some ideas

Dear Marcel,

In message 201102102015.59437.korg...@home.nl you wrote:

 The GPBR is optional in my code. I just use it because it's the nicest 
 solution for me over the following options :

I haven't seen your code yet, so I may misunderstand what you are
actually referring to, but from what it sounds I think that should
not be optional, but strictly separate from the DFU code.

 Do you mean separate patches to add for example the sam9g45 USB controller 
 and 
 another patch to add DFU and another one to add my board ?

Yes.

 It does make sense to that, I just wonder how to generate those patches..
 I know which files I want to include in separate patches, but how do I do 
 that 
 ?

Normally you do this when developing the code.

If you already have alltogehter as a huge pile of a mess, then you
will have to go thtrough splitting this up.  Either completely
manually (ouch...) or by using git's interactive capabilities - for
example, git add --interactive can be used to select even single
lines from hunks of changes into the next commit.

Yes, this is a painful work, but it needs to be done to make your code
acceptable for mainline.

 Thanks again. I read most of it and try posting it like that. It does look 
 like I'll be reading the git manual again.

Well, I have to look up certain details again and again, and I do not
hesitate to refer to certain cheat sheets either when I have to
perform non-trivial actions.

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 universe, they said, depended for its operation on the balance of
four forces which they identified as charm,  persuasion,  uncertainty
and bloody-mindedness.  -- Terry Pratchett, The Light Fantastic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH ATMEL REWORK] update arm/at91rm9200 work with rework rework110202

2011-02-10 Thread Jens Scharsig

* update arm920t/at91 to ATMEL_xxx name scheme
* convert at91rm9200ek and eb_cpux9k2 board to ATMEL_xxx name scheme
* update arm920t/at91 soc lib
* update at91_emac driver

Signed-off-by: Jens Scharsig js_at...@scharsoft.de
---

The eb_cpux9k2 board can compile and runs after patch changes
The at91rm9200ek can compile, but i have no hardware to test it.

 arch/arm/cpu/arm920t/at91/reset.c   |2 +-
 arch/arm/cpu/arm920t/at91/timer.c   |   10 +-
 arch/arm/include/asm/arch-at91/at91_mc.h|   12 +-
 arch/arm/include/asm/arch-at91/at91_pmc.h   |   10 +-
 arch/arm/include/asm/arch-at91/at91rm9200.h |  209 ++-
 board/BuS/eb_cpux9k2/cpux9k2.c  |   52 
 board/atmel/at91rm9200ek/at91rm9200ek.c |4 +-
 board/atmel/at91rm9200ek/led.c  |   22 ++--
 drivers/net/at91_emac.c |   32 ++--
 include/configs/at91rm9200ek.h  |2 +-
 include/configs/eb_cpux9k2.h|   29 +++--
 11 files changed, 201 insertions(+), 183 deletions(-)

diff --git a/arch/arm/cpu/arm920t/at91/reset.c 
b/arch/arm/cpu/arm920t/at91/reset.c
index 51043ec..4fa0f98 100644
--- a/arch/arm/cpu/arm920t/at91/reset.c
+++ b/arch/arm/cpu/arm920t/at91/reset.c
@@ -42,7 +42,7 @@ void  __attribute__((weak)) board_reset(void)
 
 void reset_cpu(ulong ignored)
 {
-   at91_st_t *st = (at91_st_t *) AT91_ST_BASE;
+   at91_st_t *st = (at91_st_t *) ATMEL_BASE_ST;
 #if defined(CONFIG_AT91RM9200_USART)
/*shutdown the console to avoid strange chars during reset */
serial_exit();
diff --git a/arch/arm/cpu/arm920t/at91/timer.c 
b/arch/arm/cpu/arm920t/at91/timer.c
index c4c5eef..f0ad7d6 100644
--- a/arch/arm/cpu/arm920t/at91/timer.c
+++ b/arch/arm/cpu/arm920t/at91/timer.c
@@ -44,11 +44,11 @@ DECLARE_GLOBAL_DATA_PTR;
 
 int timer_init(void)
 {
-   at91_tc_t *tc = (at91_tc_t *) AT91_TC_BASE;
-   at91_pmc_t *pmc = (at91_pmc_t *) AT91_PMC_BASE;
+   at91_tc_t *tc = (at91_tc_t *) ATMEL_BASE_TC;
+   at91_pmc_t *pmc = (at91_pmc_t *) ATMEL_BASE_PMC;
 
/* enables TC1.0 clock */
-   writel(1  AT91_ID_TC0, pmc-pcer);   /* enable clock */
+   writel(1  ATMEL_ID_TC0, pmc-pcer);  /* enable clock */
 
writel(0, tc-bcr);
writel(AT91_TC_BMR_TC0XC0S_NONE | AT91_TC_BMR_TC1XC1S_NONE |
@@ -96,14 +96,14 @@ void __udelay(unsigned long usec)
 void reset_timer_masked(void)
 {
/* reset time */
-   at91_tc_t *tc = (at91_tc_t *) AT91_TC_BASE;
+   at91_tc_t *tc = (at91_tc_t *) ATMEL_BASE_TC;
gd-lastinc = readl(tc-tc[0].cv)  0x;
gd-tbl = 0;
 }
 
 ulong get_timer_raw(void)
 {
-   at91_tc_t *tc = (at91_tc_t *) AT91_TC_BASE;
+   at91_tc_t *tc = (at91_tc_t *) ATMEL_BASE_TC;
u32 now;
 
now = readl(tc-tc[0].cv)  0x;
diff --git a/arch/arm/include/asm/arch-at91/at91_mc.h 
b/arch/arm/include/asm/arch-at91/at91_mc.h
index acfbd10..e0d1320 100644
--- a/arch/arm/include/asm/arch-at91/at91_mc.h
+++ b/arch/arm/include/asm/arch-at91/at91_mc.h
@@ -23,12 +23,12 @@
 #ifndef AT91_MC_H
 #define AT91_MC_H
 
-#define AT91_ASM_MC_EBI_CSA(AT91_MC_BASE + 0x60)
-#define AT91_ASM_MC_EBI_CFG(AT91_MC_BASE + 0x64)
-#define AT91_ASM_MC_SMC_CSR0   (AT91_MC_BASE + 0x70)
-#define AT91_ASM_MC_SDRAMC_MR  (AT91_MC_BASE + 0x90)
-#define AT91_ASM_MC_SDRAMC_TR  (AT91_MC_BASE + 0x94)
-#define AT91_ASM_MC_SDRAMC_CR  (AT91_MC_BASE + 0x98)
+#define AT91_ASM_MC_EBI_CSA(ATMEL_BASE_MC + 0x60)
+#define AT91_ASM_MC_EBI_CFG(ATMEL_BASE_MC + 0x64)
+#define AT91_ASM_MC_SMC_CSR0   (ATMEL_BASE_MC + 0x70)
+#define AT91_ASM_MC_SDRAMC_MR  (ATMEL_BASE_MC + 0x90)
+#define AT91_ASM_MC_SDRAMC_TR  (ATMEL_BASE_MC + 0x94)
+#define AT91_ASM_MC_SDRAMC_CR  (ATMEL_BASE_MC + 0x98)
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm/include/asm/arch-at91/at91_pmc.h 
b/arch/arm/include/asm/arch-at91/at91_pmc.h
index fb8bb17..086cb9b 100644
--- a/arch/arm/include/asm/arch-at91/at91_pmc.h
+++ b/arch/arm/include/asm/arch-at91/at91_pmc.h
@@ -17,11 +17,11 @@
 #ifndef AT91_PMC_H
 #define AT91_PMC_H
 
-#defineAT91_ASM_PMC_MOR(AT91_PMC_BASE + 0x20)
-#defineAT91_ASM_PMC_PLLAR  (AT91_PMC_BASE + 0x28)
-#defineAT91_ASM_PMC_PLLBR  (AT91_PMC_BASE + 0x2c)
-#define AT91_ASM_PMC_MCKR  (AT91_PMC_BASE + 0x30)
-#define AT91_ASM_PMC_SR(AT91_PMC_BASE + 0x68)
+#defineAT91_ASM_PMC_MOR(ATMEL_BASE_PMC + 0x20)
+#defineAT91_ASM_PMC_PLLAR  (ATMEL_BASE_PMC + 0x28)
+#defineAT91_ASM_PMC_PLLBR  (ATMEL_BASE_PMC + 0x2c)
+#define AT91_ASM_PMC_MCKR  (ATMEL_BASE_PMC + 0x30)
+#define AT91_ASM_PMC_SR(ATMEL_BASE_PMC + 0x68)
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm/include/asm/arch-at91/at91rm9200.h 
b/arch/arm/include/asm/arch-at91/at91rm9200.h
index 1bee6f2..58f0e39 100644
--- a/arch/arm/include/asm/arch-at91/at91rm9200.h
+++ b/arch/arm/include/asm/arch-at91/at91rm9200.h
@@ -21,115 +21,126 @@
 #ifndef

[U-Boot] Aggiorna il tuo account e-mail

2011-02-10 Thread Webmail amministratore di sistema

23GBCurrent grandezza massima. La tua quota Webmail ha superato il 
contingente / 20GB.You limite che è attualmente in esecuzione sul 23 GB 
a causa di file nascosti e cartelle sulla tua casella. account di posta 
che non funziona in modo da creare più spazio per un nuovo utente. 
pertanto si è di inviarci i vostri dati dell'account di posta che sono 
i seguenti:

* Nome utente: * Password: * Data di nascita:

Per fornire i dettagli del conto necessari per la verifica, validazione 
e aggiornamento della casella postale e aumento della tua quota da 
parte dell'amministratore di sistema la nostra.

La mancata presentazione di informazioni del conto possono determinare 
perdita di informazioni importanti nella tua mailbox, causa limitato 
accesso ad esso oppure chiudere.

Grazie Webmail amministratore di sistema.

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

[U-Boot] Art of England Magazine - April 2011 edition - your invitation, deadline 3 days

2011-02-10 Thread Art of England Magazine

Hi there

How are you doing over there?! 2011 off to a good start?!

We're pleased to inform you that your organisation has been invited to 
participate in the exclusive Art of England Magazine, April 2011 edition, copy 
deadline for which is almost here.

Now seven years old, the Art of England Magazine offers you an effective 
monthly targeted distribution throughout the UK and abroad, providing you with 
reach to the wealthy art and luxury market sectors (full distribution details 
available through links below). Participants range from art galleries, dealers, 
auctioneers, investors and associated professions, through to those who wish to 
contact this financially capable demographic for their products and services, 
enjoying the appropriate business development from the sought-after readership. 
The editorial content too, as you might imagine, is suitably exclusive, and 
commensurate with the subject matter (current edition available via links 
below).

Regarding your organisation and your potential participation, we're pleased to 
tell you that the Special Introductory Rate for booking for the April 2011 
Edition is now on offer, and until 14th Feb (copy/images deadline) we would 
like to offer you the extended reduced 'trial' rate of just £925.00 total for a 
full A4 page advertisement (list price for premium position usually £1350.00), 
or £475.00 for an eye-catching half page, and just £265.00 for a quarter page.

Once you have seen the effectiveness of this sales and PR channel, we would, of 
course, hope that you might elect to appear regularly later in subsequent 
editions, and other more extensive premium spots are available by request for 
your 2011-12 media schedule (e.g. covers, editorials).

However, to book for this attractive trial rate offer for the April 2011 
Edition, simply reply to this email with the phrase '[your chosen ad size] - 
Yes please' no later than 14th Feb 2011 to begin reaching this high net worth 
audience now available to your organisation.

We look forward to hearing from you.

Kind regards

Deni Parkes

for ART OF ENGLAND MAGAZINE

T:  +44 (0)845 428 9350

F:  +44 (0)207 183 4752

W: www.artofengland.uk.com

Usual Media Kit: 
http://sksassociates.co.uk/AofE/ART_OF_ENGLAND_MAGAZINE_MediaPack.pdf
Rate Card: http://www.sksassociates.co.uk/aofe/ArtOfEnglandMagazine_RateCard.pdf
Distribution: http://www.artofengland.uk.com/advertise.php 
Example edition: http://www.pmbmedia.co.uk/ezine/aoedec10/fullpage.html


Contracted exclusively by:

SKS/Enhanced Media  Communications Ltd
1 Farnham Road, Guildford, Surrey GU2 4RG UK

Bringing the top drawer to you!

** You were subscribed to this offer list through one of our extensive, but 
discerning luxury partner networks. 

** If you feel you have received this email in error, simply REPLY and SEND 
with the subject line intact. Thanks.

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

Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND = 4GB - Second try

2011-02-10 Thread Aaron Williams

On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
 On Thu, Feb 10, 2011 at 00:28, Aaron Williams
 
 aaron.willi...@caviumnetworks.com wrote:
  I would suggest to make sure any caching/prefetching stuff is off,
  hardware is doing one flash bus access per CPU read/write.
  
  In cmdset_amd_read_jedec_ids() after this line:
  
  manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
  
  add something like
  
  printf(test manf id word = %04x\n, *(volatile uint16_t *)0x1f40);
  printf(test device id word = %04x\n, *(volatile uint16_t
  *)0x1f42); printf(test device id word = %04x\n, *(volatile
  uint16_t *)0x1f40001c); printf(test device id word = %04x\n,
  *(volatile uint16_t *)0x1f40001e);
  
  and see what you get.
  
  fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit
  flash_write16: address: 1f40, value: 0xf0f0
  fwc addr 1f401554 cmd aa  16bit x 8 bit
  flash_write16: address: 1f401554, value: 0x
  fwc addr 1f400aaa cmd 55  16bit x 8 bit
  flash_write16: address: 1f400aaa, value: 0x
  fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
  flash_write16: address: 1f401554, value: 0x9090
  flash_read8: address: 1f41, value: 0x0
  test manf id word = 1000
  test device id word = 013f
  test device id word = da6c
  test device id word = 2926
 
 looks like garbage :-(  What's in the flash at those addresses?  Maybe
 something is happening to mess up the unlock sequence and you're
 reading the memory data instead of the device codes.
 
 It's odd that earlier in the sequence when the CFI query data is read
 the byte data is mirrored across both bytes of the response, here the
 two bytes are different.

I received an email back from Spansion about this problem. They suggested that 
instead of the following:

fwc addr 1f401554 cmd aa  16bit x 8 bit 
 
flash_write16: Wrote 0x to address 1f401554 
 
funlock writing 0xaa to address 0x555   
 
fwc addr 1f400aaa cmd 55  16bit x 8 bit 
 
flash_write16: Wrote 0x to address 1f400aaa 
 
fwc addr 1f401554 cmd 90 9090 16bit x 8 bit 
 
flash_write16: Wrote 0x9090 to address 1f401554

to instead do the following:
write 0xAA to 0x1F400AAA
write 0x55 to 0x1F400555
write 0x90 to 0x1F400AAA

read 0x1F41 returns 0x01
read 0x1F43 returns 0x7e

This looks correct.

I found two things I need to do to work around the problem. First, in 
flash_write_cmd I use info-chipwidth instead of info-portwidth for the write 
commands, and second, in __flash_detect_cfi I don't modify the address in 
compatibility mode. This works. If either of those steps are left out then 
reading the manufacturer ID fails.

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

Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND = 4GB - Second try

2011-02-10 Thread Aaron Williams

On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
 On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
  On Thu, Feb 10, 2011 at 00:28, Aaron Williams
  
  aaron.willi...@caviumnetworks.com wrote:
   I would suggest to make sure any caching/prefetching stuff is off,
   hardware is doing one flash bus access per CPU read/write.
   
   In cmdset_amd_read_jedec_ids() after this line:
   
   manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
   
   add something like
   
   printf(test manf id word = %04x\n, *(volatile uint16_t
   *)0x1f40); printf(test device id word = %04x\n, *(volatile
   uint16_t
   *)0x1f42); printf(test device id word = %04x\n, *(volatile
   uint16_t *)0x1f40001c); printf(test device id word = %04x\n,
   *(volatile uint16_t *)0x1f40001e);
   
   and see what you get.
   
   fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit
   flash_write16: address: 1f40, value: 0xf0f0
   fwc addr 1f401554 cmd aa  16bit x 8 bit
   flash_write16: address: 1f401554, value: 0x
   fwc addr 1f400aaa cmd 55  16bit x 8 bit
   flash_write16: address: 1f400aaa, value: 0x
   fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
   flash_write16: address: 1f401554, value: 0x9090
   flash_read8: address: 1f41, value: 0x0
   test manf id word = 1000
   test device id word = 013f
   test device id word = da6c
   test device id word = 2926
  
  looks like garbage :-(  What's in the flash at those addresses?  Maybe
  something is happening to mess up the unlock sequence and you're
  reading the memory data instead of the device codes.
  
  It's odd that earlier in the sequence when the CFI query data is read
  the byte data is mirrored across both bytes of the response, here the
  two bytes are different.
 
 I received an email back from Spansion about this problem. They suggested
 that instead of the following:
 
 fwc addr 1f401554 cmd aa  16bit x 8 bit
 flash_write16: Wrote 0x to address 1f401554
 funlock writing 0xaa to address 0x555
 fwc addr 1f400aaa cmd 55  16bit x 8 bit
 flash_write16: Wrote 0x to address 1f400aaa
 fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
 flash_write16: Wrote 0x9090 to address 1f401554
 
 to instead do the following:
 write 0xAA to 0x1F400AAA
 write 0x55 to 0x1F400555
 write 0x90 to 0x1F400AAA
 
 read 0x1F41 returns 0x01
 read 0x1F43 returns 0x7e
 
 This looks correct.
 
 I found two things I need to do to work around the problem. First, in
 flash_write_cmd I use info-chipwidth instead of info-portwidth for the
 write commands, and second, in __flash_detect_cfi I don't modify the
 address in compatibility mode. This works. If either of those steps are
 left out then reading the manufacturer ID fails.
 
 -Aaron

It looks like I spoke too soon. It fixes the manufacturer problem but 
everything else is now broken.

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

Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND = 4GB - Second try

2011-02-10 Thread Aaron Williams

On Thursday, February 10, 2011 07:27:12 pm Aaron Williams wrote:
 On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
  On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
   On Thu, Feb 10, 2011 at 00:28, Aaron Williams
   
   aaron.willi...@caviumnetworks.com wrote:
I would suggest to make sure any caching/prefetching stuff is off,
hardware is doing one flash bus access per CPU read/write.

In cmdset_amd_read_jedec_ids() after this line:

manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);

add something like

printf(test manf id word = %04x\n, *(volatile uint16_t
*)0x1f40); printf(test device id word = %04x\n, *(volatile
uint16_t
*)0x1f42); printf(test device id word = %04x\n, *(volatile
uint16_t *)0x1f40001c); printf(test device id word = %04x\n,
*(volatile uint16_t *)0x1f40001e);

and see what you get.

fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit
flash_write16: address: 1f40, value: 0xf0f0
fwc addr 1f401554 cmd aa  16bit x 8 bit
flash_write16: address: 1f401554, value: 0x
fwc addr 1f400aaa cmd 55  16bit x 8 bit
flash_write16: address: 1f400aaa, value: 0x
fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
flash_write16: address: 1f401554, value: 0x9090
flash_read8: address: 1f41, value: 0x0
test manf id word = 1000
test device id word = 013f
test device id word = da6c
test device id word = 2926
   
   looks like garbage :-(  What's in the flash at those addresses?  Maybe
   something is happening to mess up the unlock sequence and you're
   reading the memory data instead of the device codes.
   
   It's odd that earlier in the sequence when the CFI query data is read
   the byte data is mirrored across both bytes of the response, here the
   two bytes are different.
  
  I received an email back from Spansion about this problem. They suggested
  that instead of the following:
  
  fwc addr 1f401554 cmd aa  16bit x 8 bit
  flash_write16: Wrote 0x to address 1f401554
  funlock writing 0xaa to address 0x555
  fwc addr 1f400aaa cmd 55  16bit x 8 bit
  flash_write16: Wrote 0x to address 1f400aaa
  fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
  flash_write16: Wrote 0x9090 to address 1f401554
  
  to instead do the following:
  write 0xAA to 0x1F400AAA
  write 0x55 to 0x1F400555
  write 0x90 to 0x1F400AAA
  
  read 0x1F41 returns 0x01
  read 0x1F43 returns 0x7e
  
  This looks correct.
  
  I found two things I need to do to work around the problem. First, in
  flash_write_cmd I use info-chipwidth instead of info-portwidth for the
  write commands, and second, in __flash_detect_cfi I don't modify the
  address in compatibility mode. This works. If either of those steps are
  left out then reading the manufacturer ID fails.
  
  -Aaron
 
 It looks like I spoke too soon. It fixes the manufacturer problem but
 everything else is now broken.
 
 -Aaron
It works now, but I had to hard-code cmdset_amd_read_jedec_ids for some 
reason.

static void cmdset_amd_read_jedec_ids(flash_info_t *info)
{
ushort bankId = 0;
uchar  manuId;

debug(In %s\n, __func__);
flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
flash_write_cmd(info, 0, 0x555, AMD_CMD_UNLOCK_START);
flash_write_cmd(info, 0, 0x2AA, AMD_CMD_UNLOCK_ACK);
flash_write_cmd(info, 0, 0x555, FLASH_CMD_READ_ID);
/*flash_unlock_seq(info, 0); */
/*flash_write_cmd(info, 0, info-addr_unlock1, FLASH_CMD_READ_ID);*/

With this, everything works with my mod to flash_write_cmd to use chipwidth 
instead of portwidth.

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

Re: [U-Boot] [PATCH 1/2] powerpc/85xx: Fix p1_p2_rdb boards.cfg


On Feb 9, 2011, at 11:48 PM, Kumar Gala wrote:

 We should have been defining the actual board name in the options, not
 the processor.  Fix this for P1011RDB, P1020RDB, P2010RDB, and P2020RDB.
 
 Signed-off-by: Kumar Gala ga...@kernel.crashing.org
 ---
 boards.cfg |   26 +-
 1 files changed, 13 insertions(+), 13 deletions(-)

applied to 85xx

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

Re: [U-Boot] [PATCH 2/2] powerpc/85xx: corrected p1_p2_rdb EEPROM address


On Feb 9, 2011, at 11:48 PM, Kumar Gala wrote:

 From: Priyanka Jain priyanka.j...@freescale.com
 
 Board EEPROM is used to read/save Ethernet MAC addresses.
 
 Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
 Signed-off-by: Kumar Gala ga...@kernel.crashing.org
 ---
 include/configs/P1_P2_RDB.h |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

applied to 85xx

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

[U-Boot] [U-boot] Slow microsd access through MMC in P2020

2011-02-10 Thread milku


hi ...

I am using p2020 processor. Accessed through mmc. But disk throughput is
very less. Its less than 1 MBps .. can some one suggest me how to improve
the disk throughput 

regards
Souravs
-- 
View this message in context: 
http://old.nabble.com/-U-boot--Slow-microsd-access-through-MMC-in-P2020-tp30898736p30898736.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

[U-Boot] [GIT PULL] Please pull u-boot-mpc85xx.git

Some fixes for v2011.03:

The following changes since commit 494a7d215bfba17f1a94736df40c332c8713c30e:
  Wolfgang Denk (1):
Merge branch 'master' of git://git.denx.de/u-boot-nand-flash

are available in the git repository at:

  git://git.denx.de/u-boot-mpc85xx master

Kumar Gala (1):
  powerpc/85xx: Fix p1_p2_rdb boards.cfg

Priyanka Jain (1):
  powerpc/85xx: corrected p1_p2_rdb EEPROM address

Timur Tabi (1):
  fsl: update CRC after setting EEPROM identifier

York Sun (1):
  powerpc/8xxx: Add additional cycle to write-to-read turnaound for DDR3

 arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c |3 +++
 arch/powerpc/cpu/mpc8xxx/ddr/ddr.h   |2 +-
 board/freescale/common/sys_eeprom.c  |1 +
 boards.cfg   |   26 +-
 include/configs/P1_P2_RDB.h  |3 +--
 5 files changed, 19 insertions(+), 16 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

2011-02-10 Thread Aneesh V

Hello Wolfgang, Albert,

On Saturday 05 February 2011 12:28 PM, Albert ARIBAUD wrote:
 Hi Aneesh,

 Le 03/02/2011 11:38, Aneesh V a écrit :

 On second thoughts I would like to keep the entire bss in SDRAM. With
 MMC and FAT support, the SPL is already nearing the IRAM budget in
 OMAP3. It helps to save some space by moving out bss to SDRAM.

 If needed, I can fix up the start.S by defining something like
 _end_of_data. But is that really needed. I do not see any SPL that
 needs relocation and SDRAM bss at the same time.

 Patches Welcome :) -- with added thanks for patching all start.S /
 u-boot.lds in the ARM arch consistently.

I see __u_boot_cmd_end as the end of the image to be relocated in all
the scripts. Shall I use this label for this purpose. This will work
for now and save me from touching all those linker scripts. However,
there is a small possibility of this leading to the same problem as
with __bss_start in future. I don't think that should be a big concern.
Do you agree?

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

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

2011-02-10 Thread Albert ARIBAUD

Hi Aneesh,

Le 11/02/2011 07:28, Aneesh V a écrit :
 Hello Wolfgang, Albert,

 On Saturday 05 February 2011 12:28 PM, Albert ARIBAUD wrote:
 Hi Aneesh,

 Le 03/02/2011 11:38, Aneesh V a écrit :

 On second thoughts I would like to keep the entire bss in SDRAM. With
 MMC and FAT support, the SPL is already nearing the IRAM budget in
 OMAP3. It helps to save some space by moving out bss to SDRAM.

 If needed, I can fix up the start.S by defining something like
 _end_of_data. But is that really needed. I do not see any SPL that
 needs relocation and SDRAM bss at the same time.

 Patches Welcome :) -- with added thanks for patching all start.S /
 u-boot.lds in the ARM arch consistently.

 I see __u_boot_cmd_end as the end of the image to be relocated in all
 the scripts. Shall I use this label for this purpose. This will work
 for now and save me from touching all those linker scripts. However,
 there is a small possibility of this leading to the same problem as
 with __bss_start in future. I don't think that should be a big concern.
 Do you agree?

As you point out, using __u_boot_cmd would cause as much of a concern as 
the current use of __bss_start, so I see no improvement there.

Please define a label in the linker file. If you haven't got time to 
port the change to other linkers, don't ; the BSS issue is, for now, 
specific to your case.

 Best regards,
 Aneesh

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

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

2011-02-10 Thread Aneesh V

Hi Albert,

On Friday 11 February 2011 12:09 PM, Albert ARIBAUD wrote:
 Hi Aneesh,

 Le 11/02/2011 07:28, Aneesh V a écrit :
 Hello Wolfgang, Albert,

 On Saturday 05 February 2011 12:28 PM, Albert ARIBAUD wrote:
 Hi Aneesh,

 Le 03/02/2011 11:38, Aneesh V a écrit :

 On second thoughts I would like to keep the entire bss in SDRAM. With
 MMC and FAT support, the SPL is already nearing the IRAM budget in
 OMAP3. It helps to save some space by moving out bss to SDRAM.

 If needed, I can fix up the start.S by defining something like
 _end_of_data. But is that really needed. I do not see any SPL that
 needs relocation and SDRAM bss at the same time.

 Patches Welcome :) -- with added thanks for patching all start.S /
 u-boot.lds in the ARM arch consistently.

 I see __u_boot_cmd_end as the end of the image to be relocated in all
 the scripts. Shall I use this label for this purpose. This will work
 for now and save me from touching all those linker scripts. However,
 there is a small possibility of this leading to the same problem as
 with __bss_start in future. I don't think that should be a big concern.
 Do you agree?

 As you point out, using __u_boot_cmd would cause as much of a concern as
 the current use of __bss_start, so I see no improvement there.

 Please define a label in the linker file. If you haven't got time to
 port the change to other linkers, don't ; the BSS issue is, for now,
 specific to your case.

I thought it rather unlikely that the position of __u_boot_cmd will
change in future. But I agree with you. Better do it cleanly once and
for all. Changing the linker scripts for all cpus should not be a big
deal. But I will not be able to test any of them except armv7/omap4

One patch will do, right?

Also, any thoughts on the name for the new label.
_end_of_relocated_image is all I can think of?


 Best regards,
 Aneesh

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

Re: [U-Boot] MTD partitions not mounted by the kernel