[U-Boot] [PATCH V2] This patch fix the usage of the CE don't care-type NAND chips
Change since V1: - add a better description Signed-off-by: Michael Trimarchi mich...@evidence.eu.com Cc: Scott Wood scottw...@freescale.com --- drivers/mtd/nand/atmel_nand.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c index ab8bbb3..c167f77 100644 --- a/drivers/mtd/nand/atmel_nand.c +++ b/drivers/mtd/nand/atmel_nand.c @@ -249,8 +249,18 @@ static void at91_nand_hwcontrol(struct mtd_info *mtd, if (ctrl NAND_ALE) IO_ADDR_W |= CONFIG_SYS_NAND_MASK_ALE; + /* +* atmel_nand: don't require CONFIG_SYS_NAND_ENABLE_PIN +* If NCE is hooked up to NCS3, we don't need to (and can't) +* explicitly set the state of the NCE pin. Instead, the +* controller asserts it automatically as part of a +* command/data access. Only CE don't care-type NAND chips +* can be used in this manner. +*/ +#ifdef CONFIG_SYS_NAND_ENABLE_PIN at91_set_gpio_value(CONFIG_SYS_NAND_ENABLE_PIN, !(ctrl NAND_NCE)); +#endif this-IO_ADDR_W = (void *) IO_ADDR_W; } -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] This patch fix the usage of the CE don't care-type NAND chips
Hi Michael, Le 23/02/2011 12:28, Michael Trimarchi a écrit : Change since V1: - add a better description History should not be put above the '---' cut line; it should be below. Signed-off-by: Michael Trimarchimich...@evidence.eu.com Cc: Scott Woodscottw...@freescale.com --- drivers/mtd/nand/atmel_nand.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) [...] Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] This patch fix the usage of the CE don't care-type NAND chips
Hi, On 02/23/2011 12:42 PM, Albert ARIBAUD wrote: Hi Michael, Le 23/02/2011 12:28, Michael Trimarchi a écrit : Change since V1: - add a better description History should not be put above the '---' cut line; it should be below. Signed-off-by: Michael Trimarchimich...@evidence.eu.com Cc: Scott Woodscottw...@freescale.com --- drivers/mtd/nand/atmel_nand.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) [...] I will edit the text and resend with mutt. do I need to change again revision? Michael Trimarchi Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] This patch fix the usage of the CE don't care-type NAND chips
Dear Michael Trimarchi, In message 4d64f927.1000...@gandalf.sssup.it you wrote: I will edit the text and resend with mutt. do I need to change again revision? Yes, please, as it's a new commit (commit message has changed). 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 Houston, Tranquillity Base here. The Eagle has landed. -- Neil Armstrong ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot support for Cortex-M3
Hello, Does U-boot have support for Cortex-M3? Or is it available in terms of patch, if yes how can I get it? It will be very helpful to me. Thanks, Pratik. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: OMAP3: Revamp IGEP default configuration
The default IGEP configuration doesn't do anything useful; using some
boot.scr search logic like BeagleBoard is much more useful.
Signed-off-by: Loïc Minier loic.min...@linaro.org
---
include/configs/igep0020.h | 55 ---
1 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/include/configs/igep0020.h b/include/configs/igep0020.h
index c19ecc0..2466562 100644
--- a/include/configs/igep0020.h
+++ b/include/configs/igep0020.h
@@ -130,13 +130,60 @@
#define CONFIG_TWL4030_POWER 1
/* Environment information */
-#define CONFIG_BOOTCOMMAND \
- mmc init 0 ; fatload mmc 0 0x8000 setup.ini ; source \0
-
#define CONFIG_BOOTDELAY 3
#define CONFIG_EXTRA_ENV_SETTINGS \
- usbtty=cdc_acm\0
+ loadaddr=0x8200\0 \
+ usbtty=cdc_acm\0 \
+ console=ttyS2,115200n8\0 \
+ mpurate=500\0 \
+ vram=12M\0 \
+ dvimode=1024x768MR-16@60\0 \
+ defaultdisplay=dvi\0 \
+ mmcdev=0\0 \
+ mmcroot=/dev/mmcblk0p2 rw\0 \
+ mmcrootfstype=ext3 rootwait\0 \
+ nandroot=/dev/mtdblock4 rw\0 \
+ nandrootfstype=jffs2\0 \
+ mmcargs=setenv bootargs console=${console} \
+ mpurate=${mpurate} \
+ vram=${vram} \
+ omapfb.mode=dvi:${dvimode} \
+ omapfb.debug=y \
+ omapdss.def_disp=${defaultdisplay} \
+ root=${mmcroot} \
+ rootfstype=${mmcrootfstype}\0 \
+ nandargs=setenv bootargs console=${console} \
+ mpurate=${mpurate} \
+ vram=${vram} \
+ omapfb.mode=dvi:${dvimode} \
+ omapfb.debug=y \
+ omapdss.def_disp=${defaultdisplay} \
+ root=${nandroot} \
+ rootfstype=${nandrootfstype}\0 \
+ loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0 \
+ bootscript=echo Running bootscript from mmc ...; \
+ source ${loadaddr}\0 \
+ loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
+ mmcboot=echo Booting from mmc ...; \
+ run mmcargs; \
+ bootm ${loadaddr}\0 \
+ nandboot=echo Booting from nand ...; \
+ run nandargs; \
+ nand read ${loadaddr} 28 40; \
+ bootm ${loadaddr}\0 \
+
+#define CONFIG_BOOTCOMMAND \
+ if mmc rescan ${mmcdev}; then \
+ if run loadbootscript; then \
+ run bootscript; \
+ else \
+ if run loaduimage; then \
+ run mmcboot; \
+ else run nandboot; \
+ fi; \
+ fi; \
+ else run nandboot; fi
#define CONFIG_AUTO_COMPLETE 1
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Updated Business List for 2011
Hi, Hope you are the right person to deal with on email list acquisition/ email campaigns. I'm sure you have a strong in-house database that you maintain, but do you have the accurate and updated information? Our latest verified index of lead that has been compiled is of Specific target audience across the globe for all industries. This would contain detailed information of each Decision Makers such as Contact Name, Company Name, Title, Phone Number, Fax Number, Revenue Size, Employee Size, Mailing Address, Country, SIC Code, Business Email Address and Technology Installed. Our services also include Email Appending, Data Appending, Client Profiling, phone marketing, Webinars/Webcast, Social media marketing and much more! I can send you few samples which is of no cost. If you wish to discuss further, please let me know a convenient time to call you. Alternatively, it would be great if you could, please forward this communication to the concerned department. Any business list: You name it, We have it ! Regards, Daphne Ray Market Coordinator | US Data - European Data - Asia Pacific Data - Email Append - Data Append - Technology Specific Data - Email Marketing | Should you wish not to receive any communication from us in future, please reply, with subject Leave Out ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Tegra2: add support for A9 CPU init
Albert, On Tue, Feb 22, 2011 at 4:57 PM, Albert ARIBAUD albert.arib...@free.fr wrote: Hi Tom, Le 23/02/2011 00:41, Tom Warren a écrit : Anyone willing to review this? I'd like to get it pulled in to Albert's arm repo ASAP. I should be able to review it during the week-end--not before, sorry. Thank you. That would be fine - no rush. Note however that since this is not a bugfix and it came after the merge window closed, it would go to u-boot-arm/next, not /master; it will go to u-boot-arm/master after the the upcoming release (and then to u-boot/master when the next merge window closes). Understood. Just wanted an ACK, etc. so I can sign off on the CPU work and move on to the drivers. Thanks, Tom Amicalement, -- Albert. Thanks for your help, Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2 1/5] e1000: Clean up handling of dual-port NICs and support 82571
Consolidate the test for a dual-port NIC to one location for easy
modification, then fix support for the dual-port 82571.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
Cc: Ben Warren biggerbadder...@gmail.com
---
No changes since v1
drivers/net/e1000.c | 66 +-
drivers/net/e1000.h |6
2 files changed, 33 insertions(+), 39 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 5f390bd..5383064 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -1096,6 +1096,20 @@ e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t
mask)
return E1000_SUCCESS;
}
+static boolean_t e1000_is_second_port(struct e1000_hw *hw)
+{
+ switch (hw-mac_type) {
+ case e1000_80003es2lan:
+ case e1000_82546:
+ case e1000_82571:
+ if (E1000_READ_REG(hw, STATUS) E1000_STATUS_FUNC_1)
+ return TRUE;
+ /* Fallthrough */
+ default:
+ return FALSE;
+ }
+}
+
/**
* Reads the adapter's MAC address from the EEPROM and inverts the LSB for the
* second function of dual function devices
@@ -1122,11 +1136,11 @@ e1000_read_mac_addr(struct eth_device *nic)
nic-enetaddr[i] = eeprom_data 0xff;
nic-enetaddr[i + 1] = (eeprom_data 8) 0xff;
}
- if ((hw-mac_type == e1000_82546)
- (E1000_READ_REG(hw, STATUS) E1000_STATUS_FUNC_1)) {
- /* Invert the last bit if this is the second device */
- nic-enetaddr[5] += 1;
- }
+
+ /* Invert the last bit if this is the second device */
+ if (e1000_is_second_port(hw))
+ nic-enetaddr[5] ^= 1;
+
#ifdef CONFIG_E1000_FALLBACK_MAC
if ( *(u32*)(nic-enetaddr) == 0 || *(u32*)(nic-enetaddr) == ~0 ) {
unsigned char fb_mac[NODE_ADDRESS_SIZE] =
CONFIG_E1000_FALLBACK_MAC;
@@ -2528,16 +2542,13 @@ e1000_check_mng_mode(struct e1000_hw *hw)
static int32_t
e1000_write_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr, uint16_t data)
{
+ uint16_t swfw = E1000_SWFW_PHY0_SM;
uint32_t reg_val;
- uint16_t swfw;
DEBUGFUNC();
- if ((hw-mac_type == e1000_80003es2lan)
- (E1000_READ_REG(hw, STATUS) E1000_STATUS_FUNC_1)) {
+ if (e1000_is_second_port(hw))
swfw = E1000_SWFW_PHY1_SM;
- } else {
- swfw = E1000_SWFW_PHY0_SM;
- }
+
if (e1000_swfw_sync_acquire(hw, swfw))
return -E1000_ERR_SWFW_SYNC;
@@ -2552,16 +2563,13 @@ e1000_write_kmrn_reg(struct e1000_hw *hw, uint32_t
reg_addr, uint16_t data)
static int32_t
e1000_read_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr, uint16_t *data)
{
+ uint16_t swfw = E1000_SWFW_PHY0_SM;
uint32_t reg_val;
- uint16_t swfw;
DEBUGFUNC();
- if ((hw-mac_type == e1000_80003es2lan)
- (E1000_READ_REG(hw, STATUS) E1000_STATUS_FUNC_1)) {
+ if (e1000_is_second_port(hw))
swfw = E1000_SWFW_PHY1_SM;
- } else {
- swfw = E1000_SWFW_PHY0_SM;
- }
+
if (e1000_swfw_sync_acquire(hw, swfw))
return -E1000_ERR_SWFW_SYNC;
@@ -4259,11 +4267,13 @@ e1000_get_phy_cfg_done(struct e1000_hw *hw)
default:
mdelay(10);
break;
+
case e1000_80003es2lan:
/* Separate *_CFG_DONE_* bit for each port */
- if (E1000_READ_REG(hw, STATUS) E1000_STATUS_FUNC_1)
+ if (e1000_is_second_port(hw))
cfg_mask = E1000_EEPROM_CFG_DONE_PORT_1;
- /* Fall Through */
+ /* Fall Through */
+
case e1000_82571:
case e1000_82572:
while (timeout) {
@@ -4292,10 +4302,10 @@ e1000_get_phy_cfg_done(struct e1000_hw *hw)
int32_t
e1000_phy_hw_reset(struct e1000_hw *hw)
{
+ uint16_t swfw = E1000_SWFW_PHY0_SM;
uint32_t ctrl, ctrl_ext;
uint32_t led_ctrl;
int32_t ret_val;
- uint16_t swfw;
DEBUGFUNC();
@@ -4308,16 +4318,14 @@ e1000_phy_hw_reset(struct e1000_hw *hw)
DEBUGOUT(Resetting Phy...\n);
if (hw-mac_type e1000_82543) {
- if ((hw-mac_type == e1000_80003es2lan)
- (E1000_READ_REG(hw, STATUS) E1000_STATUS_FUNC_1)) {
+ if (e1000_is_second_port(hw))
swfw = E1000_SWFW_PHY1_SM;
- } else {
- swfw = E1000_SWFW_PHY0_SM;
- }
+
if (e1000_swfw_sync_acquire(hw, swfw)) {
DEBUGOUT(Unable to acquire swfw sync\n);
return -E1000_ERR_SWFW_SYNC;
}
+
/* Read the device control register and assert the
E1000_CTRL_PHY_RST
* bit. Then, take it out of reset.
[U-Boot] [PATCHv2 2/5] e1000: Restructure and streamline PCI device probing
By allocating the e1000 device structures much earlier, we can easily
generate better error messages and siginficantly clean things up.
The only user-visable change (aside from reworded error messages) is
that a detected e1000 device which fails to initialize due to software
or hardware error will still be allocated a device number.
As one example, consider a system with 2 e1000 PCI devices where the
first controller has a corrupted EEPROM. Using the old code the
second controller would be e1000#0, while with this change it would be
e1000#1.
This change should hopefully make such EEPROM errors much more
straightforward to handle correctly in boot scripts and the like.
It is also necessary for a followup patch which allows SPI programming
of an e1000 controller's EEPROM even if the checksum is invalid.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
Cc: Ben Warren biggerbadder...@gmail.com
---
Changelog:
v2: Cleaned up the boot-time probe output a bit
drivers/net/e1000.c | 119 +--
drivers/net/e1000.h |3 +
2 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 5383064..38eed37 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -65,7 +65,7 @@ static struct e1000_rx_desc *rx_base;
static int tx_tail;
static int rx_tail, rx_last;
-static struct pci_device_id supported[] = {
+static struct pci_device_id e1000_supported[] = {
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82542},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82543GC_FIBER},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82543GC_COPPER},
@@ -4746,7 +4746,7 @@ e1000_set_media_type(struct e1000_hw *hw)
**/
static int
-e1000_sw_init(struct eth_device *nic, int cardnum)
+e1000_sw_init(struct eth_device *nic)
{
struct e1000_hw *hw = (typeof(hw)) nic-priv;
int result;
@@ -5146,57 +5146,59 @@ You should omit the last argument struct pci_device *
for a non-PCI NIC
int
e1000_initialize(bd_t * bis)
{
+ unsigned int i;
pci_dev_t devno;
- int card_number = 0;
- struct eth_device *nic = NULL;
- struct e1000_hw *hw = NULL;
- u32 iobase;
- int idx = 0;
- u32 PciCommandWord;
DEBUGFUNC();
- while (1) { /* Find PCI device(s) */
- if ((devno = pci_find_devices(supported, idx++)) 0) {
- break;
- }
-
- pci_read_config_dword(devno, PCI_BASE_ADDRESS_0, iobase);
- iobase = ~0xf; /* Mask the bits that say this is an io addr
*/
- DEBUGOUT(e1000#%d: iobase 0x%08x\n, card_number, iobase);
-
- pci_write_config_dword(devno, PCI_COMMAND,
- PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
- /* Check if I/O accesses and Bus Mastering are enabled. */
- pci_read_config_dword(devno, PCI_COMMAND, PciCommandWord);
- if (!(PciCommandWord PCI_COMMAND_MEMORY)) {
- printf(Error: Can not enable MEM access.\n);
- continue;
- } else if (!(PciCommandWord PCI_COMMAND_MASTER)) {
- printf(Error: Can not enable Bus Mastering.\n);
- continue;
- }
-
- nic = (struct eth_device *) malloc(sizeof (*nic));
- if (!nic) {
- printf(Error: e1000 - Can not alloc memory\n);
- return 0;
- }
+ /* Find and probe all the matching PCI devices */
+ for (i = 0; (devno = pci_find_devices(e1000_supported, i)) = 0; i++) {
+ u32 val;
- hw = (struct e1000_hw *) malloc(sizeof (*hw));
- if (!hw) {
+ /*
+* These will never get freed due to errors, this allows us to
+* perform SPI EEPROM programming from U-boot, for example.
+*/
+ struct eth_device *nic = malloc(sizeof(*nic));
+ struct e1000_hw *hw = malloc(sizeof(*hw));
+ if (!nic || !hw) {
+ printf(e1000#%u: Out of Memory!\n, i);
free(nic);
- printf(Error: e1000 - Can not alloc memory\n);
- return 0;
+ free(hw);
+ continue;
}
+ /* Make sure all of the fields are initially zeroed */
memset(nic, 0, sizeof(*nic));
memset(hw, 0, sizeof(*hw));
+ /* Assign the passed-in values */
+ hw-cardnum = i;
hw-pdev = devno;
+ hw-nic = nic;
nic-priv = hw;
- sprintf(nic-name, e1000#%d, card_number);
+ /* Generate a card name */
+ sprintf(nic-name, e1000#%u, hw-cardnum);
+
+
[U-Boot] [PATCHv2 4/5] e1000: New e1000 commands for SPI EEPROM management
For our new board ports, we are programming the EEPROMs attached to our
Intel 82571EB controllers from software (using U-Boot and Linux).
This code provides a helpful set of e1000 subcommands for performing
EEPROM manipulation on e1000 devices, including displaying a hex-dump,
copying to and from main memory, and verifying/updating of the software
checksum.
The following commands work for programming the EEPROM from USB:
usb start
fatload usb 0 $loadaddr 82571EB_No_Mgmt_Discrete-LOM.bin
e1000 0 eeprom program $loadaddr 0 1024
e1000 0 eeprom checksum update
Please keep in mind that the Intel-provided .eep files are organized as
16-bit words. When converting them to binary form for programming you
must byteswap each 16-bit word so that it is in little-endian form.
This means that when reading and writing words to the SPI EEPROM, the
bit ordering for each word looks like this on the wire:
Time
--
... [7, 6, 5, 4, 3, 2, 1, 0, 15, 14, 13, 12, 11, 10, 9, 8], ...
--
(MSB is 15, LSB is 0).
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
Cc: Ben Warren biggerbadder...@gmail.com
---
Changelog:
v2: Removed a couple leftover debug messages
drivers/net/e1000.c | 527 ++-
drivers/net/e1000.h |2 +
2 files changed, 528 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 5d957ad..48129cc 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -5153,6 +5153,8 @@ void e1000_get_bus_type(struct e1000_hw *hw)
}
}
+static LIST_HEAD(e1000_hw_list);
+
/**
PROBE - Look for an adapter, this routine's visible to the outside
You should omit the last argument struct pci_device * for a non-PCI NIC
@@ -5231,8 +5233,9 @@ e1000_initialize(bd_t * bis)
if (e1000_check_phy_reset_block(hw))
printf(%s: ERROR: PHY Reset is blocked!\n, nic-name);
- /* Basic init was OK, reset the hardware */
+ /* Basic init was OK, reset the hardware and allow SPI access */
e1000_reset_hw(hw);
+ list_add_tail(hw-list_node, e1000_hw_list);
/* Validate the EEPROM and get chipset information */
#if !(defined(CONFIG_AP1000) || defined(CONFIG_MVBC_1G))
@@ -5260,3 +5263,525 @@ e1000_initialize(bd_t * bis)
return i;
}
+
+#ifdef CONFIG_CMD_E1000
+static struct e1000_hw *e1000_find_card(unsigned int cardnum)
+{
+ struct e1000_hw *hw;
+
+ list_for_each_entry(hw, e1000_hw_list, list_node)
+ if (hw-cardnum == cardnum)
+ return hw;
+
+ return NULL;
+}
+
+/*---
+ * SPI transfer
+ *
+ * This writes bitlen bits out the SPI MOSI port and simultaneously clocks
+ * bitlen bits in the SPI MISO port. That's just the way SPI works.
+ *
+ * The source of the outgoing bits is the dout parameter and the
+ * destination of the input bits is the din parameter. Note that dout
+ * and din can point to the same memory location, in which case the
+ * input data overwrites the output data (since both are buffered by
+ * temporary variables, this is OK).
+ *
+ * This may be interrupted with Ctrl-C if intr is true, otherwise it will
+ * never return an error.
+ */
+static int e1000_spi_xfer(struct e1000_hw *hw, unsigned int bitlen,
+ const void *dout_mem, void *din_mem, boolean_t intr)
+{
+ const uint8_t *dout = dout_mem;
+ uint8_t *din = din_mem;
+
+ uint8_t mask = 0;
+ uint32_t eecd;
+ unsigned long i;
+
+ /* Pre-read the control register */
+ eecd = E1000_READ_REG(hw, EECD);
+
+ /* Iterate over each bit */
+ for (i = 0, mask = 0x80; i bitlen; i++, mask = (mask 1)?:0x80) {
+ /* Check for interrupt */
+ if (intr ctrlc())
+ return -1;
+
+ /* Determine the output bit */
+ if (dout dout[i 3] mask)
+ eecd |= E1000_EECD_DI;
+ else
+ eecd = ~E1000_EECD_DI;
+
+ /* Write the output bit and wait 50us */
+ E1000_WRITE_REG(hw, EECD, eecd);
+ E1000_WRITE_FLUSH(hw);
+ udelay(50);
+
+ /* Poke the clock (waits 50us) */
+ e1000_raise_ee_clk(hw, eecd);
+
+ /* Now read the input bit */
+ eecd = E1000_READ_REG(hw, EECD);
+ if (din) {
+ if (eecd E1000_EECD_DO)
+ din[i 3] |= mask;
+ else
+ din[i 3] = ~mask;
+ }
+
+ /* Poke the clock again (waits 50us) */
+
[U-Boot] [PATCHv2 5/5] e1000: Add a small SPI driver wrapper around the EEPROM code
To make it possible to use the sspi command with the e1000 firmware
EEPROM we add a small generic SPI driver wrapper around the existing
e1000 SPI backend.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
Cc: Ben Warren biggerbadder...@gmail.com
---
No changes since v1
drivers/net/e1000.c | 92 ++-
drivers/net/e1000.h |7
2 files changed, 98 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 48129cc..82ca055 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -5264,7 +5264,7 @@ e1000_initialize(bd_t * bis)
return i;
}
-#ifdef CONFIG_CMD_E1000
+#if defined(CONFIG_E1000_SPI) || defined(CONFIG_CMD_E1000)
static struct e1000_hw *e1000_find_card(unsigned int cardnum)
{
struct e1000_hw *hw;
@@ -5343,6 +5343,96 @@ static int e1000_spi_xfer(struct e1000_hw *hw, unsigned
int bitlen,
return 0;
}
+#endif /* defined(CONFIG_E1000_SPI) || defined(CONFIG_CMD_E1000) */
+
+#ifdef CONFIG_E1000_SPI
+static inline struct e1000_hw *e1000_hw_from_spi(struct spi_slave *spi)
+{
+ return container_of(spi, struct e1000_hw, spi);
+}
+
+/* Not sure why all of these are necessary */
+void spi_init_r(void) { /* Nothing to do */ }
+void spi_init_f(void) { /* Nothing to do */ }
+void spi_init(void) { /* Nothing to do */ }
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+ unsigned int max_hz, unsigned int mode)
+{
+ /* Find the right PCI device */
+ struct e1000_hw *hw = e1000_find_card(bus);
+ if (!hw) {
+ printf(ERROR: No such e1000 device: e1000#%u\n, bus);
+ return NULL;
+ }
+
+ /* Make sure it has an SPI chip */
+ if (hw-eeprom.type != e1000_eeprom_spi) {
+ printf(%s: No attached SPI EEPROM found!\n, hw-nic-name);
+ return NULL;
+ }
+
+ /* Argument sanity checks */
+ if (cs != 0) {
+ printf(%s: No such SPI chip: %u\n, hw-nic-name, cs);
+ return NULL;
+ }
+ if (mode != SPI_MODE_0) {
+ printf(%s: Cannot support SPI modes other than MODE-0\n,
+ hw-nic-name);
+ return NULL;
+ }
+
+ /* TODO: Use max_hz somehow */
+ printf(%s: EEPROM SPI access requested\n, hw-nic-name);
+ return hw-spi;
+}
+
+void spi_free_slave(struct spi_slave *spi)
+{
+ struct e1000_hw *hw = e1000_hw_from_spi(spi);
+ printf(%s: EEPROM SPI access released\n, hw-nic-name);
+}
+
+int spi_claim_bus(struct spi_slave *spi)
+{
+ struct e1000_hw *hw = e1000_hw_from_spi(spi);
+
+ if (e1000_acquire_eeprom(hw)) {
+ printf(%s: EEPROM SPI cannot be acquired!, hw-nic-name);
+ return -1;
+ }
+
+ return 0;
+}
+
+void spi_release_bus(struct spi_slave *spi)
+{
+ struct e1000_hw *hw = e1000_hw_from_spi(spi);
+ e1000_release_eeprom(hw);
+}
+
+/* Skinny wrapper around e1000_spi_xfer */
+int spi_xfer(struct spi_slave *spi, unsigned int bitlen,
+ const void *dout_mem, void *din_mem, unsigned long flags)
+{
+ struct e1000_hw *hw = e1000_hw_from_spi(spi);
+ int ret;
+
+ if (flags SPI_XFER_BEGIN)
+ e1000_standby_eeprom(hw);
+
+ ret = e1000_spi_xfer(hw, bitlen, dout_mem, din_mem, TRUE);
+
+ if (flags SPI_XFER_END)
+ e1000_standby_eeprom(hw);
+
+ return ret;
+}
+
+#endif /* CONFIG_E1000_SPI */
+
+#ifdef CONFIG_CMD_E1000
/* The EEPROM opcodes */
#define SPI_EEPROM_ENABLE_WR 0x06
diff --git a/drivers/net/e1000.h b/drivers/net/e1000.h
index 68a3409..f504c90 100644
--- a/drivers/net/e1000.h
+++ b/drivers/net/e1000.h
@@ -41,6 +41,10 @@
#include asm/io.h
#include pci.h
+#ifdef CONFIG_E1000_SPI
+#include spi.h
+#endif
+
#define E1000_ERR(args...) printf(e1000: args)
#ifdef E1000_DEBUG
@@ -1046,6 +1050,9 @@ typedef enum {
struct e1000_hw {
struct list_head list_node;
struct eth_device *nic;
+#ifdef CONFIG_E1000_SPI
+ struct spi_slave spi;
+#endif
unsigned int cardnum;
pci_dev_t pdev;
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2] fdt_support: Fix buffer overflow in fdt_fixup_memory_banks
When fdt_fixup_memory_banks is called with 2-cell address and size
fields in the device-tree (IE: 64-bit address and size), then it will
overflow its on-stack tmp buffer.
This fixes the buffer size and adds a comment explaining how many bytes
need to be allocated per record.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
Cc: Jerry Van Baren vanba...@cideas.com
---
Changelog:
v2: Resubmitted separately from the other HWW-1U-1A changes.
common/fdt_support.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 6c98e5b..edcf04a 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -394,7 +394,7 @@ int fdt_fixup_memory_banks(void *blob, u64 start[], u64
size[], int banks)
{
int err, nodeoffset;
int addr_cell_len, size_cell_len, len;
- u8 tmp[banks * 8];
+ u8 tmp[banks * 16]; /* Up to 64-bit address + 64-bit size */
int bank;
err = fdt_check_header(blob);
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] This patch fix the usage of the CE don't care-type NAND chips
On Wed, 23 Feb 2011 12:28:34 +0100 Michael Trimarchi trimar...@gandalf.sssup.it wrote: Change since V1: - add a better description This part does not go in the changelog -- it should be below the --- line. Signed-off-by: Michael Trimarchi mich...@evidence.eu.com Cc: Scott Wood scottw...@freescale.com --- drivers/mtd/nand/atmel_nand.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c index ab8bbb3..c167f77 100644 --- a/drivers/mtd/nand/atmel_nand.c +++ b/drivers/mtd/nand/atmel_nand.c @@ -249,8 +249,18 @@ static void at91_nand_hwcontrol(struct mtd_info *mtd, if (ctrl NAND_ALE) IO_ADDR_W |= CONFIG_SYS_NAND_MASK_ALE; + /* + * atmel_nand: don't require CONFIG_SYS_NAND_ENABLE_PIN + * If NCE is hooked up to NCS3, we don't need to (and can't) + * explicitly set the state of the NCE pin. Instead, the + * controller asserts it automatically as part of a + * command/data access. Only CE don't care-type NAND chips + * can be used in this manner. + */ This was meant for the changelog, not the code. For the code, it seems reasonably self-explanatory that if you don't have CONFIG_SYS_NAND_ENABLE_PIN, you don't use it. If you want to put a short comment in the code about this situation, fine (though it really belongs in a README that documents CONFIG_SYS_NAND_ENABLE_PIN instead), but the text above should go in the git changelog. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2] fsl_ddr: Don't use full 64-bit divides on 32-bit PowerPC
The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit
integer divide operations to convert between nanoseconds and DDR clock
cycles given arbitrary DDR clock frequencies.
Since all of the inputs to this are 32-bit (nanoseconds, clock cycles,
and DDR frequencies), we can easily restructure the computation to use
the do_div() function to perform 64-bit/32-bit divide operations.
This decreases compute time rather significantly for each conversion and
avoids bringing in a very complicated function from libgcc.
It should be noted that nothing else in U-Boot or the Linux kernel seems
to require a full 64-bit divide on any 32-bit PowerPC.
Build-and-boot-tested on the HWW-1U-1A board using DDR2 SPD detection.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
Cc: Andy Fleming aflem...@gmail.com
Cc: Kumar Gala kumar.g...@freescale.com
Cc: Wolfgang Denk w...@denx.de
Cc: Kim Phillips kim.phill...@freescale.com
---
Ok, so this patch touches a rather sensitive part of the fsl_ddr logic.
I spent a fair amount of time trying to verify that the resulting math is
exactly the same as it was before, but the consequences of a mistake are
insideous timing problems. Additional in-depth review would be much
appreciated.
Cheers,
Kyle Moffett
Changelog:
v2: Resubmitted separately from the other HWW-1U-1A patches
arch/powerpc/cpu/mpc8xxx/ddr/util.c | 58 --
1 files changed, 41 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/util.c
b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
index 1e2d921..c545d59 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/util.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
@@ -8,11 +8,19 @@
#include common.h
#include asm/fsl_law.h
+#include div64.h
#include ddr.h
unsigned int fsl_ddr_get_mem_data_rate(void);
+/* To avoid 64-bit full-divides, we factor this here */
+#define ULL_2e12 2ULL
+#define UL_5pow12 244140625UL
+#define UL_2pow13 (1UL 13)
+
+#define ULL_8Fs 0xULL
+
/*
* Round mclk_ps to nearest 10 ps in memory controller code.
*
@@ -22,36 +30,52 @@ unsigned int fsl_ddr_get_mem_data_rate(void);
*/
unsigned int get_memory_clk_period_ps(void)
{
- unsigned int mclk_ps;
+ unsigned int data_rate = fsl_ddr_get_mem_data_rate();
+ unsigned int result;
+
+ /* Round to nearest 10ps, being careful about 64-bit multiply/divide */
+ unsigned long long mclk_ps = ULL_2e12;
- mclk_ps = 2ULL / fsl_ddr_get_mem_data_rate();
- /* round to nearest 10 ps */
- return 10 * ((mclk_ps + 5) / 10);
+ /* Add 5*data_rate, for rounding */
+ mclk_ps += 5*(unsigned long long)data_rate;
+
+ /* Now perform the big divide, the result fits in 32-bits */
+ do_div(mclk_ps, data_rate);
+ result = mclk_ps;
+
+ /* We still need to round to 10ps */
+ return 10 * (result/10);
}
/* Convert picoseconds into DRAM clock cycles (rounding up if needed). */
unsigned int picos_to_mclk(unsigned int picos)
{
- const unsigned long long ULL_2e12 = 2ULL;
- const unsigned long long ULL_8Fs = 0xULL;
- unsigned long long clks;
- unsigned long long clks_temp;
+ unsigned long long clks, clks_rem;
+ /* Short circuit for zero picos */
if (!picos)
return 0;
- clks = fsl_ddr_get_mem_data_rate() * (unsigned long long) picos;
- clks_temp = clks;
- clks = clks / ULL_2e12;
- if (clks_temp % ULL_2e12) {
+ /* First multiply the time by the data rate (32x32 = 64) */
+ clks = picos * (unsigned long long)fsl_ddr_get_mem_data_rate();
+
+ /*
+* Now divide by 5^12 and track the 32-bit remainder, then divide
+* by 2*(2^12) using shifts (and updating the remainder).
+*/
+ clks_rem = do_div(clks, UL_5pow12);
+ clks_rem = 13;
+ clks_rem |= clks (UL_2pow13-1);
+ clks = 13;
+
+ /* If we had a remainder, then round up */
+ if (clks_rem)
clks++;
- }
- if (clks ULL_8Fs) {
+ /* Clamp to the maximum representable value */
+ if (clks ULL_8Fs)
clks = ULL_8Fs;
- }
-
- return (unsigned int) clks;
+ return (unsigned int)clks;
}
unsigned int mclk_to_picos(unsigned int mclk)
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Tegra2 Seaboard: Fix mach_type to match mach-type.h update
Seaboard build stopped working due to Sandeep's recent mach-types.h update to match the Linux kernel. Change Seaboard to use MACH_TYPE_SEABOARD. Tom Warren (1): arm: Tegra2: Change mach-type to MACH_TYPE_SEABOARD due to mach-types.h update include/configs/seaboard.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: Tegra2: Change mach-type to MACH_TYPE_SEABOARD due to mach-types.h update
Signed-off-by: Tom Warren twar...@nvidia.com --- include/configs/seaboard.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h index fd87560..59eef56 100644 --- a/include/configs/seaboard.h +++ b/include/configs/seaboard.h @@ -37,7 +37,7 @@ #define CONFIG_TEGRA2_ENABLE_UARTD #define CONFIG_SYS_NS16550_COM1NV_PA_APB_UARTD_BASE -#define CONFIG_MACH_TYPE MACH_TYPE_TEGRA_SEABOARD +#define CONFIG_MACH_TYPE MACH_TYPE_SEABOARD #define CONFIG_SYS_BOARD_ODMDATA 0x300d8011 /* lp1, 1GB */ #endif /* __CONFIG_H */ -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot support for Cortex-M3
Am Wednesday 23 February 2011 13:53:53 schrieb pratik pujar: Hello, Does U-boot have support for Cortex-M3? Cortex M3 is a CPU architecture, not a specific CPU or board type. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot support for Cortex-M3
Le 23/02/2011 18:36, Thorsten Mühlfelder a écrit : Am Wednesday 23 February 2011 13:53:53 schrieb pratik pujar: Hello, Does U-boot have support for Cortex-M3? Cortex M3 is a CPU architecture, not a specific CPU or board type. Not exactly. M3 is a core; the architecture in ARM parlance is armv7-M. Still, what does your statement try to imply? I don't think U-Boot has support for M3, but that's not related to M3 being a core. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot support for Cortex-M3
Dear Albert: Let me try. U-Boot is a board oriented bootloader. So, with that said, can you tell us what boards might use an M3 or armv7-M? When I say boards, I mean those boards one can buy from Freescale, Intel, TI, Digikey or others. Given a board name, it gets easier to answer your question. Charles On Wed, Feb 23, 2011 at 11:21 AM, Albert ARIBAUD albert.arib...@free.frwrote: Le 23/02/2011 18:36, Thorsten Mühlfelder a écrit : Am Wednesday 23 February 2011 13:53:53 schrieb pratik pujar: Hello, Does U-boot have support for Cortex-M3? Cortex M3 is a CPU architecture, not a specific CPU or board type. Not exactly. M3 is a core; the architecture in ARM parlance is armv7-M. Still, what does your statement try to imply? I don't think U-Boot has support for M3, but that's not related to M3 being a core. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Charles Krinke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/4] mpc85xx: Add inline GPIO acessor functions
To ease the implementation of other MPC85xx board ports, several common
GPIO helpers are added to asm/mpc85xx_gpio.h.
Since each of these compiles to no more than 4-5 instructions it would
be very inefficient to call them out of line, therefore we put them
entirely in the header file.
The HWW-1U-1A board port which these were written for strongly prefers
to set multiple GPIOs as a single batch operation, so the API is
designed around that basis.
To assist other board ports, a small set of wrappers are used which
provides a standard gpio_request() interface around the MPC85xx-specific
functions. This can be enabled with CONFIG_MPC85XX_GENERIC_GPIO
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
Cc: Andy Fleming aflem...@gmail.com
Cc: Kumar Gala kumar.g...@freescale.com
Cc: Peter Tyser pty...@xes-inc.com
---
Changelog:
v2: Moved the inline functions to a non-board-specific header
v3: Added generic Linux-standard GPIO wrappers
v4: Improved comments and fixed minor bugs in the wrapper functions
arch/powerpc/include/asm/mpc85xx_gpio.h | 120 +++
1 files changed, 120 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/mpc85xx_gpio.h
diff --git a/arch/powerpc/include/asm/mpc85xx_gpio.h
b/arch/powerpc/include/asm/mpc85xx_gpio.h
new file mode 100644
index 000..ad54b4e
--- /dev/null
+++ b/arch/powerpc/include/asm/mpc85xx_gpio.h
@@ -0,0 +1,120 @@
+/*
+ * Copyright 2010 eXMeritus, A Boeing Company
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include asm/immap_85xx.h
+
+/*
+ * The following internal functions are an MPC85XX-specific GPIO API which
+ * allows setting and querying multiple GPIOs in a single operation.
+ *
+ * All of these look relatively large, but the arguments are almost always
+ * constants, so they compile down to just a few instructions and a
+ * memory-mapped IO operation or two.
+ */
+static inline void mpc85xx_gpio_set(unsigned int mask,
+ unsigned int dir, unsigned int val)
+{
+ ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
+
+ /* First mask off the unwanted parts of dir and val */
+ dir = mask;
+ val = mask;
+
+ /* Now read in the values we're supposed to preserve */
+ dir |= (in_be32(gpio-gpdir) ~mask);
+ val |= (in_be32(gpio-gpdat) ~mask);
+
+ /*
+* Poke the new output values first, then set the direction. This
+* helps to avoid transient data when switching from input to output
+* and vice versa.
+*/
+ out_be32(gpio-gpdat, val);
+ out_be32(gpio-gpdir, dir);
+}
+
+static inline void mpc85xx_gpio_set_in(unsigned int gpios)
+{
+ mpc85xx_gpio_set(gpios, 0x, 0x);
+}
+
+static inline void mpc85xx_gpio_set_low(unsigned int gpios)
+{
+ mpc85xx_gpio_set(gpios, 0x, 0x);
+}
+
+static inline void mpc85xx_gpio_set_high(unsigned int gpios)
+{
+ mpc85xx_gpio_set(gpios, 0x, 0x);
+}
+
+static inline unsigned int mpc85xx_gpio_get(unsigned int mask)
+{
+ ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
+
+ /* Read the requested values */
+ return in_be32(gpio-gpdat) mask;
+}
+
+/*
+ * These implement the generic Linux GPIO API on top of the other functions
+ * in this header.
+ */
+#ifdef CONFIG_MPC85XX_GENERIC_GPIO
+static inline int gpio_request(unsigned gpio, const char *label)
+{
+ /* Compatibility shim */
+ return 0;
+}
+
+static inline void gpio_free(unsigned gpio)
+{
+ /* Compatibility shim */
+}
+
+static inline int gpio_direction_input(unsigned gpio)
+{
+ mpc85xx_gpio_set_in(1U gpio);
+ return 0;
+}
+
+static inline int gpio_direction_output(unsigned gpio, int value)
+{
+ mpc85xx_gpio_set_low(1U gpio);
+ return 0;
+}
+
+static inline int gpio_get_value(unsigned gpio)
+{
+ return !!mpc85xx_gpio_get(1U gpio)
+}
+
+static inline void gpio_set_value(unsigned gpio, int value)
+{
+ if (value)
+ mpc85xx_gpio_set_high(1U gpio);
+ else
+ mpc85xx_gpio_set_low(1U gpio);
+}
+
+static inline int gpio_is_valid(int gpio)
+{
+ return (gpio = 0) (gpio 32);
+}
+#endif /* CONFIG_MPC85XX_GENERIC_GPIO */
--
1.7.2.3
[U-Boot] [PATCH v4 2/4] mpc8xxx: DDR2/DDR3: Clean up DIMM-type switch statements
The numeric constants in the switch statements are replaced by #defines
added to the common ddr_spd.h header. This dramatically improves the
readability of the switch statments.
In addition, a few of the longer lines were cleaned up, and the DDR2
type for an SO-RDIMM module was added to the DDR2 switch statement.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
Cc: Andy Fleming aflem...@gmail.com
Cc: Kumar Gala kumar.g...@freescale.com
Cc: Kim Phillips kim.phill...@freescale.com
Cc: Wolfgang Denk w...@denx.de
---
Changelog:
v2: Moved the constants to include/ddr_spd.h and also fixed DDR3.
v3: No changes
v4: Fixed up excessively long lines
arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c | 23 +++-
arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c | 43 ++
common/ddr_spd.c|2 +-
include/ddr_spd.h | 28 ++-
4 files changed, 53 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
b/arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
index dcb37ce..b565e33 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
@@ -250,24 +250,27 @@ ddr_compute_dimm_parameters(const ddr2_spd_eeprom_t *spd,
pdimm-primary_sdram_width = spd-primw;
pdimm-ec_sdram_width = spd-ecw;
- /* FIXME: what about registered SO-DIMM? */
+ /* These are all the types defined by the JEDEC DDR2 SPD 1.3 spec */
switch (spd-dimm_type) {
- case 0x01: /* RDIMM */
- case 0x10: /* Mini-RDIMM */
- pdimm-registered_dimm = 1; /* register buffered */
+ case DDR2_SPD_DIMMTYPE_RDIMM:
+ case DDR2_SPD_DIMMTYPE_72B_SO_RDIMM:
+ case DDR2_SPD_DIMMTYPE_MINI_RDIMM:
+ /* Registered/buffered DIMMs */
+ pdimm-registered_dimm = 1;
break;
- case 0x02: /* UDIMM */
- case 0x04: /* SO-DIMM */
- case 0x08: /* Micro-DIMM */
- case 0x20: /* Mini-UDIMM */
- pdimm-registered_dimm = 0; /* unbuffered */
+ case DDR2_SPD_DIMMTYPE_UDIMM:
+ case DDR2_SPD_DIMMTYPE_SO_DIMM:
+ case DDR2_SPD_DIMMTYPE_MICRO_DIMM:
+ case DDR2_SPD_DIMMTYPE_MINI_UDIMM:
+ /* Unbuffered DIMMs */
+ pdimm-registered_dimm = 0;
break;
+ case DDR2_SPD_DIMMTYPE_72B_SO_CDIMM:
default:
printf(unknown dimm_type 0x%02X\n, spd-dimm_type);
return 1;
- break;
}
/* SDRAM device parameters */
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
b/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
index 29cea53..756b15f 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
@@ -128,24 +128,32 @@ ddr_compute_dimm_parameters(const ddr3_spd_eeprom_t *spd,
pdimm-data_width = pdimm-primary_sdram_width
+ pdimm-ec_sdram_width;
- switch (spd-module_type 0xf) {
- case 0x01: /* RDIMM */
- case 0x05: /* Mini-RDIMM */
- pdimm-registered_dimm = 1; /* register buffered */
+ /* These are the types defined by the JEDEC DDR3 SPD spec */
+ pdimm-mirrored_dimm = 0;
+ pdimm-registered_dimm = 0;
+ switch (spd-module_type DDR3_SPD_MODULETYPE_MASK) {
+ case DDR3_SPD_MODULETYPE_RDIMM:
+ case DDR3_SPD_MODULETYPE_MINI_RDIMM:
+ /* Registered/buffered DIMMs */
+ pdimm-registered_dimm = 1;
for (i = 0; i 16; i += 2) {
- pdimm-rcw[i] = spd-mod_section.registered.rcw[i/2]
0x0F;
- pdimm-rcw[i+1] = (spd-mod_section.registered.rcw[i/2]
4) 0x0F;
+ u8 rcw = spd-mod_section.registered.rcw[i/2];
+ pdimm-rcw[i] = (rcw 0) 0x0F;
+ pdimm-rcw[i+1] = (rcw 4) 0x0F;
}
break;
- case 0x02: /* UDIMM */
- case 0x03: /* SO-DIMM */
- case 0x04: /* Micro-DIMM */
- case 0x06: /* Mini-UDIMM */
- pdimm-registered_dimm = 0; /* unbuffered */
+
+ case DDR3_SPD_MODULETYPE_UDIMM:
+ case DDR3_SPD_MODULETYPE_SO_DIMM:
+ case DDR3_SPD_MODULETYPE_MICRO_DIMM:
+ case DDR3_SPD_MODULETYPE_MINI_UDIMM:
+ /* Unbuffered DIMMs */
+ if (spd-mod_section.unbuffered.addr_mapping 0x1)
+ pdimm-mirrored_dimm = 1;
break;
default:
- printf(unknown dimm_type 0x%02X\n, spd-module_type);
+ printf(unknown module_type 0x%02X\n, spd-module_type);
return 1;
}
@@ -303,16 +311,5 @@ ddr_compute_dimm_parameters(const ddr3_spd_eeprom_t *spd,
pdimm-tFAW_ps =
[U-Boot] [PATCH v4 4/4] mpc85xx: Add board support for the eXMeritus HWW-1U-1A devices
The eXMeritus HWW-1U-1A unit is a DO-160-certified 13lb 1U chassis with 3 independent TEMPEST zones. Two independent P2020 computers may be found inside each zone. Complete hardware support is included. High-level hardware overview: * DO-160 certified for passenger aircraft (noncritical) * TEMPEST ceritified for RED/BLACK separation * 3 zones per chassis, 2 computers per zone (total of 6) * Dual-core 1.066GHz P2020 per computer * One 2GB DDR2 SO-RDIMM module per computer (upgradable to 4GB) * Removable 80GB or 160GB Intel X18-M SSD per computer * Front-accessible dual-port E1000E per computer * Front-accessible serial console per computer * Front-accessible USB port per computer * Internal Gigabit crossover within each TEMPEST zone * Internal unidirectional fiber links across TEMPEST zones * Battery-backed DS1339 I2C RTC on each CPU. Combined, each 13lb 1U chassis contains 12GB RAM, 12 cores @ 1.066GHz, 12 front-accessible Gigabit Ethernet ports and 960GB of solid-state storage with a total power consumption of ~200W. Additional notes: * SPD detection is only known to work with the DO-160-certified DIMMs * A U-Boot built with 36-bit address-space seems to work, but I don't yet have a usable 36-bit kernel or DTB, so it's mostly untested. * CPU reset is a little quirky due to hardware misfeature, see the extensive comments in the board_reset() function in hww1u1a.c Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com Cc: Andy Fleming aflem...@gmail.com Cc: Kumar Gala kumar.g...@freescale.com --- MAINTAINERS |4 + board/exmeritus/hww1u1a/Makefile | 54 board/exmeritus/hww1u1a/ddr.c | 51 board/exmeritus/hww1u1a/gpios.h | 67 + board/exmeritus/hww1u1a/hww1u1a.c | 549 + board/exmeritus/hww1u1a/law.c | 34 +++ board/exmeritus/hww1u1a/tlb.c | 106 +++ boards.cfg|2 + include/configs/HWW1U1A.h | 474 9 files changed, 1341 insertions(+), 0 deletions(-) create mode 100644 board/exmeritus/hww1u1a/Makefile create mode 100644 board/exmeritus/hww1u1a/ddr.c create mode 100644 board/exmeritus/hww1u1a/gpios.h create mode 100644 board/exmeritus/hww1u1a/hww1u1a.c create mode 100644 board/exmeritus/hww1u1a/law.c create mode 100644 board/exmeritus/hww1u1a/tlb.c create mode 100644 include/configs/HWW1U1A.h diff --git a/MAINTAINERS b/MAINTAINERS index 07541bd..5da7c1f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -320,6 +320,10 @@ Reinhard Meyer reinhard.me...@emk-elektronik.de TOP5200 MPC5200 TOP9000 ARM926EJS (AT91SAM9xxx SoC) +Kyle Moffett kyle.d.moff...@boeing.com + + HWW1U1A P2020 + Tolunay Orkun tor...@nextio.com csb272 PPC405GP diff --git a/board/exmeritus/hww1u1a/Makefile b/board/exmeritus/hww1u1a/Makefile new file mode 100644 index 000..b927f59 --- /dev/null +++ b/board/exmeritus/hww1u1a/Makefile @@ -0,0 +1,54 @@ +# +# Copyright 2007-2009 Freescale Semiconductor, Inc. +# (C) Copyright 2001-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS-y+= $(BOARD).o +COBJS-y+= law.o +COBJS-y+= tlb.o +COBJS-$(CONFIG_DDR_SPD) += ddr.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS)) + +clean: + rm -f $(OBJS) $(SOBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/exmeritus/hww1u1a/ddr.c b/board/exmeritus/hww1u1a/ddr.c new file mode 100644 index 000..dbdcc86 --- /dev/null +++ b/board/exmeritus/hww1u1a/ddr.c @@ -0,0 +1,51 @@ +/* + * Copyright 2009-2010 eXMeritus, A Boeing Company + * Copyright
[U-Boot] [PATCH v4 1/4] Refactor do_reset() into board-specific and CPU-specific portions
The existing do_reset() shell command function is defined and redefined all over the place. Most CPU types have their own default internal reset mechanism, even if it is just to force a triple-fault. In addition, some board designs require the ability to override the native CPU reset due to hardware requirements or limitations. This patch is designed to make it much easier for boards to generically override their CPU-architecture reset routine, as well as to provide a generic entrypoint for common improvements to CPU reset (IE: clean restart of network/storage devices, etc). In particular, this is necessary for the new eXMeritus HWW-1U-1A port. All of the board-specific reset routines are renamed from do_reset() to board_reset(). A few CPUs already had a customized board_reset() hook; those were adjusted to use the new board_reset() prototype. All of the CPU-specific reset routines are renamed from do_reset() to arch_reset(). The name cpu_reset() might better, but that is already in use in various places for SMP support. (IE: Reset one particular CPU). Weak no-ops were created for arch_reset() and board_reset() to support platforms which don't implement one or both of them. A new generic system_reset() function was introduced which simply calls board_reset() and cpu_reset() in that order, and all explicit callers of do_reset() were changed to use system_reset() instead. Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com Cc: Wolfgang Denk w...@denx.de Cc: Albert Aribaud albert.arib...@free.fr Cc: Mike Frysinger vap...@gentoo.org Cc: Jason Jin jason@freescale.com Cc: Michal Simek mon...@monstr.eu Cc: Shinya Kuribayashi skuri...@pobox.com Cc: Kim Phillips kim.phill...@freescale.com Cc: Andy Fleming aflem...@gmail.com Cc: Kumar Gala kumar.g...@freescale.com Cc: Stefan Roese s...@denx.de Cc: Daniel Hellstrom dan...@gaisler.com Cc: Graeme Russ graeme.r...@gmail.com --- v4: Complete rewrite as a fully architecture-independent feature api/api.c |3 +- arch/arm/cpu/arm920t/at91/reset.c |5 --- arch/arm/cpu/arm920t/at91rm9200/reset.c|2 - arch/arm/lib/reset.c |2 +- arch/avr32/cpu/cpu.c |2 +- arch/blackfin/cpu/cpu.h|1 - arch/blackfin/cpu/reset.c | 28 ++--- arch/i386/cpu/cpu.c|2 +- arch/m68k/cpu/mcf5227x/cpu.c |2 +- arch/m68k/cpu/mcf523x/cpu.c|2 +- arch/m68k/cpu/mcf52x2/cpu.c| 20 arch/m68k/cpu/mcf52x2/cpu.h| 33 arch/m68k/cpu/mcf532x/cpu.c|2 +- arch/m68k/cpu/mcf5445x/cpu.c |2 +- arch/m68k/cpu/mcf547x_8x/cpu.c |2 +- arch/mips/cpu/cpu.c|2 +- arch/nios2/cpu/cpu.c |2 +- arch/powerpc/cpu/74xx_7xx/cpu.c|2 +- arch/powerpc/cpu/mpc512x/cpu.c |3 +- arch/powerpc/cpu/mpc5xx/cpu.c |2 +- arch/powerpc/cpu/mpc5xxx/cpu.c |3 +- arch/powerpc/cpu/mpc8220/cpu.c |2 +- arch/powerpc/cpu/mpc824x/cpu.c |2 +- arch/powerpc/cpu/mpc8260/cpu.c |5 +-- arch/powerpc/cpu/mpc83xx/cpu.c |3 +- arch/powerpc/cpu/mpc85xx/cpu.c | 15 +--- arch/powerpc/cpu/mpc86xx/cpu.c | 22 ++--- arch/powerpc/cpu/mpc8xx/cpu.c |4 +- arch/powerpc/cpu/ppc4xx/cpu.c |9 +- arch/sh/cpu/sh2/cpu.c |2 +- arch/sh/cpu/sh3/cpu.c |2 +- arch/sh/cpu/sh4/cpu.c |2 +- arch/sparc/cpu/leon2/cpu.c |3 +- arch/sparc/cpu/leon3/cpu.c |4 +-- board/BuS/eb_cpux9k2/cpux9k2.c |1 - board/amcc/yosemite/yosemite.c |3 +- board/atmel/at91rm9200dk/at91rm9200dk.c|3 +- board/bf537-stamp/bf537-stamp.c|3 +- board/dave/PPChameleonEVB/PPChameleonEVB.c |4 +- board/eltec/bab7xx/bab7xx.c|6 ++-- board/eltec/elppc/elppc.c |2 +- board/esd/apc405/apc405.c |4 +- board/esd/ar405/ar405.c|2 +- board/esd/ash405/ash405.c |4 +- board/esd/canbt/canbt.c|2 +- board/esd/cpci405/cpci405.c|6 ++-- board/esd/cpciiser4/cpciiser4.c|2 +- board/esd/du405/du405.c
Re: [U-Boot] [PATCH v4 1/4] Refactor do_reset() into board-specific and CPU-specific portions
On Wednesday, February 23, 2011 14:28:44 Kyle Moffett wrote:
+__attribute__((__weak__)) int arch_reset(void)
+{
+ return 0;
+}
is there any cpu which wouldnt provide arch_reset() ? i dont think it was
possible in the past to do this, so i dont see any value in supporting this.
+int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
static
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Tegra2 Seaboard: Fix mach_type to match mach-type.h update
Seaboard build stopped working due to Sandeep's recent mach-types.h update to match the Linux kernel. Change Seaboard to use MACH_TYPE_SEABOARD. Tom Warren (1): arm: Tegra2: Change mach-type to MACH_TYPE_SEABOARD due to mach-types.h update include/configs/seaboard.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Tegra2: Change mach-type to MACH_TYPE_SEABOARD due to mach-types.h update
OK, I'm an idiot. I see now that I needed to add -n to format-patch to add the numbering to the [PATCH] header. Sorry for the noise - resending now with the corrected patchset. Tom On Wed, Feb 23, 2011 at 12:54 PM, Tom Warren twarren.nvi...@gmail.com wrote: Signed-off-by: Tom Warren twar...@nvidia.com --- include/configs/seaboard.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h index fd87560..59eef56 100644 --- a/include/configs/seaboard.h +++ b/include/configs/seaboard.h @@ -37,7 +37,7 @@ #define CONFIG_TEGRA2_ENABLE_UARTD #define CONFIG_SYS_NS16550_COM1 NV_PA_APB_UARTD_BASE -#define CONFIG_MACH_TYPE MACH_TYPE_TEGRA_SEABOARD +#define CONFIG_MACH_TYPE MACH_TYPE_SEABOARD #define CONFIG_SYS_BOARD_ODMDATA 0x300d8011 /* lp1, 1GB */ #endif /* __CONFIG_H */ -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: Tegra2: Change mach-type to MACH_TYPE_SEABOARD due to mach-types.h update
Signed-off-by: Tom Warren twar...@nvidia.com --- include/configs/seaboard.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h index fd87560..59eef56 100644 --- a/include/configs/seaboard.h +++ b/include/configs/seaboard.h @@ -37,7 +37,7 @@ #define CONFIG_TEGRA2_ENABLE_UARTD #define CONFIG_SYS_NS16550_COM1NV_PA_APB_UARTD_BASE -#define CONFIG_MACH_TYPE MACH_TYPE_TEGRA_SEABOARD +#define CONFIG_MACH_TYPE MACH_TYPE_SEABOARD #define CONFIG_SYS_BOARD_ODMDATA 0x300d8011 /* lp1, 1GB */ #endif /* __CONFIG_H */ -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/1] Tegra2 Seaboard: Fix mach_type to match mach-type.h update
Seaboard build stopped working due to Sandeep's recent mach-types.h update to match the Linux kernel. Change Seaboard to use MACH_TYPE_SEABOARD. Tom Warren (1): arm: Tegra2: Change mach-type to MACH_TYPE_SEABOARD due to mach-types.h update include/configs/seaboard.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] arm: Tegra2: Change mach-type to MACH_TYPE_SEABOARD due to mach-types.h update
Signed-off-by: Tom Warren twar...@nvidia.com --- include/configs/seaboard.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h index fd87560..59eef56 100644 --- a/include/configs/seaboard.h +++ b/include/configs/seaboard.h @@ -37,7 +37,7 @@ #define CONFIG_TEGRA2_ENABLE_UARTD #define CONFIG_SYS_NS16550_COM1NV_PA_APB_UARTD_BASE -#define CONFIG_MACH_TYPE MACH_TYPE_TEGRA_SEABOARD +#define CONFIG_MACH_TYPE MACH_TYPE_SEABOARD #define CONFIG_SYS_BOARD_ODMDATA 0x300d8011 /* lp1, 1GB */ #endif /* __CONFIG_H */ -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Tegra2: Change mach-type to MACH_TYPE_SEABOARD due to mach-types.h update
Le 23/02/2011 21:03, Tom Warren a écrit : OK, I'm an idiot. I see now that I needed to add -n to format-patch to add the numbering to the [PATCH] header. Sorry for the noise - resending now with the corrected patchset. Tom Actually, for a single patch, you don't need to generate numbers, nor a cover letter (the 0/N message). Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] building enc28j60 for omap3: SILICON ERRATA
Hi,
On Tue, 22 Feb 2011 17:34:30 +0100
jacopo mondi j.mo...@voltaelectronics.com wrote:
...
Second issue is related to enc identification.
The following code section:
phid1 = phy_read(enc, PHY_REG_PHID1);
phid2 = phy_read(enc, PHY_REG_PHID2) ENC_PHID2_MASK;
if (phid1 != ENC_PHID1_VALUE || phid2 != ENC_PHID2_VALUE) {
printf(%s: failed to identify PHY. Found
%04x:%04x\n, enc-dev-name,
phid1, phid2);
return -1;
}
fails because phy_read instructions return 0 or random values (0xB0B0
or 0xB000).
Linux driver does not perform such tests, so I've tried removing them.
No, please do not remove them. Fix the register access
problem instead.
Anyway all read and write to enc fails.
Could that be related to omap3_spi implementation?
Yes. If you use the omap3_spi driver in current mainline tree,
then definitely the omap3_spi driver is the problem. enc28j60
register and buffer access can not work with this current driver
version.
We experienced problems with enc28j60 register access on a iMX31
based board as there were among other things some byte order issues
in the spi driver. When using spi clock above 2 MHz we also have
seen seemingly random data when reading the enc registers. Be aware
that there are two kinds of spi transfers for enc register access:
two bytes long transfers and three bytes long transfers with a dummy
byte. The spi chip select signal have to be active as long as
these tx/rx transfers didn't completed and may not be deactivated
in between. Also the spi transfer is full-duplex for enc28j60
register and buffers access. With a properly working spi driver
the enc28j60 driver in U-Boot works well.
I can confirm that same same board I'm using for test works great
under Linux, so it is not an hardware issue.
This is the omap3_spi driver issue. You can apply the attached
patch for enc28j60 driver to be able to start single register
accesses on the U-Boot command line. Then you can start fixing
the spi driver code. Implement fixes in the spi driver and test
the register access using the enc commands added by the path.
You will have to implement the Master Transmit-Receive Mode
(full-duplex) in the omap3_spi driver for proper enc28j60 register
and buffer access. Currently this driver is using Tx-Only Mode
for transmitting a Rx-Only Mode for receiving. But it shouldn't
be too hard to fix the spi driver. What is needed is a kind
of merge of omap3_spi_read/omap3_spi_write routines.
HTH
Anatolij
diff --git a/drivers/net/enc28j60.c b/drivers/net/enc28j60.c
index 5731bdb..784d1dd 100644
--- a/drivers/net/enc28j60.c
+++ b/drivers/net/enc28j60.c
@@ -21,6 +21,7 @@
*/
#include common.h
+#include command.h
#include net.h
#include spi.h
#include malloc.h
@@ -926,6 +927,7 @@ static void enc_halt(struct eth_device *dev)
enc_release_bus(enc);
}
+enc_dev_t *genc;
/*
* This is the only exported function.
*
@@ -974,5 +976,65 @@ int enc28j60_initialize(unsigned int bus, unsigned int cs,
#if defined(CONFIG_CMD_MII)
miiphy_register(dev-name, enc_miiphy_read, enc_miiphy_write);
#endif
+ genc = enc;
return 0;
}
+
+
+int do_enc(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ char *cmd;
+ u32 reg;
+ u32 val;
+
+ /* at least two arguments */
+ if (argc 3)
+ return cmd_usage(cmdtp);
+
+ cmd = argv[1];
+ if (strcmp(cmd, r) == 0) {
+ if (argc 3)
+ return cmd_usage(cmdtp);
+
+ reg = simple_strtoul(argv[2], NULL, 16);
+ printf(reg. 0x%02lx: 0x%02lx\n, (ulong)reg, (ulong)enc_r8(genc, (u16)reg));
+ return 0;
+ }
+ if (strcmp(cmd, pr) == 0) {
+ if (argc 3)
+ return cmd_usage(cmdtp);
+
+ reg = simple_strtoul(argv[2], NULL, 16);
+ printf(phy reg. 0x%02lx: 0x%04lx\n, (ulong)reg, (ulong)phy_read(genc, (u8)reg));
+ return 0;
+ }
+ if (strcmp(cmd, w) == 0) {
+ if (argc 4)
+ return cmd_usage(cmdtp);
+
+ reg = simple_strtoul(argv[2], NULL, 16);
+ val = simple_strtoul(argv[3], NULL, 16);
+ enc_w8(genc, (u16)reg, (u8)val);
+ return 0;
+ }
+ if (strcmp(cmd, pw) == 0) {
+ if (argc 4)
+ return cmd_usage(cmdtp);
+
+ reg = simple_strtoul(argv[2], NULL, 16);
+ val = simple_strtoul(argv[3], NULL, 16);
+ phy_write(genc, (u8)reg, (u16)val);
+ return 0;
+ }
+ /* No subcommand */
+ return 1;
+}
+
+U_BOOT_CMD(
+ enc, 4, 1, do_enc,
+ enc28j60 register read/write,
+ r reg - read register\n
+ enc w reg value - write register\n
+ enc pr reg - read PHY register\n
+ enc pw reg value - write PHY register
+);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] autocomplete environment variables
Hello I am using u-boot 2010.12 release. On previous releases auto completion was working for environment variables (bootargs, bootcmd, etc...) but with this release it is not. When i searched the mailing list for a clue i found this patch [1], which i think disables autocompletion for environment variables. Is there a way of enabling this feature after this patch? [1] http://old.nabble.com/-U-Boot---PATCH--autocomplete%3A-remove-runtime-handle r-install-tp30007491p30007491.html Best Regards Alper YILDIRIM ## Dikkat: Bu elektronik posta mesaji kisisel ve ozeldir. Eger size gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz. Firmamiza gelen ve giden mesajlar virus taramasindan gecirilmekte, guvenlik nedeni ile kontrol edilerek saklanmaktadir. Mesajdaki gorusler ve bakis acisi gondericiye ait olup Aselsan A.S. resmi gorusu olmak zorunda degildir. ## Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. E-mails to and from the company are monitored for operational reasons and in accordance with lawful business practices. Any views or opinions presented are solely those of the author and do not necessarily represent the views of the company. ## ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] autocomplete environment variables
On Wednesday, February 23, 2011 17:17:39 Alper YILDIRIM wrote: I am using u-boot 2010.12 release. On previous releases auto completion was working for environment variables (bootargs, bootcmd, etc...) but with this release it is not. it will be re-enabled in the next release When i searched the mailing list for a clue i found this patch [1], which i think disables autocompletion for environment variables. Is there a way of enabling this feature after this patch? [1] http://old.nabble.com/-U-Boot---PATCH--autocomplete%3A-remove-runtime-handl e r-install-tp30007491p30007491.html that is not what the patch does. it is an optimization only. removal of the functionality happened way before with Wolfgang's env rewrite. i re-added support after the 2010.12 release. Dikkat: please do not e-mail this crap out to the list -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] building enc28j60 for omap3: SILICON ERRATA
Dear Anatolij Gustschin, In message 20110223233201.09aee7e4@wker you wrote: No, please do not remove them. Fix the register access problem instead. Anyway all read and write to enc fails. Could that be related to omap3_spi implementation? Yes. If you use the omap3_spi driver in current mainline tree, then definitely the omap3_spi driver is the problem. enc28j60 register and buffer access can not work with this current driver version. There might also be other issues. The omap3_spi driver was one of those affected by the bug fixed in commit 495df3b ARM: fix write*() I/O accessors, see http://patchwork.ozlabs.org/patch/82841/ This is fixed in mainline now, so it might be wise to update the code base and just try again. 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 On the subject of C program indentation: In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. - Blair P. Houghton ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] building enc28j60 for omap3: SILICON ERRATA
Hi, I wrote: The omap3_spi driver was one of those affected by the bug fixed in commit 495df3b ARM: fix write*() I/O accessors, see http://patchwork.ozlabs.org/patch/82841/ Sorry, I mixed this up. That was the davinci_spi driver, not the omap3_spi one. 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 Madness takes its toll. Please have exact change. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot support for Cortex-M3
Hi Pratik, ST provided In Application Programming via USART. Search for application node AN2557, it is used to boot uClinux. But you may take a look to https://github.com/leaflabs/maple-bootloader if you intent to create your board-support in u-boot :) On Wed, Feb 23, 2011 at 7:53 PM, pratik pujar pratikpu...@yahoo.com wrote: Does U-boot have support for Cortex-M3? Or is it available in terms of patch, if yes how can I get it? -- Viet ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM: Incorrect ROM protection range?
Hi all,
I am using relocation fixed a320evb (arm) u-boot.
I noticed something weird about the output of
command flinfo.
The size of u-boot.bin is 129156 (0x1F884), but the
protected range is only 0 ~ 0x1bfff.
I guess that it is because u-boot protects _start ~ __bss_start,
but there are some other things in u-boot.bin after __bss_start,
e.g. .rel.dyn section and .dynsym section
That is quite strange.
According to arch/arm/cpu/arm920t/u-boot.lds,
.rel.dyn and .dynsym sections should be placed before __bss_start.
However, objdump shows that they are not at where they should be.
Do I understand correctly?
Does anybody have similar situation?
BTW, the toolchain I am using is
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1.
0001be8c g O .u_boot_cmd0018 __u_boot_cmd_printenv
0001bea4 g O .u_boot_cmd0018 __u_boot_cmd_setenv
0001bebc g O .u_boot_cmd0018 __u_boot_cmd_run
0001bed4 g O .u_boot_cmd0018 __u_boot_cmd_source
0001beec g O .u_boot_cmd0018 __u_boot_cmd_version
0001bf04 g O .u_boot_cmd0018 __u_boot_cmd_imxtract
0001bf1c g *ABS* __u_boot_cmd_end
0001bf1c g .bss __bss_start
0001bf1c g O .bss 0004 monitor_flash_len
0001bf1c g .rel.dyn __rel_dyn_start
0001bf1c ld .bss .bss
0001bf1c ld .rel.dyn .rel.dyn
0001bf20 l O .bss 012c images
0001c04c l O .bss 0004 os_data_state
0001c050 l O .bss 0004 os_data_addr
0001c054 l O .bss 0004 bin_start_address
0001c058 l O .bss 0004 k_data_escape
0001c05c g O .bss 0004 os_data_init
0001c060 l O .bss 0004 k_data_escape_saved
0001c064 l O .bss 0004 os_data_state_saved
[snip]
0001dcac l O .bss 0004 NetRestarted
0001dcb0 g O .bss 0004 NetRestartWrap
0001dcb4 l O .bss 0004 NetDevExists
0001dcb8 g O .bss 1e20 PktBuf
0001f73c g .dynsym __dynsym_start
0001f73c g .rel.dyn __rel_dyn_end
0001f73c ld .dynsym .dynsym
0001fad8 g O .bss 0010 NetRxPackets
0001fae8 g O .bss 0620 NetArpWaitPacketBuf
00020108 l O .bss 0004 env_changed_id.3244
U-Boot 2011.03-rc1-00134-ga898a11 (Feb 23 2011 - 16:53:13)
DRAM: 64 MiB
Flash: 32.5 MiB
In:serial
Out: serial
Err: serial
Net: FTMAC100
Hit any key to stop autoboot: 0
A320 # fli 1
Bank # 1: SST 39LF040 flash (8 x 8) Size: 512 kB in 128 Sectors
AMD Legacy command set, Manufacturer ID: 0xBF, Device ID: 0xD7
Erase timeout: 3 ms, write timeout: 100 ms
Sector Start Addresses:
RO 1000 RO 2000 RO 3000 RO 4000 RO
5000 RO 6000 RO 7000 RO 8000 RO 9000 RO
A000 RO B000 RO C000 RO D000 RO E000 RO
F000 RO 0001 RO 00011000 RO 00012000 RO 00013000 RO
00014000 RO 00015000 RO 00016000 RO 00017000 RO 00018000 RO
00019000 RO 0001A000 RO 0001B000 RO 0001C0000001D000
0001E0000001F00000020002100000022000
0002300000024000000250000002600000027000
00028000000290000002A0000002B0000002C000
0002D0000002E0000002F000000300031000
0003200000033000000340000003500000036000
0003700000038000000390000003A0000003B000
0003C0000003D0000003E0000003F0000004
0004100000042000000430000004400000045000
000460000004700000048000000490000004A000
0004B0000004C0000004D0000004E0000004F000
000500051000000520000005300000054000
0005500000056000000570000005800000059000
0005A0000005B0000005C0000005D0000005E000
0005F0000006 RO 00061000 RO 00062000 RO 00063000 RO
00064000 RO 00065000 RO 00066000 RO 00067000 RO 00068000 RO
00069000 RO 0006A000 RO 0006B000 RO 0006C000 RO 0006D000 RO
0006E000 RO 0006F000 RO 0007 RO 00071000 RO 00072000 RO
00073000 RO 00074000 RO 00075000 RO 00076000 RO 00077000 RO
00078000 RO 00079000 RO 0007A000 RO 0007B000 RO 0007C000 RO
0007D000 RO 0007E000 RO 0007F000 RO
best regards,
Po-Yu Chuang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: Incorrect ROM protection range?
Hi Po-Yu Chuang, Le 24/02/2011 07:06, Po-Yu Chuang a écrit : Hi all, I am using relocation fixed a320evb (arm) u-boot. I noticed something weird about the output of command flinfo. The size of u-boot.bin is 129156 (0x1F884), but the protected range is only 0 ~ 0x1bfff. I guess that it is because u-boot protects _start ~ __bss_start, but there are some other things in u-boot.bin after __bss_start, e.g. .rel.dyn section and .dynsym section You're most probable right about this -- this size error has to be fixed. All reasers please see the 'BTW' at the end of my post. That is quite strange. According to arch/arm/cpu/arm920t/u-boot.lds, .rel.dyn and .dynsym sections should be placed before __bss_start. However, objdump shows that they are not at where they should be. Do I understand correctly? Not quite. Actually, relocation sections should start from the same location as BSS -- they are overlaid at the same location, and this is voluntary. The relocation sections are only needed and useful before relocation, where BSS should not be used anyway. BSS only exists after relocation, where relocation tables are no more useful. Thus, to minimize RAM and FLASH footprints, the two are overlaid at the same location. Does anybody have similar situation? Just about all people who use ARM U-Boot since the overlay was introduced. :) 0001bf1c g .bss __bss_start 0001bf1c g .rel.dyn __rel_dyn_start 0001f73c g .dynsym __dynsym_start 0001f73c g .rel.dyn __rel_dyn_end This is normal as far as layout is concerned: BSS and .rel.dyn start at the same offset, and .dynsym follows .rel.dyn. You're right that U-Boot protection should cover the whole of U-Boot, including the relocation tables. I *think* protection uses a monitor length define for this. Can you verify this point, and check what your monitor length define amounts to? Maybe it does not cover the relocation tables any more. BTW, Would it not be better to compute the actual image size rather than rely on a define? In the U-Boot image itself, knowing the image size could be achieved in ARM by using a general _end symbol that would be set after the last image output section, so _end-_start would equal the image size. For code other than the U-Boot image itself (loaders, utilities), a 'du -b u-boot.bin | cut -f 1' should be ok, provided the image is built first, which I think is already the case. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: Incorrect ROM protection range?
Dear Albert ARIBAUD, In message 4d660030@free.fr you wrote: You're right that U-Boot protection should cover the whole of U-Boot, including the relocation tables... True. This was overlooked during all thie relocation rework. ... I *think* protection uses a monitor length define for this. Can you verify this point, and check what your monitor length define amounts to? Maybe it does not cover the relocation tables any more. I'm not sure if all boards do the same; the common CFI driver (drivers/mtd/cfi_flash.c, search for Monitor protection ON by default) protects an area of monitor_flash_len bytes starting at CONFIG_SYS_MONITOR_BASE plus the environment sector(s). monitor_flash_len gets normally computed in archh/*/lib/board.c; on ARM, we have this: monitor_flash_len = _bss_start_ofs; Would it not be better to compute the actual image size rather than rely on a define? This is already the case. It's just that the computation is not correct any more. 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 Those who do not understand Unix are condemned to reinvent it, poorly. - Henry Spencer, University of Toronto Unix hack ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: Incorrect ROM protection range?
Hi Albert, On Thu, Feb 24, 2011 at 2:52 PM, Albert ARIBAUD albert.arib...@free.fr wrote: Hi Po-Yu Chuang, Le 24/02/2011 07:06, Po-Yu Chuang a écrit : That is quite strange. According to arch/arm/cpu/arm920t/u-boot.lds, .rel.dyn and .dynsym sections should be placed before __bss_start. However, objdump shows that they are not at where they should be. Do I understand correctly? Not quite. Actually, relocation sections should start from the same location as BSS -- they are overlaid at the same location, and this is voluntary. The relocation sections are only needed and useful before relocation, where BSS should not be used anyway. BSS only exists after relocation, where relocation tables are no more useful. Thus, to minimize RAM and FLASH footprints, the two are overlaid at the same location. I got it. Thanks for your explanation. Does anybody have similar situation? Just about all people who use ARM U-Boot since the overlay was introduced. :) 0001bf1c g .bss __bss_start 0001bf1c g .rel.dyn __rel_dyn_start 0001f73c g .dynsym __dynsym_start 0001f73c g .rel.dyn __rel_dyn_end This is normal as far as layout is concerned: BSS and .rel.dyn start at the same offset, and .dynsym follows .rel.dyn. You're right that U-Boot protection should cover the whole of U-Boot, including the relocation tables. I *think* protection uses a monitor length define for this. Can you verify this point, and check what your monitor length define amounts to? Maybe it does not cover the relocation tables any more. The monitor length is not defined by macro. It is calculated. In drivers/mtd/cfi_flash.c: /* Monitor protection ON by default */ #if (CONFIG_SYS_MONITOR_BASE = CONFIG_SYS_FLASH_BASE) \ (!defined(CONFIG_MONITOR_IS_IN_RAM)) flash_protect (FLAG_PROTECT_SET, CONFIG_SYS_MONITOR_BASE, CONFIG_SYS_MONITOR_BASE + monitor_flash_len - 1, flash_get_info(CONFIG_SYS_MONITOR_BASE)); #endif monitor_flash_len is defined in arch/arm/lib/board.c and is calculated by board_init_r(): monitor_flash_len = _bss_start_ofs; Which is in arch/arm/cpu/arm920t/start.S in my case: .globl _bss_start_ofs _bss_start_ofs: .word __bss_start - _start So I guess we should use another way to calculate monitor_flash_len. BTW, Would it not be better to compute the actual image size rather than rely on a define? In the U-Boot image itself, knowing the image size could be achieved in ARM by using a general _end symbol that would be set after the last image output section, so _end-_start would equal the image size. But _end means end of bss section, right? I think _end is not the right choice. For code other than the U-Boot image itself (loaders, utilities), a 'du -b u-boot.bin | cut -f 1' should be ok, provided the image is built first, which I think is already the case. best regards, Po-Yu Chuang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: Incorrect ROM protection range?
Hello Albert, Albert ARIBAUD wrote: Le 24/02/2011 07:06, Po-Yu Chuang a écrit : Hi all, I am using relocation fixed a320evb (arm) u-boot. I noticed something weird about the output of command flinfo. The size of u-boot.bin is 129156 (0x1F884), but the protected range is only 0 ~ 0x1bfff. I guess that it is because u-boot protects _start ~ __bss_start, but there are some other things in u-boot.bin after __bss_start, e.g. .rel.dyn section and .dynsym section You're most probable right about this -- this size error has to be fixed. All reasers please see the 'BTW' at the end of my post. That is quite strange. According to arch/arm/cpu/arm920t/u-boot.lds, .rel.dyn and .dynsym sections should be placed before __bss_start. However, objdump shows that they are not at where they should be. Do I understand correctly? Not quite. Actually, relocation sections should start from the same location as BSS -- they are overlaid at the same location, and this is voluntary. The relocation sections are only needed and useful before relocation, where BSS should not be used anyway. BSS only exists after relocation, where relocation tables are no more useful. Thus, to minimize RAM and FLASH footprints, the two are overlaid at the same location. Does anybody have similar situation? Just about all people who use ARM U-Boot since the overlay was introduced. :) 0001bf1c g .bss __bss_start 0001bf1c g .rel.dyn __rel_dyn_start 0001f73c g .dynsym __dynsym_start 0001f73c g .rel.dyn __rel_dyn_end This is normal as far as layout is concerned: BSS and .rel.dyn start at the same offset, and .dynsym follows .rel.dyn. You're right that U-Boot protection should cover the whole of U-Boot, including the relocation tables. I *think* protection uses a monitor length define for this. Can you verify this point, and check what your monitor length define amounts to? Maybe it does not cover the relocation tables any more. The bin length is calculated in arch/arm/lib/board.c, but it seems to me not correct ... :-( in board_init_f(): gd-mon_len = _bss_end_ofs; that seems correct to me, but later in board_init_r() monitor_flash_len = _bss_start_ofs; which is used for example in ./drivers/mtd/cfi_flash.c for protecting the flash sectors ... so this should be fixed. BTW, Would it not be better to compute the actual image size rather than rely on a define? In the U-Boot image itself, knowing the image size could be achieved in ARM by using a general _end symbol that would be set after the last image output section, so _end-_start would equal the image size. we have such a _end in u-boot.lds files. For code other than the U-Boot image itself (loaders, utilities), a 'du -b u-boot.bin | cut -f 1' should be ok, provided the image is built first, which I think is already the case. Amicalement, bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: Incorrect ROM protection range?
Hi Heiko, On Thu, Feb 24, 2011 at 3:33 PM, Heiko Schocher h...@denx.de wrote: Albert ARIBAUD wrote: The bin length is calculated in arch/arm/lib/board.c, but it seems to me not correct ... :-( in board_init_f(): gd-mon_len = _bss_end_ofs; that seems correct to me, but later in board_init_r() monitor_flash_len = _bss_start_ofs; which is used for example in ./drivers/mtd/cfi_flash.c for protecting the flash sectors ... so this should be fixed. In the U-Boot image itself, knowing the image size could be achieved in ARM by using a general _end symbol that would be set after the last image output section, so _end-_start would equal the image size. we have such a _end in u-boot.lds files. I guess we need a __dynsym_end in all u-boot.lds files. For code other than the U-Boot image itself (loaders, utilities), a 'du -b u-boot.bin | cut -f 1' should be ok, provided the image is built first, which I think is already the case. best regards, Po-Yu Chuang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
