[U-Boot] Sorry, the patch v5 of arm64 port is duplicated, please remove unwanted.

2013-08-24 Thread FengHua 


I am so sorry, the patch v5 of arm64 port is duplicated, please remove unwanted.




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

Re: [U-Boot] Failing USB devices

2013-08-24 Thread Andrew Murray 
On 23 August 2013 04:23, Marek Vasut ma...@denx.de wrote:

 Dear Andrew Murray,

  Hello,
 
  I'm unable to use some mass storage devices with the current git version
  (6612ab33956ae09c5ba2fde9c1540b519625ba37) of UBoot on a TI Davinci custom
  board. I have 7 pen drives, and 2 of them fail.
 
  I-O DATA USB Flash Disk (0x04bb/0x0c43)
 
  ...
  2 USB Device(s) found
  scan end
 scanning usb for storage devices... i=0
  i=1
 
 
  USB Mass Storage device detected
  Transport: Bulk/Bulk/Bulk
  Endpoints In 1 Out 2 Int 0
  usb_control_msg: request: 0xFE, requesttype: 0xA1, value 0x0 index 0x0
  length 0x1
  Get Max LUN - len = 1, result = 0
   address 2
  COMMAND phase
  DATA phase
  STATUS phase
  !CSWSIGNATURE
  BBB_reset
  usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
  length 0x0
  RESET:stall
  inquiry returns -1
  COMMAND phase
  DATA phase
  STATUS phase
  !CSWSIGNATURE
  BBB_reset
  usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
  length 0x0
  RESET:stall
  inquiry returns -1
  COMMAND phase
  DATA phase
  STATUS phase
  !CSWSIGNATURE
  BBB_reset
  usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
  length 0x0
  RESET:stall
  inquiry returns -1
  COMMAND phase
  DATA phase
  STATUS phase
  !CSWSIGNATURE
  BBB_reset
  usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
  length 0x0
  RESET:stall
  inquiry returns -1
  COMMAND phase
  DATA phase
  STATUS phase
  !CSWSIGNATURE
  BBB_reset
  usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
  length 0x0
  RESET:stall
  inquiry returns -1
  error in inquiry
  i=2
  0 Storage Device(s) found
 
  In this case putting a delay of 1000ms in usb_stor_BBB_transport between
  the COMMAND and DATA phase, (in place of the conditional 5ms USB_READY
  delay), overcomes this issue. It seems this 1000ms delay is only required
  for the first COMMAND, subsequent COMMAND phases seem happy with the 5ms
  delay.
 
  Lexar JumpDrive 32GB (0x0424/0x2507):
 

 So the device takes too long to init itself after powering up the port.

The port is powered after usb_hub_power_on, I've used
CONFIG_USB_HUB_MIN_POWER_ON_DELAY to set this to a large value (10
seconds), however this has no effect on the above failure.

In fact with some further testing it seems that adding the 1000ms
delay anywhere inside the loop inside the usb_inquiry function
overcomes the above issues. The inquiry still fails, but the
subsequent BBB_reset's stop stalling - successfully reset and then the
next inquiry succeeds and the storage device detected. E.g...

.
COMMAND phase
DATA phase
STATUS phase
!CSWSIGNATURE
BBB_reset
RESET:stall
inquiry returns -1
.
COMMAND phase
DATA phase
STATUS phase
!CSWSIGNATURE
BBB_reset
BBB_reset result 0: status 0 reset
BBB_reset result 0: status 0 clearing IN endpoint
BBB_reset result 0: status 0 clearing OUT endpoint
BBB_reset done
inquiry returns -1
.
COMMAND phase
DATA phase
STATUS phase
inquiry returns 0
ISO Vers 2, Response Data 2
COMMAND phase
STATUS phase
COMMAND phase
DATA phase
STATUS phase
Read Capacity returns: 0xff3f3d00, 0x2
Capacity = 0x3d4000, blocksz = 0x200
 address 2
partype: 0

Does this suggest there needs to be a larger initial delay in between
the COMMAND and STATUS phase, something wrong with the BBB_reset or
something else?

 It would
 be nice if you could check the spec and see if there is a way to query the
 device for ready condition. Although I remember we already do that.


Unfortunately I do not have the spec (the USB device is an
off-the-shelf pen drive). The above failure happens in the usb_inquiry
function, this seems to be the first user of BBB transport and this
happens before the first call to usb_test_unit_ready.

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

Re: [U-Boot] Failing USB devices

2013-08-24 Thread Andrew Murray 
On 23 August 2013 11:54, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
 Dear Marek, Andrew,

...

 This is the kind of issue that made me create this (discarded) patch at some
 point:
 http://patchwork.ozlabs.org/patch/176527/

 Can you try it? I'm not sure that it will be helpful for your specific case.

Unfortunately it has no effect. But then the STATUS phase isn't
stalling in my case, it's just giving back an unexpected value for
CSWSIGNATURE - I have no idea why this is.


 I also have this issue with some devices and mainline U-Boot. I can confirm 
 that
 this is a device initialization delay issue because subsequent USB commands on
 the device succeed (only the single automatic U-Boot USB command that I use at
 boot time fails).

You may be able to work around these by setting
CONFIG_USB_HUB_MIN_POWER_ON_DELAY in your config file (assuming the
device is behind a hub).


 Best regards,
 Benoît

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

Re: [U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?

2013-08-24 Thread Luka Perkov 
On Sat, Aug 24, 2013 at 12:01:25AM -0400, Robert P. J. Day wrote:
 On Sat, 24 Aug 2013, Luka Perkov wrote:
  /dev/mmcblk0 0x6 0x2000 0x2000
 
   ah, there's the misunderstanding. i thought we were discussing how
 to be able to refer *directly* to the eMMC partition boot1, as in
 /dev/mmcblk1boot1. it looks like what you're describing would refer
 instead simply to /dev/mmcblk1, correct?

Even though the config is actually refering to /dev/mmcblk1 in fact it's
writing/reading to /dev/mmcblk1p1 (or /dev/mmcblk1boot1) in your case.
But you need to configure it properly for your MMC device.

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

Re: [U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?

2013-08-24 Thread Robert P. J. Day 
On Sat, 24 Aug 2013, Luka Perkov wrote:

 On Sat, Aug 24, 2013 at 12:01:25AM -0400, Robert P. J. Day wrote:
  On Sat, 24 Aug 2013, Luka Perkov wrote:
   /dev/mmcblk0 0x6 0x2000 0x2000
 
ah, there's the misunderstanding. i thought we were discussing
  how to be able to refer *directly* to the eMMC partition boot1,
  as in /dev/mmcblk1boot1. it looks like what you're describing
  would refer instead simply to /dev/mmcblk1, correct?

 Even though the config is actually refering to /dev/mmcblk1 in fact
 it's writing/reading to /dev/mmcblk1p1 (or /dev/mmcblk1boot1) in
 your case. But you need to configure it properly for your MMC
 device.

  right, i can see that and that clarifies things for me. my
*original* question was whether there was a way to set up
/etc/fw_env.config to refer to the eMMC partition /dev/mmcblk1boot1
*directly*, treating it as a regular block partition and bypassing all
the MTD-related processing. (perhaps stefano can weigh in and say
whether that's how he understood what i was asking.)

  if you instead refer to /dev/mmcblk1, as i understand it, you're
just back to the standard MTD-based access, yes?

  anyway, sorry if i didn't explain myself clearly the first time.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[U-Boot] [PATCH] arm: prevent using movt/movw address loads

2013-08-24 Thread Jeroen Hofstee 
The movt/movw instruction can be used to hardcode an
memory location in the instruction itself. The linker
starts complaining about this if the compiler decides
to do so: relocation R_ARM_MOVW_ABS_NC against `a local
symbol' can not be used and it is not support by U-boot
as well. Prevent their use by requiring word relocations.
This allows u-boot to be build at other optimalization
levels then -Os.

Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
Cc: tiger...@viatech.com.cn
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
---
 arch/arm/config.mk | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 540a119..2277c82 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -94,7 +94,11 @@ PLATFORM_RELFLAGS += -fno-optimize-sibling-calls
 endif
 endif
 
-# check that only R_ARM_RELATIVE relocations are generated
 ifneq ($(CONFIG_SPL_BUILD),y)
-ALL-y  += checkarmreloc
+# Check that only R_ARM_RELATIVE relocations are generated.
+ALL-y += checkarmreloc
+# The movt / movw can hardcode 16 bit parts of the addresses in the
+# instruction. Relocation is not supported for that case, so disable
+# such usage by requiring word relocations.
+PLATFORM_CPPFLAGS += $(call cc-option, -mword-relocations)
 endif
-- 
1.8.1.2

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

Re: [U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?

2013-08-24 Thread Michael Heimpold 
Hi,

   right, i can see that and that clarifies things for me. my
 *original* question was whether there was a way to set up
 /etc/fw_env.config to refer to the eMMC partition /dev/mmcblk1boot1
 *directly*, treating it as a regular block partition and bypassing all
 the MTD-related processing. (perhaps stefano can weigh in and say
 whether that's how he understood what i was asking.)
 
   if you instead refer to /dev/mmcblk1, as i understand it, you're
 just back to the standard MTD-based access, yes?

the /dev/mmcblk... devices are block devices and do not provide
the MTD API of the kernel. I guess this is the cause for the error message
you've seen. You could try strace to verify.
And this is the problem why the patches Luka mentioned are required:
they make fw_{printenv,setenv} aware of opening such block devices
by-passing the MTD-specific stuff, that means simply open the file,
write/read the data and close the file descriptor. Without these patches
these tools assume that the file descriptor opened are MTD-based.

You can pass what ever you want via your config, so your file could
look like:
/dev/mmcblk1boot1 0x0 0x4000
Since the partition is somewhere placed on the eMMC device, you
can also refer to the same location using /dev/mmcblk1. In the latter
case you have to calculate the offset correctly to not overwrite
other data (e.g. on other partitions). Using /dev/mmcblk1boot1 as
entry point the kernel should reject write requests which go beyond
the partition size.

BR, Michael

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

[U-Boot] [PATCH] mxs_nand: Fix ECC strength for NAND flash with OOB size of 224

2013-08-24 Thread Elie De Brauwer 
On a board with an i.mx28 and a Micron MT29F4G08ABAEAH4, Linux says:

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron MT29F4G08ABAEAH4),
512MiB, page size: 4096, OOB size: 224) the ECC strength is 16.

root@(none):/sys/devices/virtual/mtd/mtd0# for i in ecc_strength oobsize 
subpagesize; do echo $i = `cat $i`; done
ecc_strength = 16
oobsize = 224
subpagesize = 4096

The ECC strength was not properly discovered by U-Boot causing the data
written by Linux to return an -74 (EBADMSG) when read from U-Boot. This
patch fixes mxs_nand_get_ecc_strength() to function in case of a NAND
flash with page_data_size = 4096 and page_oob_size= 224.

Signed-off-by: Elie De Brauwer eliedebrau...@gmail.com
---
 drivers/mtd/nand/mxs_nand.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index 378f8c5..036c113 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -155,6 +155,9 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t 
page_data_size,
 
if (page_oob_size == 218)
return 16;
+
+   if (page_oob_size == 224)
+   return 16;
}
 
return 0;
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 4/8] ahci: add defines for PORT_SCR_STAT register bits

2013-08-24 Thread Rob Herring 
From: Rob Herring rob.herr...@calxeda.com

Replace hard-coded register values with proper defines for PORT_SCR_STAT
register.

Signed-off-by: Rob Herring rob.herr...@calxeda.com
---
v2: New patch

 drivers/block/ahci.c | 5 +++--
 include/ahci.h   | 5 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index f088063..ad7e95f 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -207,7 +207,8 @@ static int ahci_host_init(struct ahci_probe_ent *probe_ent)
j = 0;
while (j  WAIT_MS_LINKUP) {
tmp = readl(port_mmio + PORT_SCR_STAT);
-   if ((tmp  0xf) == 0x3)
+   tmp = PORT_SCR_STAT_DET_MASK;
+   if (tmp == PORT_SCR_STAT_DET_PHYRDY)
break;
udelay(1000);
j++;
@@ -258,7 +259,7 @@ static int ahci_host_init(struct ahci_probe_ent *probe_ent)
/* register linkup ports */
tmp = readl(port_mmio + PORT_SCR_STAT);
debug(SATA port %d status: 0x%x\n, i, tmp);
-   if ((tmp  0xf) == 0x03)
+   if ((tmp  PORT_SCR_STAT_DET_MASK) == PORT_SCR_STAT_DET_PHYRDY)
probe_ent-link_port_map |= (0x01  i);
}
 
diff --git a/include/ahci.h b/include/ahci.h
index 78a8c55..d76993c 100644
--- a/include/ahci.h
+++ b/include/ahci.h
@@ -87,6 +87,11 @@
| PORT_IRQ_DMAS_FIS | PORT_IRQ_PIOS_FIS \
| PORT_IRQ_D2H_REG_FIS
 
+/* PORT_SCR_STAT bits */
+#define PORT_SCR_STAT_DET_MASK 0x3
+#define PORT_SCR_STAT_DET_COMINIT 0x1
+#define PORT_SCR_STAT_DET_PHYRDY 0x3
+
 /* PORT_CMD bits */
 #define PORT_CMD_ATAPI (1  24) /* Device is ATAPI */
 #define PORT_CMD_LIST_ON   (1  15) /* cmd list DMA engine running */
-- 
1.8.1.2

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

[U-Boot] [PATCH v2 2/8] ahci: fix unaligned access

2013-08-24 Thread Rob Herring 
From: Rob Herring rob.herr...@calxeda.com

gcc 4.7 will generate unaligned accesses to local char arrays, so make
them static to avoid that.

Signed-off-by: Rob Herring rob.herr...@calxeda.com
Reviewed-by: Tom Rini tr...@ti.com
---
v2: make hdr const

 drivers/block/ahci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 02ba02f..f4d1d81 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -610,7 +610,7 @@ static void dump_ataid(hd_driveid_t *ataid)
  */
 static int ata_scsiop_inquiry(ccb *pccb)
 {
-   u8 hdr[] = {
+   static const u8 hdr[] = {
0,
0,
0x5,/* claim SPC-3 version compatibility */
-- 
1.8.1.2

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

[U-Boot] [PATCH v2 6/8] ahci: handle COMINIT received during spin-up

2013-08-24 Thread Rob Herring 
From: Rob Herring rob.herr...@calxeda.com

Some Intel SSDs can send a COMINIT after the initial COMRESET. This causes
the link to go down and we need to re-initialize the link.

Signed-off-by: Rob Herring rob.herr...@calxeda.com
---
v2: Use define values for PORT_SCR

 drivers/block/ahci.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 5e7d01b..a7044f2 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -243,8 +243,20 @@ static int ahci_host_init(struct ahci_probe_ent *probe_ent)
if (!(tmp  (ATA_STAT_BUSY | ATA_STAT_DRQ)))
break;
udelay(1000);
+   tmp = readl(port_mmio + PORT_SCR_STAT);
+   tmp = PORT_SCR_STAT_DET_MASK;
+   if (tmp == PORT_SCR_STAT_DET_PHYRDY)
+   break;
j++;
}
+
+   tmp = readl(port_mmio + PORT_SCR_STAT)  PORT_SCR_STAT_DET_MASK;
+   if (tmp == PORT_SCR_STAT_DET_COMINIT) {
+   debug(SATA link %d down (COMINIT received), 
retrying...\n, i);
+   i--;
+   continue;
+   }
+
printf(Target spinup took %d ms.\n, j);
if (j == WAIT_MS_SPINUP)
debug(timeout.\n);
-- 
1.8.1.2

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

[U-Boot] [PATCH v2 8/8] ahci: convert to use libata functions and definitions

2013-08-24 Thread Rob Herring 
From: Rob Herring rob.herr...@calxeda.com

libata already has similar functions as implemented in the ahci code.
Refactor the code to use the libata variants and remove the dependency on
ata.h. Convert some defines to use the version from libata.h. Also, remove
some unnecessary memset's of bss data.

This is a step toward hopefully merging ahci.c and dw_ahsata.c which are
essentially the same driver.

Signed-off-by: Rob Herring rob.herr...@calxeda.com
Reviewed-by: Tom Rini tr...@ti.com
---
v2: rebase to v2013.10-rc1

 drivers/block/ahci.c  | 80 +--
 include/ahci.h| 23 -
 include/configs/MPC8544DS.h   |  1 +
 include/configs/MPC8572DS.h   |  1 +
 include/configs/MPC8610HPCD.h |  1 +
 include/configs/MPC8641HPCN.h |  1 +
 include/configs/P2020DS.h |  1 +
 include/configs/coreboot.h|  1 +
 include/configs/highbank.h|  1 +
 9 files changed, 31 insertions(+), 79 deletions(-)

diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 7f78c00..8cc9379 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -16,14 +16,14 @@
 #include asm/io.h
 #include malloc.h
 #include scsi.h
-#include ata.h
+#include libata.h
 #include linux/ctype.h
 #include ahci.h
 
 static int ata_io_flush(u8 port);
 
 struct ahci_probe_ent *probe_ent = NULL;
-hd_driveid_t *ataid[AHCI_MAX_PORTS];
+u16 *ataid[AHCI_MAX_PORTS];
 
 #define writel_with_flush(a,b) do { writel(a,b); readl(b); } while (0)
 
@@ -240,7 +240,7 @@ static int ahci_host_init(struct ahci_probe_ent *probe_ent)
j = 0;
while (j  WAIT_MS_SPINUP) {
tmp = readl(port_mmio + PORT_TFDATA);
-   if (!(tmp  (ATA_STAT_BUSY | ATA_STAT_DRQ)))
+   if (!(tmp  (ATA_BUSY | ATA_DRQ)))
break;
udelay(1000);
tmp = readl(port_mmio + PORT_SCR_STAT);
@@ -378,8 +378,6 @@ static int ahci_init_one(pci_dev_t pdev)
u16 vendor;
int rc;
 
-   memset((void *)ataid, 0, sizeof(hd_driveid_t *) * AHCI_MAX_PORTS);
-
probe_ent = malloc(sizeof(struct ahci_probe_ent));
memset(probe_ent, 0, sizeof(struct ahci_probe_ent));
probe_ent-dev = pdev;
@@ -469,7 +467,7 @@ static void ahci_set_feature(u8 port)
memset(fis, 0, sizeof(fis));
fis[0] = 0x27;
fis[1] = 1  7;
-   fis[2] = ATA_CMD_SETF;
+   fis[2] = ATA_CMD_SET_FEATURES;
fis[3] = SETFEATURES_XFER;
fis[12] = __ilog2(probe_ent-udma_mask + 1) + 0x40 - 0x01;
 
@@ -607,27 +605,6 @@ static char *ata_id_strcpy(u16 *target, u16 *src, int len)
return (char *)target;
 }
 
-
-static void dump_ataid(hd_driveid_t *ataid)
-{
-   debug((49)ataid-capability = 0x%x\n, ataid-capability);
-   debug((53)ataid-field_valid =0x%x\n, ataid-field_valid);
-   debug((63)ataid-dma_mword = 0x%x\n, ataid-dma_mword);
-   debug((64)ataid-eide_pio_modes = 0x%x\n, ataid-eide_pio_modes);
-   debug((75)ataid-queue_depth = 0x%x\n, ataid-queue_depth);
-   debug((80)ataid-major_rev_num = 0x%x\n, ataid-major_rev_num);
-   debug((81)ataid-minor_rev_num = 0x%x\n, ataid-minor_rev_num);
-   debug((82)ataid-command_set_1 = 0x%x\n, ataid-command_set_1);
-   debug((83)ataid-command_set_2 = 0x%x\n, ataid-command_set_2);
-   debug((84)ataid-cfsse = 0x%x\n, ataid-cfsse);
-   debug((85)ataid-cfs_enable_1 = 0x%x\n, ataid-cfs_enable_1);
-   debug((86)ataid-cfs_enable_2 = 0x%x\n, ataid-cfs_enable_2);
-   debug((87)ataid-csf_default = 0x%x\n, ataid-csf_default);
-   debug((88)ataid-dma_ultra = 0x%x\n, ataid-dma_ultra);
-   debug((93)ataid-hw_config = 0x%x\n, ataid-hw_config);
-}
-
-
 /*
  * SCSI INQUIRY command operation.
  */
@@ -641,7 +618,7 @@ static int ata_scsiop_inquiry(ccb *pccb)
95 - 4,
};
u8 fis[20];
-   u8 *tmpid;
+   u16 *tmpid;
u8 port;
 
/* Clean ccb data buffer */
@@ -656,15 +633,16 @@ static int ata_scsiop_inquiry(ccb *pccb)
/* Construct the FIS */
fis[0] = 0x27;  /* Host to device FIS. */
fis[1] = 1  7;/* Command FIS. */
-   fis[2] = ATA_CMD_IDENT; /* Command byte. */
+   fis[2] = ATA_CMD_ID_ATA; /* Command byte. */
 
/* Read id from sata */
port = pccb-target;
-   if (!(tmpid = malloc(sizeof(hd_driveid_t
+   tmpid = malloc(ATA_ID_WORDS * 2);
+   if (!tmpid)
return -ENOMEM;
 
-   if (ahci_device_data_io(port, (u8 *) fis, sizeof(fis), tmpid,
-   sizeof(hd_driveid_t), 0)) {
+   if (ahci_device_data_io(port, (u8 *) fis, sizeof(fis), (u8 *)tmpid,
+   ATA_ID_WORDS * 2, 0)) {
debug(scsi_ahci: SCSI inquiry command failure.\n);
free(tmpid);
return -EIO;
@@ -672,13 +650,16 @@ static int ata_scsiop_inquiry(ccb *pccb)

[U-Boot] [PATCH v2 7/8] ahci: increase spin-up timeout to 20 sec

2013-08-24 Thread Rob Herring 
From: Rob Herring rob.herr...@calxeda.com

Based on Linux libata code, most drives are less than 10 sec, but some
need up to 20 sec.

Signed-off-by: Rob Herring rob.herr...@calxeda.com
Reviewed-by: Tom Rini tr...@ti.com
---
v2: rebase to v2013.10-rc1

 drivers/block/ahci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index a7044f2..7f78c00 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -38,7 +38,7 @@ hd_driveid_t *ataid[AHCI_MAX_PORTS];
 #endif
 
 /* Maximum timeouts for each event */
-#define WAIT_MS_SPINUP 1
+#define WAIT_MS_SPINUP 2
 #define WAIT_MS_DATAIO 5000
 #define WAIT_MS_FLUSH  5000
 #define WAIT_MS_LINKUP 4
-- 
1.8.1.2

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

[U-Boot] [PATCH v2 1/8] ahci: use ports implemented map instead of num_ports

2013-08-24 Thread Rob Herring 
From: Richard Gibbs richard.gi...@calxeda.com

The AHCI driver was incorrectly using the Capabilities register NP (number
of ports) field to determine which ports to activate. This commit changes
it to correctly use the PORTS_IMPL register as a port map.

Signed-off-by: Richard Gibbs richard.gi...@calxeda.com
Reviewed-by: Tom Rini tr...@ti.com
---
v2: rebase to v2013.10-rc1

 drivers/block/ahci.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index e455ba5..02ba02f 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -119,6 +119,7 @@ static int ahci_host_init(struct ahci_probe_ent *probe_ent)
u32 tmp, cap_save, cmd;
int i, j;
volatile u8 *port_mmio;
+   u32 port_map;
 
debug(ahci_host_init: start\n);
 
@@ -160,6 +161,7 @@ static int ahci_host_init(struct ahci_probe_ent *probe_ent)
 #endif
probe_ent-cap = readl(mmio + HOST_CAP);
probe_ent-port_map = readl(mmio + HOST_PORTS_IMPL);
+   port_map = probe_ent-port_map;
probe_ent-n_ports = (probe_ent-cap  0x1f) + 1;
 
debug(cap 0x%x  port_map 0x%x  n_ports %d\n,
@@ -169,6 +171,8 @@ static int ahci_host_init(struct ahci_probe_ent *probe_ent)
probe_ent-n_ports = CONFIG_SYS_SCSI_MAX_SCSI_ID;
 
for (i = 0; i  probe_ent-n_ports; i++) {
+   if (!(port_map  (1  i)))
+   continue;
probe_ent-port[i].port_mmio = ahci_port_base((u32) mmio, i);
port_mmio = (u8 *) probe_ent-port[i].port_mmio;
ahci_setup_port(probe_ent-port[i], (unsigned long)mmio, i);
-- 
1.8.1.2

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

[U-Boot] [PATCH v2 3/8] ahci: fix memory leak in ata_scsiop_inquiry

2013-08-24 Thread Rob Herring 
From: Rob Herring rob.herr...@calxeda.com

This fixes a memory leak when scsi inquiry fails.

Signed-off-by: Rob Herring rob.herr...@calxeda.com
Reviewed-by: Tom Rini tr...@ti.com
---
v2: rebase to v2013.10-rc1

 drivers/block/ahci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index f4d1d81..f088063 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -643,6 +643,7 @@ static int ata_scsiop_inquiry(ccb *pccb)
if (ahci_device_data_io(port, (u8 *) fis, sizeof(fis), tmpid,
sizeof(hd_driveid_t), 0)) {
debug(scsi_ahci: SCSI inquiry command failure.\n);
+   free(tmpid);
return -EIO;
}
 
-- 
1.8.1.2

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

[U-Boot] [PATCH v2 5/8] ahci: move link bring-up handling to separate function

2013-08-24 Thread Rob Herring 
From: Rob Herring rob.herr...@calxeda.com

Move the link bring-up handling to a separate weak function in order to
allow platforms to override it. This is needed on highbank platform which
needs special phy handling.

Signed-off-by: Rob Herring rob.herr...@calxeda.com
---
v2:
- Use __weak attribute instead
- Fix comment formatting
- Use defines added in previous patch

 drivers/block/ahci.c | 40 +---
 1 file changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index ad7e95f..5e7d01b 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -107,6 +107,27 @@ static int waiting_for_cmd_completed(volatile u8 *offset,
return (i  timeout_msec) ? 0 : -1;
 }
 
+int __weak ahci_link_up(struct ahci_probe_ent *probe_ent, u8 port)
+{
+   u32 tmp;
+   int j = 0;
+   u8 *port_mmio = (u8 *)probe_ent-port[port].port_mmio;
+
+   /* 
+* Bring up SATA link.
+* SATA link bringup time is usually less than 1 ms; only very
+* rarely has it taken between 1-2 ms. Never seen it above 2 ms.
+*/
+   while (j  WAIT_MS_LINKUP) {
+   tmp = readl(port_mmio + PORT_SCR_STAT);
+   tmp = PORT_SCR_STAT_DET_MASK;
+   if (tmp == PORT_SCR_STAT_DET_PHYRDY)
+   return 0;
+   udelay(1000);
+   j++;
+   }
+   return 1;
+}
 
 static int ahci_host_init(struct ahci_probe_ent *probe_ent)
 {
@@ -117,7 +138,7 @@ static int ahci_host_init(struct ahci_probe_ent *probe_ent)
 #endif
volatile u8 *mmio = (volatile u8 *)probe_ent-mmio_base;
u32 tmp, cap_save, cmd;
-   int i, j;
+   int i, j, ret;
volatile u8 *port_mmio;
u32 port_map;
 
@@ -200,20 +221,9 @@ static int ahci_host_init(struct ahci_probe_ent *probe_ent)
cmd |= PORT_CMD_SPIN_UP;
writel_with_flush(cmd, port_mmio + PORT_CMD);
 
-   /* Bring up SATA link.
-* SATA link bringup time is usually less than 1 ms; only very
-* rarely has it taken between 1-2 ms. Never seen it above 2 ms.
-*/
-   j = 0;
-   while (j  WAIT_MS_LINKUP) {
-   tmp = readl(port_mmio + PORT_SCR_STAT);
-   tmp = PORT_SCR_STAT_DET_MASK;
-   if (tmp == PORT_SCR_STAT_DET_PHYRDY)
-   break;
-   udelay(1000);
-   j++;
-   }
-   if (j == WAIT_MS_LINKUP) {
+   /* Bring up SATA link. */
+   ret = ahci_link_up(probe_ent, i);
+   if (ret) {
printf(SATA link %d timeout.\n, i);
continue;
} else {
-- 
1.8.1.2

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

Re: [U-Boot] Failing USB devices

2013-08-24 Thread Benoît Thébaudeau 
On Saturday, August 24, 2013 12:51:09 PM, Andrew Murray wrote:
 On 23 August 2013 11:54, Benoît Thébaudeau
 benoit.thebaud...@advansee.com wrote:
  I also have this issue with some devices and mainline U-Boot. I can confirm
  that
  this is a device initialization delay issue because subsequent USB commands
  on
  the device succeed (only the single automatic U-Boot USB command that I use
  at
  boot time fails).
 
 You may be able to work around these by setting
 CONFIG_USB_HUB_MIN_POWER_ON_DELAY in your config file (assuming the
 device is behind a hub).

This happens for me without any hub.

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

[U-Boot] [RFC 3/3] ARM: do not assign gd outside of crt0.S

2013-08-24 Thread Jeroen Hofstee 
---
 arch/arm/cpu/arm926ejs/davinci/spl.c   | 3 +--
 arch/arm/cpu/armv7/exynos/spl_boot.c   | 6 ++
 arch/arm/cpu/armv7/omap-common/hwinit-common.c | 2 --
 arch/arm/cpu/armv7/omap3/board.c   | 2 --
 board/isee/igep0033/board.c| 1 -
 board/phytec/pcm051/board.c| 2 --
 board/ti/am335x/board.c| 2 --
 board/ti/ti814x/evm.c  | 2 --
 board/woodburn/woodburn.c  | 3 ---
 9 files changed, 3 insertions(+), 20 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c 
b/arch/arm/cpu/arm926ejs/davinci/spl.c
index 59b304e..0af3646 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
@@ -50,8 +50,7 @@ void board_init_f(ulong dummy)
/* Third, we clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
 
-   /* Finally, setup gd and move to the next step. */
-   gd = gdata;
+   /* Finally move to the next step. */
board_init_r(NULL, 0);
 }
 
diff --git a/arch/arm/cpu/armv7/exynos/spl_boot.c 
b/arch/arm/cpu/armv7/exynos/spl_boot.c
index 3651c00..c0287aa 100644
--- a/arch/arm/cpu/armv7/exynos/spl_boot.c
+++ b/arch/arm/cpu/armv7/exynos/spl_boot.c
@@ -149,9 +149,8 @@ void memzero(void *s, size_t n)
  *
  * @param gdp   Value to give to gd
  */
-static void setup_global_data(gd_t *gdp)
+static void setup_global_data(void)
 {
-   gd = gdp;
memzero((void *)gd, sizeof(gd_t));
gd-flags |= GD_FLG_RELOC;
gd-baudrate = CONFIG_BAUDRATE;
@@ -160,10 +159,9 @@ static void setup_global_data(gd_t *gdp)
 
 void board_init_f(unsigned long bootflag)
 {
-   __aligned(8) gd_t local_gd;
__attribute__((noreturn)) void (*uboot)(void);
 
-   setup_global_data(local_gd);
+   setup_global_data();
 
if (do_lowlevel_init())
power_exit_wakeup();
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c 
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 85d3754..69cbfd6 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -143,8 +143,6 @@ void s_init(void)
srcomp_enable();
setup_clocks_for_console();
 
-   gd = gdata;
-
preloader_console_init();
do_io_settings();
 #endif
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 7d1f8d9..3c0042d 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -240,8 +240,6 @@ void s_init(void)
 #endif
 
 #ifdef CONFIG_SPL_BUILD
-   gd = gdata;
-
preloader_console_init();
 
timer_init();
diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
index c0f0c0d..8cb9e4c 100644
--- a/board/isee/igep0033/board.c
+++ b/board/isee/igep0033/board.c
@@ -102,7 +102,6 @@ void s_init(void)
enable_uart0_pin_mux();
 
uart_soft_reset();
-   gd = gdata;
 
preloader_console_init();
 
diff --git a/board/phytec/pcm051/board.c b/board/phytec/pcm051/board.c
index 6291d03..3bf45ac 100644
--- a/board/phytec/pcm051/board.c
+++ b/board/phytec/pcm051/board.c
@@ -113,8 +113,6 @@ void s_init(void)
enable_uart0_pin_mux();
uart_soft_reset();
 
-   gd = gdata;
-
preloader_console_init();
 
/* Initalize the board header */
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 7138d73..f11eb93 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -328,8 +328,6 @@ void s_init(void)
 
uart_soft_reset();
 
-   gd = gdata;
-
preloader_console_init();
 
/* Initalize the board header */
diff --git a/board/ti/ti814x/evm.c b/board/ti/ti814x/evm.c
index 17fba5a..7800a4d 100644
--- a/board/ti/ti814x/evm.c
+++ b/board/ti/ti814x/evm.c
@@ -143,8 +143,6 @@ void s_init(void)
/* Enable UART */
uart_enable();
 
-   gd = gdata;
-
preloader_console_init();
 
config_dmm(evm_lisa_map_regs);
diff --git a/board/woodburn/woodburn.c b/board/woodburn/woodburn.c
index 2744514..3da61a4 100644
--- a/board/woodburn/woodburn.c
+++ b/board/woodburn/woodburn.c
@@ -137,9 +137,6 @@ void board_init_f(ulong dummy)
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
 
-   /* Set global data pointer. */
-   gd = gdata;
-
preloader_console_init();
timer_init();
 
-- 
1.8.1.2

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

[U-Boot] [RFC 2/3] ARM,crt0.S: optional init gd to gdata for spl

2013-08-24 Thread Jeroen Hofstee 
The common/spl changes gd to gdata in board_init_f.
I fail to see why. The only reason I can think of to
use the gdata is the case where is won't fit into the
region where the stack lives.

Move the init to crt0.S and make it a CONFIG.
---
 arch/arm/lib/crt0.S | 5 +
 arch/arm/lib/spl.c  | 5 ++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 98d7881..b8fa10e 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -67,9 +67,14 @@ ENTRY(_main)
ldr sp, =(CONFIG_SYS_INIT_SP_ADDR)
 #endif
bic sp, sp, #7  /* 8-byte alignment for ABI compliance */
+
+#if defined(CONFIG_SPL_BUILD)  defined(CONFIG_SPL_GD_GLOBAL)
+   ldr r8, =gdata  /* SPL assigns GD directly to gdata */
+#else
sub sp, #GD_SIZE/* allocate one GD above SP */
bic sp, sp, #7  /* 8-byte alignment for ABI compliance */
mov r8, sp  /* GD is above SP */
+#endif
 
bl  s_init
 
diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c
index 583bdb3..52dba2f 100644
--- a/arch/arm/lib/spl.c
+++ b/arch/arm/lib/spl.c
@@ -15,7 +15,9 @@
 
 /* Pointer to as well as the global data structure for SPL */
 DECLARE_GLOBAL_DATA_PTR;
+#ifdef CONFIG_SPL_GD_GLOBAL
 gd_t gdata __attribute__ ((section(.data)));
+#endif
 
 /*
  * In the context of SPL, board_init_f must ensure that any clocks/etc for
@@ -31,9 +33,6 @@ void __weak board_init_f(ulong dummy)
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
 
-   /* Set global data pointer. */
-   gd = gdata;
-
board_init_r(NULL, 0);
 }
 
-- 
1.8.1.2

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

[U-Boot] [RFC 0/3] ARM: cleanup gd init

2013-08-24 Thread Jeroen Hofstee 
Hello,

As I noticed at [1] gd is setup multiple times. As pointed
Tom pointed out out me this actually leads to problems as
well, see [2]. These patches attempt to cleanup gd usage
(a bit, board_f.c is not included since that one is rather
trivial), some questions I have about it:

1) The major one, do these init changes brick any board?
2) Is there any board which needs gdata as a global?
3) What to do with lowlevel_init on armv7. Hide it under
a CONFIG_*, make it weak.. or just remove it completely?
4) Keep the s_init in crt0.S or move it to the board_init_f?
The disadvantage of the later is that all the different
board_init_f's need to call system_init.
5) Where to put the __weak s_init (or hide this under a define)

Regards,
Jeroen

[1] http://lists.denx.de/pipermail/u-boot/2013-August/160933.html
[2] http://lists.denx.de/pipermail/u-boot/2013-July/158144.html

Jeroen Hofstee (3):
  ARM,crt0.S: call s_init instead from ctr0.S
  ARM,crt0.S: optional init gd to gdata for spl
  ARM: do not assign gd outside of crt0.S

 arch/arm/cpu/arm926ejs/davinci/spl.c   |  3 +--
 arch/arm/cpu/armv7/exynos/spl_boot.c   |  6 ++
 arch/arm/cpu/armv7/lowlevel_init.S | 23 +--
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |  2 --
 arch/arm/cpu/armv7/omap3/board.c   |  2 --
 arch/arm/cpu/armv7/omap3/lowlevel_init.S   |  8 
 arch/arm/cpu/armv7/rmobile/lowlevel_init.S |  6 --
 arch/arm/lib/crt0.S|  8 
 arch/arm/lib/reset.c   |  5 +
 arch/arm/lib/spl.c |  5 ++---
 board/isee/igep0033/board.c|  1 -
 board/phytec/pcm051/board.c|  2 --
 board/ti/am335x/board.c|  2 --
 board/ti/omap5912osk/lowlevel_init.S   | 11 ---
 board/ti/ti814x/evm.c  |  2 --
 board/woodburn/woodburn.c  |  3 ---
 16 files changed, 23 insertions(+), 66 deletions(-)

-- 
1.8.1.2

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

[U-Boot] [RFC 1/3] ARM,crt0.S: call s_init instead from ctr0.S

2013-08-24 Thread Jeroen Hofstee 
The only reason gd is setup before _main seems to be
the call to s_init. Therefore call s_init in crt0.S
after gd has been setup. (It might become system_init
one day, but that has the disadvantage that all versions
of board_init_f must call system_init).
---
 arch/arm/cpu/armv7/lowlevel_init.S | 23 +--
 arch/arm/cpu/armv7/omap3/lowlevel_init.S   |  8 
 arch/arm/cpu/armv7/rmobile/lowlevel_init.S |  6 --
 arch/arm/lib/crt0.S|  3 +++
 arch/arm/lib/reset.c   |  5 +
 board/ti/omap5912osk/lowlevel_init.S   | 11 ---
 6 files changed, 13 insertions(+), 43 deletions(-)

diff --git a/arch/arm/cpu/armv7/lowlevel_init.S 
b/arch/arm/cpu/armv7/lowlevel_init.S
index 82b2b86..1ec7481 100644
--- a/arch/arm/cpu/armv7/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/lowlevel_init.S
@@ -16,26 +16,5 @@
 #include linux/linkage.h
 
 ENTRY(lowlevel_init)
-   /*
-* Setup a temporary stack
-*/
-   ldr sp, =CONFIG_SYS_INIT_SP_ADDR
-   bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
-#ifdef CONFIG_SPL_BUILD
-   ldr r8, =gdata
-#else
-   sub sp, #GD_SIZE
-   bic sp, sp, #7
-   mov r8, sp
-#endif
-   /*
-* Save the old lr(passed in ip) and the current lr to stack
-*/
-   push{ip, lr}
-
-   /*
-* go setup pll, mux, memory
-*/
-   bl  s_init
-   pop {ip, pc}
+   mov pc, lr
 ENDPROC(lowlevel_init)
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S 
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index bdf74ea..db1d4dc 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -197,22 +197,22 @@ pll_div_val5:
 #endif
 
 ENTRY(lowlevel_init)
+#if !defined(CONFIG_SYS_NAND_BOOT)  !defined(CONFIG_SYS_ONENAND_BOOT)
ldr sp, SRAM_STACK
str ip, [sp]/* stash ip register */
mov ip, lr  /* save link reg across call */
-#if !defined(CONFIG_SYS_NAND_BOOT)  !defined(CONFIG_SYS_ONENAND_BOOT)
 /*
  * No need to copy/exec the clock code - DPLL adjust already done
  * in NAND/oneNAND Boot.
  */
ldr r1, =SRAM_CLK_CODE
bl  cpy_clk_code
-#endif /* NAND Boot */
+
mov lr, ip  /* restore link reg */
ldr ip, [sp]/* restore save ip */
-   /* tail-call s_init to setup pll, mux, memory */
-   b   s_init
+#endif /* NAND Boot */
 
+   mov pc, lr
 ENDPROC(lowlevel_init)
 
/* the literal pools origin */
diff --git a/arch/arm/cpu/armv7/rmobile/lowlevel_init.S 
b/arch/arm/cpu/armv7/rmobile/lowlevel_init.S
index ff18d96..70ec22d 100644
--- a/arch/arm/cpu/armv7/rmobile/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/rmobile/lowlevel_init.S
@@ -59,14 +59,8 @@ loop0:
subs r0, r0, #1
bne  loop0
 
-   ldr sp, MERAM_STACK
-   b s_init
-
.pool
.align 4
 
 ENDPROC(lowlevel_init)
.ltorg
-
-MERAM_STACK:
-   .word LOW_LEVEL_MERAM_STACK
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 960d12e..98d7881 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -70,6 +70,9 @@ ENTRY(_main)
sub sp, #GD_SIZE/* allocate one GD above SP */
bic sp, sp, #7  /* 8-byte alignment for ABI compliance */
mov r8, sp  /* GD is above SP */
+
+   bl  s_init
+
mov r0, #0
bl  board_init_f
 
diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
index 7a03580..d14eac9 100644
--- a/arch/arm/lib/reset.c
+++ b/arch/arm/lib/reset.c
@@ -35,3 +35,8 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
/*NOTREACHED*/
return 0;
 }
+
+/* HACK */
+__weak void s_init(void)
+{
+}
diff --git a/board/ti/omap5912osk/lowlevel_init.S 
b/board/ti/omap5912osk/lowlevel_init.S
index cad0a5a..61c8605 100644
--- a/board/ti/omap5912osk/lowlevel_init.S
+++ b/board/ti/omap5912osk/lowlevel_init.S
@@ -296,17 +296,6 @@ common_tc:
ldr sp, SRAM_STACK
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
 
-   /*
-* Save the old lr(passed in ip) and the current lr to stack
-*/
-   push{ip, lr}
-
-   /*
-* go setup pll, mux, memory
-*/
-   bl  s_init
-   pop {ip, pc}
-
/* back to arch calling code */
mov pc, lr
 
-- 
1.8.1.2

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

Re: [U-Boot] [RFC 1/3] ARM,crt0.S: call s_init instead from ctr0.S

2013-08-24 Thread Jeroen Hofstee 

On 08/24/2013 06:32 PM, Jeroen Hofstee wrote:

/* the literal pools origin */
diff --git a/arch/arm/cpu/armv7/rmobile/lowlevel_init.S 
b/arch/arm/cpu/armv7/rmobile/lowlevel_init.S
index ff18d96..70ec22d 100644
--- a/arch/arm/cpu/armv7/rmobile/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/rmobile/lowlevel_init.S
@@ -59,14 +59,8 @@ loop0:
subs r0, r0, #1
bne  loop0
  
-	ldr sp, MERAM_STACK

-   b s_init
-
right, this ^^^ will brick things nicely, how about returning to the 
caller...

.pool
.align 4
  
  ENDPROC(lowlevel_init)

.ltorg
-
-MERAM_STACK:
-   .word LOW_LEVEL_MERAM_STACK



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

Re: [U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?

2013-08-24 Thread Luka Perkov 
On Sat, Aug 24, 2013 at 07:37:00AM -0400, Robert P. J. Day wrote:
 On Sat, 24 Aug 2013, Luka Perkov wrote:
 
  On Sat, Aug 24, 2013 at 12:01:25AM -0400, Robert P. J. Day wrote:
   On Sat, 24 Aug 2013, Luka Perkov wrote:
/dev/mmcblk0 0x6 0x2000 0x2000
  
 ah, there's the misunderstanding. i thought we were discussing
   how to be able to refer *directly* to the eMMC partition boot1,
   as in /dev/mmcblk1boot1. it looks like what you're describing
   would refer instead simply to /dev/mmcblk1, correct?
 
  Even though the config is actually refering to /dev/mmcblk1 in fact
  it's writing/reading to /dev/mmcblk1p1 (or /dev/mmcblk1boot1) in
  your case. But you need to configure it properly for your MMC
  device.
 
   right, i can see that and that clarifies things for me. my
 *original* question was whether there was a way to set up
 /etc/fw_env.config to refer to the eMMC partition /dev/mmcblk1boot1
 *directly*, treating it as a regular block partition and bypassing all
 the MTD-related processing. (perhaps stefano can weigh in and say
 whether that's how he understood what i was asking.)
 
   if you instead refer to /dev/mmcblk1, as i understand it, you're
 just back to the standard MTD-based access, yes?
 
   anyway, sorry if i didn't explain myself clearly the first time.

AFAIK there is no fw_{printenv,setenv} support for MMC. Except if you
use the patches I pointed out. Somebody please correct me if I'm wrong.

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

Re: [U-Boot] Change of NDS32 Custodian

2013-08-24 Thread Mike Frysinger 
On Wednesday 31 July 2013 06:40:37 Marek Vasut wrote:
 Dear Macpaul Lin,
  Here is a short announcement about a change in the U-boot NDS32
  custodian.
  
  I have no longer working in Andes Technology Corporation and cannot
  provide the community the best support on NDS32 architecture.
  Kuan-Yu Kuo (a.k.a. Ken Kuo) will be the next custodian of u-boot-nds32
  branch.
  
  Thanks for the great support and co-working guide from Wolfgang, Tom,
  Po-Yu Chuang, Mike, Marek and many people.
  Thanks for your help which made the u-boot porting work of NDS32
  architecture becomes the first open source mainline contribution of
  NDS32.
  
  The official custodian e-mail of NDS32 will be changed to
  ub...@andestech.com. Ken will send the patchwork permission request,
  patches to MAINTAINERS file, and update the U-boot Wiki later.
 
 Was good having you around! Thank you for your efforts!

indeed ... it's been fun working with you Macpaul.  hopefully we can meet up 
at some point and have a beer.
-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