Re: [U-Boot] [PATCH-V3 1/2] omap3: Calculate CS1 size only when SDRC is initialized for CS1
-Original Message-
From: Hiremath, Vaibhav
Sent: Tuesday, May 11, 2010 10:30 AM
To: Hiremath, Vaibhav; u-boot@lists.denx.de
Cc: w...@denx.de; t...@bumblecow.com; Paulraj, Sandeep; Premi, Sanjeev
Subject: RE: [PATCH-V3 1/2] omap3: Calculate CS1 size only when SDRC is
initialized for CS1
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, May 06, 2010 10:52 PM
To: u-boot@lists.denx.de
Cc: w...@denx.de; t...@bumblecow.com; Paulraj, Sandeep; Hiremath, Vaibhav;
Premi, Sanjeev
Subject: [PATCH-V3 1/2] omap3: Calculate CS1 size only when SDRC is
initialized for CS1
From: Vaibhav Hiremath hvaib...@ti.com
The patch makes sure that size for SDRC CS1 gets calculated
only when the CS1 SDRC is initialized.
[Hiremath, Vaibhav] Denk,
If we do not have any further comments, can we merge these patches?
[Hiremath, Vaibhav] Tom,
Can you merge these patches and give pull request to Denk, this is long pending
item.
Thanks,
Vaibhav
Thanks,
Vaibhav
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/cpu/arm_cortexa8/omap3/board.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/arm_cortexa8/omap3/board.c
b/arch/arm/cpu/arm_cortexa8/omap3/board.c
index 7b78fa4..69a08fd 100644
--- a/arch/arm/cpu/arm_cortexa8/omap3/board.c
+++ b/arch/arm/cpu/arm_cortexa8/omap3/board.c
@@ -282,6 +282,8 @@ int dram_init(void)
DECLARE_GLOBAL_DATA_PTR;
unsigned int size0 = 0, size1 = 0;
+ size0 = get_sdr_cs_size(CS0);
+
/*
* If a second bank of DDR is attached to CS1 this is
* where it can be started. Early init code will init
@@ -290,10 +292,9 @@ int dram_init(void)
if ((sysinfo.mtype == DDR_COMBO) || (sysinfo.mtype == DDR_STACKED)) {
do_sdrc_init(CS1, NOT_EARLY);
make_cs1_contiguous();
- }
- size0 = get_sdr_cs_size(CS0);
- size1 = get_sdr_cs_size(CS1);
+ size1 = get_sdr_cs_size(CS1);
+ }
gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
gd-bd-bi_dram[0].size = size0;
--
1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91 i2c support
Hello Maxim, Maxim Podbereznyy wrote: I can't find a support for i2c functionality in u-boot 1.3.4. I've found a please use actual code, 1.3.4 is very old ... discussion of such patches from Jean-Christophein in March 2009 and still no code in u-boot. You mean?: http://lists.denx.de/pipermail/u-boot/2009-March/049751.html This never made the way in mainline, because I made some comments, see here: http://lists.denx.de/pipermail/u-boot/2009-March/049840.html and after some discussion I never heard anything from this patch :-( So, if you are interested in this patch, please feel free to update it to current mainline (test it ;-), and post it again for discussion! Where can I find experimental or any i2c patches for u-boot? for example here: Experimental (new multibus approach for u-boot) http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=shortlog;h=refs/heads/multibus_v2 pending i2c patches are collected here (actual none): http://git.denx.de/u-boot-i2c.git 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
[U-Boot] [PATCH 0/3] Support for SM502 on PCI bus
This patch series adds support for SM502 on ICON board. Anatolij Gustschin (3): video: sm501: add support for SM501 chips on PCI bus video: sm501.c: add weak default functions ppc4xx: icon: add support for SM502 chip board/mosaixtech/icon/icon.c | 69 + drivers/video/sm501.c| 117 -- include/configs/icon.h | 23 include/pci_ids.h|1 + 4 files changed, 205 insertions(+), 5 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] ppc4xx: icon: add support for SM502 chip
Adds initialization code for SM502 graphics controller
and NL6448BC20-21D LCD panel.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Stefan Roese s...@denx.de
---
board/mosaixtech/icon/icon.c | 69 ++
include/configs/icon.h | 23 ++
2 files changed, 92 insertions(+), 0 deletions(-)
diff --git a/board/mosaixtech/icon/icon.c b/board/mosaixtech/icon/icon.c
index fbace9e..ecea1ee 100644
--- a/board/mosaixtech/icon/icon.c
+++ b/board/mosaixtech/icon/icon.c
@@ -317,3 +317,72 @@ int board_pcie_last(void)
/* Only 2 PCIe ports used on ICON, so the last one is 1 */
return 1;
}
+
+/*
+ * Video
+ */
+#ifdef CONFIG_VIDEO_SM501
+#include sm501.h
+
+#define DISPLAY_WIDTH 640
+#define DISPLAY_HEIGHT 480
+
+static const SMI_REGS sm502_init_regs[] = {
+ {0x4, 0x0},
+ {0x00040, 0x00021847},
+ {0x00044, 0x091a0a01}, /* 24 MHz pixclk */
+ {0x00054, 0x0},
+ {0x00048, 0x00021847},
+ {0x0004C, 0x091a0a01},
+ {0x00054, 0x1},
+ {0x80004, 0xc428bb17},
+ {0x8000C, 0x},
+ {0x80010, 0x0a000a00},
+ {0x80014, 0x0280},
+ {0x80018, 0x01e0},
+ {0x8001C, 0x},
+ {0x80020, 0x01e00280},
+ {0x80024, 0x02fa027f},
+ {0x80028, 0x004a0280},
+ {0x8002C, 0x020c01df},
+ {0x80030, 0x000201e7},
+ {0x80200, 0x0001},
+ {0x8, 0x2000}, /* gpio29 is pwm0, LED_PWM */
+ {0xC, 0x3f00}, /* gpio56 - gpio61 as flat panel data pins */
+ {0x10020, 0x25725728}, /* 20 kHz pwm0, 50 % duty cycle, disabled */
+ {0x8, 0x0f010106}, /* vsync hsync pos, disp on */
+ {0, 0}
+};
+
+/*
+ * Return a pointer to the register initialization table.
+ */
+const SMI_REGS *board_get_regs(void)
+{
+ return sm502_init_regs;
+}
+
+int board_get_width(void)
+{
+ return DISPLAY_WIDTH;
+}
+
+int board_get_height(void)
+{
+ return DISPLAY_HEIGHT;
+}
+
+#ifdef CONFIG_CONSOLE_EXTRA_INFO
+/*
+ * Return text to be printed besides the logo.
+ */
+void video_get_info_str(int line_number, char *info)
+{
+ if (line_number == 1)
+ strcpy(info, Board: ICON);
+ else
+ info[0] = '\0';
+}
+#endif
+
+#endif /* CONFIG_VIDEO_SM501 */
diff --git a/include/configs/icon.h b/include/configs/icon.h
index 3a57d69..7a4e60c 100644
--- a/include/configs/icon.h
+++ b/include/configs/icon.h
@@ -143,6 +143,26 @@
#define CONFIG_SYS_M41T11_BASE_YEAR 1900 /* play along with linux */
/*
+ * Video options
+ */
+#define CONFIG_VIDEO
+
+#ifdef CONFIG_VIDEO
+#define CONFIG_VIDEO_SM501
+#define CONFIG_VIDEO_SM501_32BPP
+#define CONFIG_VIDEO_SM501_PCI
+#define VIDEO_FB_LITTLE_ENDIAN
+#define CONFIG_CFB_CONSOLE
+#define CONFIG_VIDEO_LOGO
+#define CONFIG_CONSOLE_EXTRA_INFO
+#define CONFIG_VGA_AS_SINGLE_DEVICE
+#define CONFIG_VIDEO_SW_CURSOR
+#define CONFIG_VIDEO_BMP_RLE8
+#define CONFIG_SPLASH_SCREEN
+#define CFG_CONSOLE_IS_IN_ENV
+#endif
+
+/*
* Environment
*/
#defineCONFIG_ENV_IS_IN_FLASH 1 /* Environment uses flash
*/
@@ -171,6 +191,9 @@
#define CONFIG_CMD_PCI
#define CONFIG_CMD_SDRAM
#define CONFIG_CMD_SNTP
+#ifdef CONFIG_VIDEO
+#define CONFIG_CMD_BMP
+#endif
#defineCONFIG_IBM_EMAC4_V4 /* 440SPe has this EMAC version
*/
#define CONFIG_PHY_ADDR1 /* PHY address, See schematics
*/
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] video: sm501.c: add weak default functions
For boards using sm501/sm502 on PCI bus some driver
functions normaly defined in the board code are not
needed and empty. Provide weak default functions for
them and do not enforce board code to define empty
functions.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/video/sm501.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/video/sm501.c b/drivers/video/sm501.c
index 544e0a0..40606db 100644
--- a/drivers/video/sm501.c
+++ b/drivers/video/sm501.c
@@ -95,6 +95,34 @@ static struct pci_device_id sm501_pci_tbl[] = {
};
#endif
+/*
+ * We do not enforce board code to provide empty/unused
+ * functions for this driver and define weak default
+ * functions here.
+ */
+unsigned int __board_video_init (void)
+{
+ return 0;
+}
+
+unsigned int board_video_init (void)
+ __attribute__((weak, alias(__board_video_init)));
+
+unsigned int __board_video_get_fb (void)
+{
+ return 0;
+}
+
+unsigned int board_video_get_fb (void)
+ __attribute__((weak, alias(__board_video_get_fb)));
+
+void __board_validate_screen (unsigned int base)
+{
+}
+
+void board_validate_screen (unsigned int base)
+ __attribute__((weak, alias(__board_validate_screen)));
+
/*-
* video_hw_init --
*-
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] video: sm501: add support for SM501 chips on PCI bus
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/video/sm501.c | 89 ++---
include/pci_ids.h |1 +
2 files changed, 85 insertions(+), 5 deletions(-)
diff --git a/drivers/video/sm501.c b/drivers/video/sm501.c
index 283d2d9..544e0a0 100644
--- a/drivers/video/sm501.c
+++ b/drivers/video/sm501.c
@@ -31,6 +31,7 @@
#include common.h
+#include asm/io.h
#include video_fb.h
#include sm501.h
@@ -54,6 +55,18 @@
GraphicDevice sm501;
+void write_be32(int off, unsigned int val)
+{
+ out_be32((unsigned __iomem *)(sm501.isaBase + off), val);
+}
+
+void write_le32(int off, unsigned int val)
+{
+ out_le32((unsigned __iomem *)(sm501.isaBase + off), val);
+}
+
+void (*write_reg32)(int off, unsigned int val) = write_be32;
+
/*-
* SmiSetRegs --
*-
@@ -66,7 +79,7 @@ static void SmiSetRegs (void)
*/
const SMI_REGS *preg = board_get_regs ();
while (preg-Index) {
- write32 (preg-Index, preg-Value);
+ write_reg32 (preg-Index, preg-Value);
/*
* Insert a delay between
*/
@@ -75,26 +88,92 @@ static void SmiSetRegs (void)
}
}
+#ifdef CONFIG_VIDEO_SM501_PCI
+static struct pci_device_id sm501_pci_tbl[] = {
+ { PCI_VENDOR_ID_SMI, PCI_DEVICE_ID_SMI_501 },
+ {}
+};
+#endif
+
/*-
* video_hw_init --
*-
*/
void *video_hw_init (void)
{
+#ifdef CONFIG_VIDEO_SM501_PCI
+ unsigned int pci_mem_base, pci_mmio_base;
+ unsigned int id;
+ unsigned short device_id;
+ pci_dev_t devbusfn;
+ int mem;
+#endif
unsigned int *vm, i;
memset (sm501, 0, sizeof (GraphicDevice));
+#ifdef CONFIG_VIDEO_SM501_PCI
+ printf(Video: );
+
+ /* Look for SM501/SM502 chips */
+ devbusfn = pci_find_devices(sm501_pci_tbl, 0);
+ if (devbusfn 0) {
+ printf (PCI Controller not found.\n);
+ goto not_pci;
+ }
+
+ /* Setup */
+ pci_write_config_dword (devbusfn, PCI_COMMAND,
+ (PCI_COMMAND_MEMORY | PCI_COMMAND_IO));
+ pci_read_config_word (devbusfn, PCI_DEVICE_ID, device_id);
+ pci_read_config_dword (devbusfn, PCI_REVISION_ID, id);
+ pci_read_config_dword (devbusfn, PCI_BASE_ADDRESS_0, pci_mem_base);
+ pci_read_config_dword (devbusfn, PCI_BASE_ADDRESS_1, pci_mmio_base);
+ sm501.frameAdrs = pci_mem_to_phys (devbusfn, pci_mem_base);
+ sm501.isaBase = pci_mem_to_phys (devbusfn, pci_mmio_base);
+
+ if (sm501.isaBase)
+ write_reg32 = write_le32;
+
+ mem = in_le32 ((unsigned __iomem *)(sm501.isaBase + 0x10));
+ mem = (mem 0xe000) 13;
+ switch (mem) {
+ case 1:
+ mem = 8;
+ break;
+ case 2:
+ mem = 16;
+ break;
+ case 3:
+ mem = 32;
+ break;
+ case 4:
+ mem = 64;
+ break;
+ case 5:
+ mem = 2;
+ break;
+ case 0:
+ default:
+ mem = 4;
+ }
+ printf (PCI SM50%d %d MB\n, ((id 0xff) == 0xC0) ? 2 : 1, mem);
+not_pci:
+#endif
/*
* Initialization of the access to the graphic chipset Retreive base
* address of the chipset (see board/RPXClassic/eccx.c)
*/
- if ((sm501.isaBase = board_video_init ()) == 0) {
- return (NULL);
+ if (!sm501.isaBase) {
+ sm501.isaBase = board_video_init ();
+ if (!sm501.isaBase)
+ return NULL;
}
- if ((sm501.frameAdrs = board_video_get_fb ()) == 0) {
- return (NULL);
+ if (!sm501.frameAdrs) {
+ sm501.frameAdrs = board_video_get_fb ();
+ if (!sm501.frameAdrs)
+ return NULL;
}
sm501.winSizeX = board_get_width ();
diff --git a/include/pci_ids.h b/include/pci_ids.h
index edfdc1e..dcc381d 100644
--- a/include/pci_ids.h
+++ b/include/pci_ids.h
@@ -1454,6 +1454,7 @@
#define PCI_DEVICE_ID_SMI_710 0x0710
#define PCI_DEVICE_ID_SMI_712 0x0712
#define PCI_DEVICE_ID_SMI_810 0x0810
+#define PCI_DEVICE_ID_SMI_501 0x0501
#define PCI_VENDOR_ID_HUGHES 0x1273
#define PCI_DEVICE_ID_HUGHES_DIRECPC 0x0002
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91 i2c support
Dear Maxim Podbereznyy, please keep the mailing list on cc: In message aanlktikzgywfuvnktdd97pleuin0wn5mrzuvoqdjv...@mail.gmail.com you wrote: I'm sorry I did not mention about I need *AT91* i2c support in u-boot. I know that a general i2c is supported in u-boot since the ages. It seems there are a number of AT91 based boards in mainline that use I2C: - g -l AT91 include/configs/* | xargs egrep -l I2C include/configs/at91rm9200ek.h include/configs/cmc_pu2.h include/configs/cpuat91.h include/configs/eb_cpux9k2.h include/configs/kb9202.h include/configs/m501sk.h include/configs/mp2usb.h include/configs/otc570.h What exactly is the problem? I use references from linux4sam.org to build u-boot and v1.3.4 is used there. Actually I tried to find more recent version of u-boot for AT91 but I have no idea what linux4sam.org is and in which way they might be an authority of which U-Boot versions are considered to be current. All I can tell you is that U-Boot 1.3.4 is 21 months old, which is a long, long time. with no luck because u-boot/u-boot-at91.git refers to exactly 1.3.4. This is wrong. The top of tree of u-boot/u-boot-at91.git is at commit - git describe remotes/u-boot-at91.git/master v2009.06-rc1-5-gf8ddcd5 This is 2065 commits after v1.3.4 and means that a total of 299799 lines have been added since, 141729 lines removed, and 158070 lines changed. If you http://git.denx.de/?p=u-boot.git;a=forks you can also see that the u-boot-at91.git repository is listed as orphaned, which means it is probably not the best base when looking for current code. 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 Plan to throw one away. You will anyway. - Fred Brooks, The Mythical Man Month ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:io.h: define __io() macro if not defined erlier
Dear Wolfgang,
Am 25.05.2010 13:29, schrieb Wolfgang Denk:
In message 4bfb8708.4010...@corscience.de you wrote:
I think the easiest way to solve this is to create another patch
including exactely the changes sent before plus removing {in|out}[bwl]
macros in omap1510.h.
Well ... this statement was a bit precipitate. Just defining __io() to
get {in|out}[bwl] macros in asm/io.h for arch arm is dangerous cause the
enabled macros do conversion from/to little endian. This is ok for
some/most current arm devices but may be wrong for older ones (eg.
omap1510).
Sounds like a plan to me.
I can not test the generated code on omap1510 therefore my current
suggestion is to modify commit a45dde2293c816138e53c26eca6fd0322583f9a6
to something like attached at end of this message. Each devices asm/io.h
using dm9000x defines __raw_{read|write}[bwl] and therefore it would be
an easy task (easier than rewriting arm asm/io.h).
Ben and Mike, can you please give a statement to this suggestion?
regards
Andreas Bießmann
---
diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c
index f121286..84f67b1 100644
--- a/drivers/net/dm9000x.c
+++ b/drivers/net/dm9000x.c
@@ -117,12 +117,12 @@ static void DM9000_iow(int reg, u8 value);
/* DM9000 network board routine */
-#define DM9000_outb(d,r) outb(d, r)
-#define DM9000_outw(d,r) outw(d, r)
-#define DM9000_outl(d,r) outl(d, r)
-#define DM9000_inb(r) inb(r)
-#define DM9000_inw(r) inw(r)
-#define DM9000_inl(r) inl(r)
+#define DM9000_outb(d,r) __raw_writeb(d, r)
+#define DM9000_outw(d,r) __raw_writew(d, r)
+#define DM9000_outl(d,r) __raw_writel(d, r)
+#define DM9000_inb(r) __raw_readb(r)
+#define DM9000_inw(r) __raw_readw(r)
+#define DM9000_inl(r) __raw_readl(r)
#ifdef CONFIG_DM9000_DEBUG
static void
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: add initilisation of watchdog in init_sequence
For platforms that implement a hardware watchdog, call its initialization
routine in init_sequence.
This location has been chosen to be the closest to initialization of console as
some watchdog drivers are writing status messages. On the other hand, watchdog
setup should be close to chip startup to be able to begin the triggering
quickly.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
arch/arm/lib/board.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index f5660a9..569009e 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -70,6 +70,10 @@ extern int AT91F_DataflashInit(void);
extern void dataflash_print_info(void);
#endif
+#ifdef CONFIG_HW_WATCHDOG
+extern void hw_watchdog_init(void);
+#endif
+
#ifndef CONFIG_IDENT_STRING
#define CONFIG_IDENT_STRING
#endif
@@ -251,6 +255,9 @@ init_fnc_t *init_sequence[] = {
serial_init,/* serial communications setup */
console_init_f, /* stage 1 init of console */
display_banner, /* say that we are here */
+#if defined(CONFIG_HW_WATCHDOG)
+ hw_watchdog_init, /* watchdog setup */
+#endif
#if defined(CONFIG_DISPLAY_CPUINFO)
print_cpuinfo, /* display cpu info (and speed) */
#endif
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Internet Users Reward
Internet Users Reward For the Last time, we are pleased to notify you of your Windows© E-Award for 2.5, million. Please confirm if you received our previous message with; E-ticket number: 7219231BB-988, Category: A, Draw: 6756 Amount: 2.5, million Dollars You may establish contact with the Enquiry Officer via the e-mail address below with the information's necessary: Name:, Address:, Phone:, Cell Phone:, Email:, Alternative Email:, Occupation:, and E-ticket number: Enquiry officer: Damien Lewis, Tel: +31 626 006 051 Ext; 1000, E-Mail: [ enquirydept_le...@live.nl ] NOTE: You are expected to contact the Enquiry Officer for details of claims. Kerri Pingree. Promotions Co-ordinator. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] watchdog petting during autoboot delay
Watchdog resets were experienced during autoboot delay. Petting the watchdog
during abortboot() function solve the issue.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
common/main.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/common/main.c b/common/main.c
index f7e7c1c..ea040aa 100644
--- a/common/main.c
+++ b/common/main.c
@@ -159,6 +159,7 @@ static __inline__ int abortboot(int bootdelay)
* when catch up.
*/
do {
+ WATCHDOG_RESET(); /* Trigger watchdog, if needed */
if (tstc()) {
if (presskey_len presskey_max) {
presskey [presskey_len ++] = getc();
@@ -251,6 +252,7 @@ static __inline__ int abortboot(int bootdelay)
# endif
break;
}
+ WATCHDOG_RESET(); /* Trigger watchdog, if needed
*/
udelay(1);
}
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Training on FP7 in London (u-boot@lists.denx.de)
inline: a.gif___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/17] SPARC: added unaligned definitions, patch supplied by Magnus Sjalander.
Hi, Thank you for the input, I will resend the patch with Magnus as author. Daniel Mike Frysinger wrote: the subject line is incorrect. you dont credit people via summary/changelogs, you do it via the tags. so if Magnus wrote this patch, he should be credited with authorship (so use --author when committing). if he gave tips or something, then perhaps use Reported-by. -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] avr32 compilation fixed
Compilation was broken in atstk100x boards (at least) due to missing file unaligned.h I hope following patch helps. Regards, Xulio Coira. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] avr32: use generic unaligned.h
Signed-off-by: Xulio Coira xul...@gmail.com --- arch/avr32/include/asm/unaligned.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) create mode 100644 arch/avr32/include/asm/unaligned.h diff --git a/arch/avr32/include/asm/unaligned.h b/arch/avr32/include/asm/unaligned.h new file mode 100644 index 000..34b9ccc --- /dev/null +++ b/arch/avr32/include/asm/unaligned.h @@ -0,0 +1,6 @@ +#ifndef _ASM_AVR32_UNALIGNED_H +#define _ASM_AVR32_UNALIGNED_H + +#include asm-generic/unaligned.h + +#endif -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 01/17] SPARC: added unaligned definitions
From: Magnus Sjalander mag...@gaisler.com Signed-off-by: Daniel Hellstrom dan...@gaisler.com --- arch/sparc/include/asm/byteorder.h |1 + arch/sparc/include/asm/unaligned.h | 10 ++ 2 files changed, 11 insertions(+), 0 deletions(-) create mode 100644 arch/sparc/include/asm/unaligned.h diff --git a/arch/sparc/include/asm/byteorder.h b/arch/sparc/include/asm/byteorder.h index b9fc656..e3b3dec 100644 --- a/arch/sparc/include/asm/byteorder.h +++ b/arch/sparc/include/asm/byteorder.h @@ -32,6 +32,7 @@ #if defined(__GNUC__) !defined(__STRICT_ANSI__) #define __BYTEORDER_HAS_U64__ +#define __SWAB_64_THRU_32__ #endif #include linux/byteorder/big_endian.h #endif /* _SPARC_BYTEORDER_H */ diff --git a/arch/sparc/include/asm/unaligned.h b/arch/sparc/include/asm/unaligned.h new file mode 100644 index 000..0e646f7 --- /dev/null +++ b/arch/sparc/include/asm/unaligned.h @@ -0,0 +1,10 @@ +#ifndef _ASM_SPARC_UNALIGNED_H +#define _ASM_SPARC_UNALIGNED_H + +/* + * The SPARC can not do unaligned accesses, it must be split into multiple + * byte accesses. The SPARC is in big endian mode. + */ +#include asm-generic/unaligned.h + +#endif /* _ASM_SPARC_UNALIGNED_H */ -- 1.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-sparc.git
Dear Wolfgang, Please pull the 17 patches in the master branch of u-boot-sparc repository. I have rebased the patches and updated the first patch according to Mike Drysingers comments. Thanks, Daniel The following changes since commit 209c040b86ce7081f25dd547913d86d597e8ac34: Magnus Sjalander (1): SPARC: added unaligned definitions are available in the git repository at: git://www.denx.de/git/u-boot-sparc.git master Daniel Hellstrom (16): GRETH: Added support for selecting PHY address from config, PHY address was always set to zero before. GRETH: Added extra RESET, this is needed if GRETH was stopped during an ethernet frame reception. LEON3: reimplemented AMBA PlugPlay scanning routines. LEON3: added memory controller initialization using the new AMBA PnP routines. LEON3: Moved GRLIB core header files to common include/grlib directory LEON3: serial baud rate register support multiple buses with different frequency. SPARC: added function that checks if IRQ is on or off. LEON3: added busy wait function, made wait_ms() work when IRQ is disabled. LEON3: added CPU count and frequency detection. SPARC: removed USB stop from linux bootm, arch-independent bootm stop USB. SPARC: added optional cpu_late_init routine. LEON3: Added GRETH EDCL debug link IP address initialization. LEON: added support for GRLIB SPI Memory controller, spi command interface. LEON3: fixed MMU table for systems with larger memory than 128MB. bootm command: added argument to arch_preboot_os, function may depend on OS type. SPARC, LEON3: added support for multiprocessing, tested Linux 2.6.21.1 SMP and RTEMS-4.10 AMP. arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +- arch/sparc/cpu/leon3/Makefile |5 +- arch/sparc/cpu/leon3/ambapp.c | 581 --- arch/sparc/cpu/leon3/ambapp_low.S | 798 +++ arch/sparc/cpu/leon3/ambapp_low_c.S | 133 + arch/sparc/cpu/leon3/cpu.c | 52 ++- arch/sparc/cpu/leon3/cpu_init.c | 228 - arch/sparc/cpu/leon3/cpu_mp.c | 87 arch/sparc/cpu/leon3/greth.c| 152 ++ arch/sparc/cpu/leon3/interrupts.c |7 +- arch/sparc/cpu/leon3/memcfg.c | 276 +++ arch/sparc/cpu/leon3/memcfg.h | 105 arch/sparc/cpu/leon3/memcfg_low.S | 270 +++ arch/sparc/cpu/leon3/prom.c | 55 ++- arch/sparc/cpu/leon3/serial.c | 41 ++- arch/sparc/cpu/leon3/start.S| 106 arch/sparc/cpu/leon3/usb_uhci.c |4 +- arch/sparc/include/asm/boot_mp.h| 70 +++ arch/sparc/include/asm/irq.h|3 + arch/sparc/include/asm/leon3.h | 13 + arch/sparc/lib/Makefile |2 +- arch/sparc/lib/board.c | 19 + arch/sparc/lib/boot_mp.c| 177 +++ arch/sparc/lib/bootm.c | 65 ++- arch/sparc/lib/interrupts.c |7 + board/gaisler/gr_cpci_ax2000/u-boot.lds |7 + board/gaisler/gr_ep2s60/u-boot.lds |7 + board/gaisler/gr_xc3s_1500/u-boot.lds |7 + board/gaisler/grsim/u-boot.lds |7 + common/cmd_ambapp.c | 564 +- common/cmd_bootm.c |8 +- drivers/net/greth.c | 98 +++-- drivers/spi/Makefile|1 + drivers/spi/spimctrl_spi.c | 263 ++ include/ambapp.h| 488 +++- include/ambapp_ids.h| 256 ++ include/configs/gr_cpci_ax2000.h| 39 +- include/configs/gr_ep2s60.h | 44 ++- include/configs/gr_xc3s_1500.h | 37 +- include/configs/grsim.h | 39 +- include/grlib/apbuart.h | 63 +++ include/grlib/gptimer.h | 50 ++ include/grlib/greth.h | 103 include/grlib/irqmp.h | 39 ++ include/grlib/spimctrl.h| 69 +++ 45 files changed, 4442 insertions(+), 1005 deletions(-) create mode 100644 arch/sparc/cpu/leon3/ambapp_low.S create mode 100644 arch/sparc/cpu/leon3/ambapp_low_c.S create mode 100644 arch/sparc/cpu/leon3/cpu_mp.c create mode 100644 arch/sparc/cpu/leon3/greth.c create mode 100644 arch/sparc/cpu/leon3/memcfg.c create mode 100644 arch/sparc/cpu/leon3/memcfg.h create mode 100644 arch/sparc/cpu/leon3/memcfg_low.S create mode 100644 arch/sparc/include/asm/boot_mp.h create mode 100644 arch/sparc/lib/boot_mp.c create mode 100644 drivers/spi/spimctrl_spi.c create mode 100644 include/ambapp_ids.h create mode 100644 include/grlib/apbuart.h create mode 100644 include/grlib/gptimer.h create mode 100644 include/grlib/greth.h create mode 100644 include/grlib/irqmp.h create mode 100644
Re: [U-Boot] [PATCH] ubifsmount fails due to not initialized list
Hi, On Wed, May 05, 2010 at 03:10:20PM +0100, Quotient Remainder wrote: On Wed, May 5, 2010 at 1:59 PM, Stefano Babic sba...@denx.de wrote: Quotient Remainder wrote: Out of interest, how did something like this get away with only causing an occasional failure? Well, there are some explanations. MMU is normally off and a Null Pointer does not cause an exception in u-boot. If we get a failure, it depends on the architecture we are using. On PowerPC, address 0 is accessible and then we get no failure. In this particular case (ubifsmount), the list is set but not used by the calling function. Because writing to address 0 is allowed, the bug is not noticeable. Different is on arm, where I have found the problem. Because in this case address 0 is not accessible at all, u-boot hangs and it is not possible to avoid to see that we have a problem I've been using UBIFS on arm (1136) with the v2009.11 release and it works almost all the time. Sometimes U-Boot fails to mount the UBIFS (1 in 100 boots, maybe), and in these cases I was putting it down to forgetting to do a sync in Linux before rebooting. I wonder if this was the problem all along... Probably not. IMHO rebooting without a sync is pretty common and should work. With v2009.11 and the INIT_LIST_HEAD(ubifs_fs_type.fs_supers); fix I was able to force a mount-failure of UBIFS in u-boot by executing some tar under linux in parallel and pulling the plug in the meantime: tar zxf some_tar.tgz mkdir -p P; tar zxf some_tar.tgz -C P I fixed it (fixed as in http://thereifixedit.com) by disabling journal-replaying. In fs/ubifs/super.c:686 I skipped ubifs_replay_journal(c). Without that fix I needed the linux kernel to once mount the volume and replay the journal. Afterwards everything was fine on next volume mount in u-boot. I failed to find the cause in ubifs_replay_journal(). How harmful is the skipping of ubifs_replay_journal() ? Does someone have a real fix ? Christian Hohnstaedt -- Christian Hohnstaedt / Project Manager Hardware and Manufacturing Innominate Security Technologies AG / protecting industrial networks tel: +49.30.921028.208 / fax: +49.30.921028.020 Rudower Chaussee 13, D-12489 Berlin / http://www.innominate.com Register Court: AG Charlottenburg, HR B 81603 Management Board: Dirk Seewald Chairman of the Supervisory Board: Volker Bibelhausen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] *** SUBJECT HERE ***
This trivial patch remove the 64-bit division into print_size code. Luigi 'Comio' Mantellini (1): [OLT-M68K] Avoid 64bit division in print_size lib/display_options.c | 15 --- 1 files changed, 8 insertions(+), 7 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [OLT-M68K] Avoid 64bit division in print_size
Signed-off-by: Luigi 'Comio' Mantellini luigi.mantell...@idf-hit.com
---
lib/display_options.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index 86df05d..eca5415 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -45,14 +45,14 @@ int display_options (void)
*/
void print_size(unsigned long long size, const char *s)
{
- unsigned long m = 0, n;
+ unsigned long m = 0, n, rem;
static const char names[] = {'E', 'P', 'T', 'G', 'M', 'K'};
- unsigned long long d = 1ULL (10 * ARRAY_SIZE(names));
+ unsigned int d_shift = 10 * ARRAY_SIZE(names);
char c = 0;
unsigned int i;
- for (i = 0; i ARRAY_SIZE(names); i++, d = 10) {
- if (size = d) {
+ for (i = 0; i ARRAY_SIZE(names); i++, d_shift -= 10) {
+ if (size = (1ULL d_shift)) {
c = names[i];
break;
}
@@ -63,11 +63,12 @@ void print_size(unsigned long long size, const char *s)
return;
}
- n = size / d;
+ n = size d_shift;
+ rem = size - (n d_shift);
/* If there's a remainder, deal with it */
- if(size % d) {
- m = (10 * (size - (n * d)) + (d / 2) ) / d;
+ if(rem) {
+ m = (10 * rem + (1ULL (d_shift -1 ))) d_shift;
if (m = 10) {
m -= 10;
--
1.7.0.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Wolfgang Denk wrote:
Thanks. Just to be clear, do you expect fdt_fw_addr always to point to a
FIT-wrapped firmware binary?
Please re-read the IRC log. Kumar explicitly stated he was trying to
avoid making FIT images mandatory, at least for now.
And he proposed a board-specific function that would allow this to work, but
you rejected it. So I don't still know how to implement what you want.
And I explicitly
wrote that it should be the address of a IH_TYPE_FIRMWARE image
then.
So you're saying fdt_fw_addr should pointer to either a FIT image or the
older image type? What's the point in supporting the older type? Isn't it
deprecated?
But either way, the firmware needs to be wrapped inside an image object. I
think Kumar was implying that he didn't want to make *any* image type (FIT
or legacy) mandatory.
We never finished this discussion. My point was that even if the firmware
is wrapped in a FIT image, the process by which the firmware is actually
inserted into the device tree is specific to the actual firmware. You could
even say it's board-specific.
You could say that. You could also say that 2+2=5.
I will argue in both cases.
I don't understand your position. The method by which firmware is to be
embedded in the device tree *is* specific to the kind of firmware in
question, and therefore requires knowledge of the kind of firmware. A QE
firmware is not embedded in the device tree the same way an FPGA firmware
is. This is just a fact.
You keep telling me that there's a counter argument to this statement, but I
don't know what it is. You just tell me you disagree. In effect, you are
the one saying that 2+2=5.
In contrast, you want the fdt relocation code to be able to increase the
size of the fdt without knowing any details about the firmware itself.
That's not correct. At least we know the address and the size.
Address and size is *not* details about the firmware itself. When I say
details about the firmware itself, I mean stuff like what kind of firmware
it is, what chip it's for, what it's supposed to do, etc.
And if
you follow my recommendation of using the name entry for type
information (or come up with a better proposal) we also know the
type.
Are you talking about the ih_name field in the image_header_t structure? So
for instance, if the ih_name field says QE Firmware, we can assume assume
that it's a QE firmware, and the generic code should have something like
this in it:
#include qe.h
if (strcmp(image-ih_name, QE Firmware) == 0) {
/*
* Embed the firmware in the device tree using the binding
* definition in Documentation/powerpc/dts-bindings/fsl/cpm_qe
* /qe.txt
*/
}
Doesn't that seem really clunky to you? That requires the generic code to
have knowledge of every type of firmware. Wouldn't it be simpler if we just
followed Kumar's recommendation to have a board-specific __weak__ function
that handled this code?
Therefore, there will be two pieces of code that references fdt_fw_addr.
The first is in boot_relocate_fdt(), which will extract the size information
from the FIT image that fdt_fw_addr points to. The second is the QE code
which extracts the firmware from the FIT image and embeds it into the device
tree, in a QE-specific way.
I see no inherent problems with having a generic, common part for all
systems enabling this feature, plus eventually hooks for (additional)
customized processing of certain firmware image types.
So you agree with Kumar's idea of having a weak function that embeds the
firmware into the device tree, but the firmware must always be wrapped in an
image format?
Of course one can argue that making the decision on the type based on
the name entry is a stupid thing, and come up for example with
additional IH_TYPE entries; or even try to define subtypes. I think
I'll leave this as an exercise to you :-)
I'd rather not use subtypes, because I don't think we want anything like this:
if (is_qe_firmware()) {
/* embed QE firmware */
} else if (is_amd_fpga_firmware()) {
/* embed AMD fpga firmware */
} ...
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [OLT-M68K] Avoid 64bit division in print_size
On Wed, May 26, 2010 at 9:01 AM, Luigi 'Comio' Mantellini luigi.mantell...@idf-hit.com wrote: Signed-off-by: Luigi 'Comio' Mantellini luigi.mantell...@idf-hit.com --- You're a little late: http://git.denx.de/?p=u-boot.git;a=commit;h=f2d76ae4fdde180e120ea2d29d6ef881360b3cba -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Dear Timur Tabi,
In message 4bfd3a39.4090...@freescale.com you wrote:
Please re-read the IRC log. Kumar explicitly stated he was trying to
avoid making FIT images mandatory, at least for now.
And he proposed a board-specific function that would allow this to work, but
you rejected it. So I don't still know how to implement what you want.
Well, in a way that may be image-type dependent, but that is not
board-specific.
And I explicitly
wrote that it should be the address of a IH_TYPE_FIRMWARE image
then.
So you're saying fdt_fw_addr should pointer to either a FIT image or the
older image type? What's the point in supporting the older type? Isn't it
deprecated?
No, not really. It works fine for the intended purpose. Actually I
still prefer it in a lot of cases because we have checksum protection
of the header information, while you can have a totally corrupted
DTB without really being able to detect it.
But either way, the firmware needs to be wrapped inside an image object. I
think Kumar was implying that he didn't want to make *any* image type (FIT
or legacy) mandatory.
And where would you then get type and size information from?
I don't understand your position. The method by which firmware is to be
embedded in the device tree *is* specific to the kind of firmware in
question, and therefore requires knowledge of the kind of firmware. A QE
firmware is not embedded in the device tree the same way an FPGA firmware
is. This is just a fact.
I also said that I see no problems with ading type specific hooks.
You keep telling me that there's a counter argument to this statement, but I
don't know what it is. You just tell me you disagree. In effect, you are
the one saying that 2+2=5.
Really?
In contrast, you want the fdt relocation code to be able to increase the
size of the fdt without knowing any details about the firmware itself.
That's not correct. At least we know the address and the size.
Address and size is *not* details about the firmware itself. When I say
No, but they are important properties, for example when it comes to
find out by how much the DT needs to be grown.
details about the firmware itself, I mean stuff like what kind of firmware
it is, what chip it's for, what it's supposed to do, etc.
Maybe we can abstrct off most of this, and/or leave it to image type
specific handlers?
Are you talking about the ih_name field in the image_header_t structure? So
for instance, if the ih_name field says QE Firmware, we can assume assume
that it's a QE firmware, and the generic code should have something like
this in it:
#include qe.h
No. There would be no qe.h needed in that generic code.
if (strcmp(image-ih_name, QE Firmware) == 0) {
/*
* Embed the firmware in the device tree using the binding
* definition in Documentation/powerpc/dts-bindings/fsl/cpm_qe
* /qe.txt
*/
}
No. More like
if (strcmp(image-ih_name, QE Firmware) == 0)
handle_fdt_fw_qe(image);
or similar. Probably #ifdef'ed for machines that have enabled QE
support in their board config, or with a weak handle_fdt_fw_qe() that
gets filled in for QE aware boards only so the compiler optimizes away
that call everywhere else.
Doesn't that seem really clunky to you? That requires the generic code to
have knowledge of every type of firmware. Wouldn't it be simpler if we just
followed Kumar's recommendation to have a board-specific __weak__ function
that handled this code?
D*mn. Don't you get it. There is NOT BOARD-SPECIFIC CODE anywhere.
It is feature specific. Either you enable QE support or not, but then
the same code will be used for all boards enabling this feature.
I see no inherent problems with having a generic, common part for all
systems enabling this feature, plus eventually hooks for (additional)
customized processing of certain firmware image types.
So you agree with Kumar's idea of having a weak function that embeds the
firmware into the device tree, but the firmware must always be wrapped in an
image format?
Yes. Note that there is NOT any board-specific code.
Of course one can argue that making the decision on the type based on
the name entry is a stupid thing, and come up for example with
additional IH_TYPE entries; or even try to define subtypes. I think
I'll leave this as an exercise to you :-)
I'd rather not use subtypes, because I don't think we want anything like this:
if (is_qe_firmware()) {
/* embed QE firmware */
} else if (is_amd_fpga_firmware()) {
/* embed AMD fpga firmware */
} ...
In which way would that be worse compared to
if (strcmp(image-ih_name, QE Firmware) == 0)
handle_fdt_fw_qe(image);
else if (strcmp(image-ih_name, AMD FPGA Firmware) == 0)
handle_fdt_fw_amd(image);
...
?
Actually it would be easier to read...
Best regards,
Re: [U-Boot] [PATCH] [OLT-M68K] Avoid 64bit division in print_size
I'm sorry! my tree is out of date (2010/05/15) :) I'm using the toolchain coldfire-4.4 from Codesourcery (Sourcery G++ Lite 4.4-217) Today I tried to build the cf547x_8x target and I noticed a div by 0 issue on the __udivdi3 (n = size / d) ... I checked the operands that were ok, but I wasn't able to understand the real problem. In order to avoid the (bugged?) __udivdi3 call I wrote this workaroud. Any idea regarding this issue? Of course, avoiding the __udivdi3 call, the u-boot works fine. best regards, luigi mercoledì 26 maggio 2010 17:32 Timur Tabi timur.t...@gmail.com ha scritto: On Wed, May 26, 2010 at 9:01 AM, Luigi 'Comio' Mantellini luigi.mantell...@idf-hit.com wrote: Signed-off-by: Luigi 'Comio' Mantellini luigi.mantell...@idf-hit.com --- You're a little late: http://git.denx.de/?p=u-boot.git;a=commit;h=f2d76ae4fdde180e120ea2d29d6ef88 1360b3cba -- Luigi 'Comio' Mantellini RD - Software Industrie Dial Face S.p.A. Via Canzo, 4 20068 Peschiera Borromeo (MI) Italy Tel.: +39 02 5167 2813 Fax: +39 02 5167 2459 E-mail: luigi.mantell...@idf-hit.com Website: http://www.idf-hit.com Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. Rispetta l'ambiente. Non stampare questa mail se non è realmente necessario. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorized. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Help the environment. Please do not print this email unless it is absolutely necessary. idf_logo.png 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] libfdt: make fdt_increase_size() available to everyone
Wolfgang Denk wrote:
And he proposed a board-specific function that would allow this to work, but
you rejected it. So I don't still know how to implement what you want.
Well, in a way that may be image-type dependent, but that is not
board-specific.
Technically, that's true, but in most cases the function that returns the
address/size of the firmware would exist in board code.
For example, the MPC8323 has a bug in its QE UART support, so if you want to
use the QE as a UART, you need to download a special QE firmware to
work-around the bug. So even though all MPC8323 boards have a QE that can
run in UART mode, only those boards that have a QE wired to an RS232 port
need to enable the UART work-around, so only those boards would embed the
firmware in the device tree.
So you're saying fdt_fw_addr should pointer to either a FIT image or the
older image type? What's the point in supporting the older type? Isn't it
deprecated?
No, not really. It works fine for the intended purpose. Actually I
still prefer it in a lot of cases because we have checksum protection
of the header information, while you can have a totally corrupted
DTB without really being able to detect it.
Ok.
But either way, the firmware needs to be wrapped inside an image object. I
think Kumar was implying that he didn't want to make *any* image type (FIT
or legacy) mandatory.
And where would you then get type and size information from?
For example, QE firmware comes with its own header that includes size
information, as well as a magic number and a CRC. See struct qe_firmware in
qe.h. Since we distribute the QE firmware on our boards as-is, it would be
nice if we didn't need to wrap those binaries inside a legacy/FIT image. So
on an MPC8323E-MDS board, for example, the board-specific implementation of
fdt_board_size() could support having fdt_fw_addr points directly to a QE
firmware binary. We already have code that validates a QE firmware (see
function qe_upload_firmware()), so this is safe.
For those firmware types that don't have such a header built-in, they would
need to be wrapped in a legacy/FIT image.
I don't understand your position. The method by which firmware is to be
embedded in the device tree *is* specific to the kind of firmware in
question, and therefore requires knowledge of the kind of firmware. A QE
firmware is not embedded in the device tree the same way an FPGA firmware
is. This is just a fact.
I also said that I see no problems with ading type specific hooks.
Ok.
That's not correct. At least we know the address and the size.
Address and size is *not* details about the firmware itself. When I say
No, but they are important properties, for example when it comes to
find out by how much the DT needs to be grown.
I agree, although I would say that only size is necessary.
details about the firmware itself, I mean stuff like what kind of firmware
it is, what chip it's for, what it's supposed to do, etc.
Maybe we can abstrct off most of this, and/or leave it to image type
specific handlers?
I'm not sure that's a good idea. We can't predict what kind of firmware
we'll need to support in the future, and a board-specific fdt_board_size()
function is, in my opinion, a more elegant way to solve the problem.
#include qe.h
No. There would be no qe.h needed in that generic code.
if (strcmp(image-ih_name, QE Firmware) == 0) {
/*
* Embed the firmware in the device tree using the binding
* definition in Documentation/powerpc/dts-bindings/fsl/cpm_qe
* /qe.txt
*/
}
No. More like
if (strcmp(image-ih_name, QE Firmware) == 0)
handle_fdt_fw_qe(image);
Where is the function prototype for handle_fdt_fw_qe()? Wouldn't it be in qe.h?
Also, I really think the strcmp is a bad idea, because then we have to put a
specific string in the ih_name field, not something unique to the actual
firmware in the image.
or similar. Probably #ifdef'ed for machines that have enabled QE
support in their board config, or with a weak handle_fdt_fw_qe() that
gets filled in for QE aware boards only so the compiler optimizes away
that call everywhere else.
So it would look like board_init_r()?
Doesn't that seem really clunky to you? That requires the generic code to
have knowledge of every type of firmware. Wouldn't it be simpler if we just
followed Kumar's recommendation to have a board-specific __weak__ function
that handled this code?
D*mn. Don't you get it. There is NOT BOARD-SPECIFIC CODE anywhere.
It is feature specific. Either you enable QE support or not, but then
the same code will be used for all boards enabling this feature.
Ok.
I see no inherent problems with having a generic, common part for all
systems enabling this feature, plus eventually hooks for (additional)
customized processing of certain firmware image types.
So you agree with Kumar's idea of having a weak function that embeds
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
On Wed, May 26, 2010 at 11:38:27AM -0500, Timur Tabi wrote: I believe we should have a board-specific function that figures out how much extra space is needed, and just returns a single integer that the boot_relocate_fdt() uses to pad the FDT when it relocates it. Why don't we just grow the FDT on demand, after we make sure that it always lives someplace that is safely growable? Or if we absolutely must resize it all at once, have a variable that contains the size required, which gets increased by whatever init code determines a reason for it (whether it be QE firmware in this environment variable, some other firmware in that environment variable, just a bunch of nodes that u-boot creates on this platform, etc). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] USB: fix create_pipe()
create_pipe() can give wrong result if an expression is passed as the 'endpoint' argument -- due to missing parentheses. Thanks to Martin Mueller for finding the bug and providing the patch. Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com --- include/usb.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: u-boot/include/usb.h === --- u-boot.orig/include/usb.h +++ u-boot/include/usb.h @@ -259,7 +259,7 @@ int usb_set_interface(struct usb_device */ /* Create various pipes... */ #define create_pipe(dev,endpoint) \ - (((dev)-devnum 8) | (endpoint 15) | \ + (((dev)-devnum 8) | ((endpoint) 15) | \ ((dev)-speed 26) | (dev)-maxpacketsize) #define default_pipe(dev) ((dev)-speed 26) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:io.h: define __io() macro if not defined erlier
On Wednesday 26 May 2010 05:49:21 Andreas Bießmann wrote:
Am 25.05.2010 13:29, schrieb Wolfgang Denk:
In message 4bfb8708.4010...@corscience.de you wrote:
I think the easiest way to solve this is to create another patch
including exactely the changes sent before plus removing {in|out}[bwl]
macros in omap1510.h.
Well ... this statement was a bit precipitate. Just defining __io() to
get {in|out}[bwl] macros in asm/io.h for arch arm is dangerous cause the
enabled macros do conversion from/to little endian. This is ok for
some/most current arm devices but may be wrong for older ones (eg.
omap1510).
Sounds like a plan to me.
I can not test the generated code on omap1510 therefore my current
suggestion is to modify commit a45dde2293c816138e53c26eca6fd0322583f9a6
to something like attached at end of this message. Each devices asm/io.h
using dm9000x defines __raw_{read|write}[bwl] and therefore it would be
an easy task (easier than rewriting arm asm/io.h).
i changed the accessors to use in/out macros as i thought that was the correct
set of accessor functions to use. looking at a set of definitions and picking
a set because they look like they'll just work isnt how i set about it.
after having read the deviceiobook in the Linux kernel, i think the correct
funcs to use here are the read/write helpers. now that i have that
information, looking at the definitions shows that this should work for ARM
just fine.
so, to be clear, i think we should do:
-#define DM9000_outb(d,r) outb(d, r)
+#define DM9000_outb(d,r) writeb(d, r)
etc...
-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] libfdt: make fdt_increase_size() available to everyone
Scott Wood wrote: On Wed, May 26, 2010 at 11:38:27AM -0500, Timur Tabi wrote: I believe we should have a board-specific function that figures out how much extra space is needed, and just returns a single integer that the boot_relocate_fdt() uses to pad the FDT when it relocates it. Why don't we just grow the FDT on demand, after we make sure that it always lives someplace that is safely growable? We use lmb regions to allocate space for the fdt in the bootmap, so we need to know how big the lmb region should be before we allocate it. Resizing an lmb region will probably require moving it, and that might confuse the upper-level functions that expect the fdt pointer to remain constant. Or if we absolutely must resize it all at once, have a variable that contains the size required, which gets increased by whatever init code determines a reason for it (whether it be QE firmware in this environment variable, some other firmware in that environment variable, just a bunch of nodes that u-boot creates on this platform, etc). The issue is that how those functions will look. Kumar and I are advocating a board-specific weak function that figures it all out at once and returns a single number. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
On 05/26/2010 12:56 PM, Timur Tabi wrote: Scott Wood wrote: On Wed, May 26, 2010 at 11:38:27AM -0500, Timur Tabi wrote: I believe we should have a board-specific function that figures out how much extra space is needed, and just returns a single integer that the boot_relocate_fdt() uses to pad the FDT when it relocates it. Why don't we just grow the FDT on demand, after we make sure that it always lives someplace that is safely growable? We use lmb regions to allocate space for the fdt in the bootmap, so we need to know how big the lmb region should be before we allocate it. But you can reasonably allocate significantly more than you'll need without actually causing the fdt to get that big. The actual cap could be a board specific magic number (like CONFIG_SYS_MALLOC_LEN), or we could cap it at something based on the amount of RAM. Resizing an lmb region will probably require moving it, and that might confuse the upper-level functions that expect the fdt pointer to remain constant. Or if we absolutely must resize it all at once, have a variable that contains the size required, which gets increased by whatever init code determines a reason for it (whether it be QE firmware in this environment variable, some other firmware in that environment variable, just a bunch of nodes that u-boot creates on this platform, etc). The issue is that how those functions will look. What functions? I'm just talking about arbitrary code that runs before the fdt is resized, and after relocation (or even before if we make it a gd_t variable), and adds a certain amount to a variable. Kumar and I are advocating a board-specific weak function that figures it all out at once and returns a single number. That seems an awkward combination of centralization (you need to combine every fdt-expanding feature found on a board into the board file) and decentralization (if such a feature is added or changed you may need to update a bunch of board files). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32: use generic unaligned.h
On Wednesday 26 May 2010 07:52:37 Xulio Coira wrote: Signed-off-by: Xulio Coira xul...@gmail.com --- arch/avr32/include/asm/unaligned.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) create mode 100644 arch/avr32/include/asm/unaligned.h diff --git a/arch/avr32/include/asm/unaligned.h b/arch/avr32/include/asm/unaligned.h new file mode 100644 index 000..34b9ccc --- /dev/null +++ b/arch/avr32/include/asm/unaligned.h @@ -0,0 +1,6 @@ +#ifndef _ASM_AVR32_UNALIGNED_H +#define _ASM_AVR32_UNALIGNED_H + +#include asm-generic/unaligned.h + +#endif typically #ifdef protection isnt needed when the header is merely a stub that forwards to the asm-generic one. not that it hurts the vast majority of the time. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Wolfgang Denk wrote: Hm... looks as if you were repeating the same code 3 times. Please make this a function. The code isn't really the same. I would need to pass a lot of parameters to this function: the hose, the devdisr mask, the slot name, the slot number, the bus number, and so on. Actually it is not that many arguments. It is. Here's the prototype I came up with; static int configure_pci(enum srds_prtcl pci, const char *name, const char *target, int endpoint, int first_free_busno, phys_addr_t mem_addr, enum law_size mem_size, phys_addr_t io_addr, enum law_size io_size, struct fsl_pci_info *pci_info, struct pci_controller *hose); Are you sure you would really rather see this as its own function? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] watchdog petting during autoboot delay
On Wednesday 26 May 2010 06:34:49 Nicolas Ferre wrote:
--- a/common/main.c
+++ b/common/main.c
@@ -159,6 +159,7 @@ static __inline__ int abortboot(int bootdelay)
* when catch up.
*/
do {
+ WATCHDOG_RESET(); /* Trigger watchdog, if needed */
if (tstc()) {
if (presskey_len presskey_max) {
presskey [presskey_len ++] = getc();
@@ -251,6 +252,7 @@ static __inline__ int abortboot(int bootdelay)
# endif
break;
}
+ WATCHDOG_RESET(); /* Trigger watchdog, if needed
*/
udelay(1);
}
if your udelay() implementation isnt calling WATCHDOG_RESET(), it is broken.
yes, this is undocumented, but search the mailing archives for examples.
i believe the same goes for serial devices and their tstc() function.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
On 05/26/2010 01:12 PM, Timur Tabi wrote: Wolfgang Denk wrote: Hm... looks as if you were repeating the same code 3 times. Please make this a function. The code isn't really the same. I would need to pass a lot of parameters to this function: the hose, the devdisr mask, the slot name, the slot number, the bus number, and so on. Actually it is not that many arguments. It is. Here's the prototype I came up with; static int configure_pci(enum srds_prtcl pci, const char *name, const char *target, int endpoint, int first_free_busno, phys_addr_t mem_addr, enum law_size mem_size, phys_addr_t io_addr, enum law_size io_size, struct fsl_pci_info *pci_info, struct pci_controller *hose); Are you sure you would really rather see this as its own function? Perhaps (most of) this information could be put in a data structure to which you point? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Scott Wood wrote: Perhaps (most of) this information could be put in a data structure to which you point? That doesn't change the amount of information that needs to be passed, it only makes the prototype have fewer lines. The point I'm trying to make is that the code in question is not the same code copy/pasted three times. Every line is different. Moving that code into a function is not going to simplify anything. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Scott Wood wrote: But you can reasonably allocate significantly more than you'll need without actually causing the fdt to get that big. The actual cap could be a board specific magic number (like CONFIG_SYS_MALLOC_LEN), or we could cap it at something based on the amount of RAM. We have something like that already: #ifndef CONFIG_SYS_FDT_PAD #define CONFIG_SYS_FDT_PAD 0x3000 #endif And Wolfgang doesn't like it. I was going to do this in my board header file: #define CONFIG_SYS_MAX_QE_FW_SIZE 0x4000 #define CONFIG_SYS_FDT_PAD (0x3000 + CONFIG_SYS_MAX_QE_FW_SIZE) And I was even going to add code to the QE firmware functions to verify that the firmware is not larger than CONFIG_SYS_MAX_QE_FW_SIZE. The issue is that how those functions will look. What functions? I'm just talking about arbitrary code that runs before the fdt is resized, and after relocation (or even before if we make it a gd_t variable), and adds a certain amount to a variable. Actually, that would be *during* relocation because we relocate and resize the fdt in the same function: fdt_open_into(). Depending on the nature of the firmware, we may not know anything about the firmware until we try to boot Linux, so we need to decide where this arbitrary code is supposed to exist. Kumar and I are advocating a board-specific weak function that figures it all out at once and returns a single number. That seems an awkward combination of centralization (you need to combine every fdt-expanding feature found on a board into the board file) and decentralization (if such a feature is added or changed you may need to update a bunch of board files). We could have feature-specific functions that do the work of handling the fdt size for a specific feature. So qe_firmware_size(void *) would tell you the size of the QE firmware, and your board's fdt_board_size() would just be a front-end to qe_firmware_size(). Are you suggesting that we implement some user interface where the user, on the command line, can specify any number and type of firmware binaries to get embedded in the device tree? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] add 1-wire DS2401 serial number chip
Signed-off-by: Asen Dimov di...@ronetix.at
---
drivers/misc/Makefile |1 +
drivers/misc/ds2401.c | 265 +
include/ds2401.h | 36 +++
3 files changed, 302 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/ds2401.c
create mode 100644 include/ds2401.h
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 96aa331..4355b6e 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -32,6 +32,7 @@ COBJS-$(CONFIG_NS87308) += ns87308.o
COBJS-$(CONFIG_STATUS_LED) += status_led.o
COBJS-$(CONFIG_TWL4030_LED) += twl4030_led.o
COBJS-$(CONFIG_FSL_PMIC) += fsl_pmic.o
+COBJS-$(CONFIG_DS2401) += ds2401.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/misc/ds2401.c b/drivers/misc/ds2401.c
new file mode 100644
index 000..4298d8a
--- /dev/null
+++ b/drivers/misc/ds2401.c
@@ -0,0 +1,265 @@
+/*
+ * Copyright 2009, 2010
+ * Ilko Iliev il...@ronetix.at
+ * Ronetix Development Tools GmbH www.ronetix.at
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * Version 2 as published by the Free Software Foundation.
+ *
+ * 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
+ */
+
+/*
+ * Driver for 1-wire, DS2401, a Silicon Serial Number chip
+ *
+ * Driver usage:
+ *
+ * To build the driver add in a board config file:
+ * #define CONFIG_DS2401 1
+ *
+ * In the board specific file define the get and set functions
+ * to read and write one bit from/to PIO.
+ *
+ * If you want to set a specific first three bytes of the MAC address
+ * define CONFIG_MAC_OUI.
+ */
+
+#include common.h
+#include command.h
+#include ds2401.h
+
+#ifndef CONFIG_MAC_OUI
+#define CONFIG_MAC_OUI 02:00:00 /* Organizationally Unique Identifier*/
+#endif
+
+static DS2401_FUNCS *DS2401_Funcs = NULL;
+
+/*
+ * Generate a 1-wire reset, return 1 if no presence detect was found,
+ * return 0 otherwise.
+ */
+static int ds2401_reset(void)
+{
+ int result;
+
+ DS2401_Funcs-set(0);
+ udelay(480);
+ DS2401_Funcs-set(1);
+ udelay(70);
+
+ result = DS2401_Funcs-get();
+
+ udelay(410);
+ return result;
+}
+
+/*
+ * Send 1 a 1-wire write bit.
+ * Provide 10us recovery time.
+ */
+static void ds2401_write_bit(int bit)
+{
+ if (bit) {
+ /*
+* write '1' bit
+*/
+ DS2401_Funcs-set(0);
+ udelay(6);
+ DS2401_Funcs-set(1);
+ udelay(64);
+ } else {
+ /*
+* write '0' bit
+*/
+ DS2401_Funcs-set(0);
+ udelay(60);
+ DS2401_Funcs-set(1);
+ udelay(10);
+ }
+}
+
+/*
+ * Read a bit from the 1-wire bus and return it.
+ * Provide 10us recovery time.
+ */
+static int ds2401_read_bit(void)
+{
+ int result;
+
+ DS2401_Funcs-set(0);
+
+#ifdef __OPTIMIZE__
+ udelay(1);
+#endif
+
+ DS2401_Funcs-set(1);
+ udelay(9);
+
+ result = DS2401_Funcs-get();
+ udelay(55);
+
+ return result;
+}
+
+static void ds2401_write_byte(int data)
+{
+ int loop;
+
+ for (loop = 0; loop 8; loop++) {
+ ds2401_write_bit(data 0x01);
+ data = 1;
+ }
+}
+
+static int ds2401_read_byte(void)
+{
+ int loop, result = 0;
+
+ for (loop = 0; loop 8; loop++) {
+ result = 1;
+ if (ds2401_read_bit())
+ result |= 0x80;
+ }
+
+ return result;
+}
+
+static unsigned char ds2401_crc8_table[] = {
+ 0, 94, 188, 226, 97, 63, 221, 131, 194, 156, 126, 32, 163, 253, 31, 65,
+ 157, 195, 33, 127, 252, 162, 64, 30, 95, 1, 227, 189, 62, 96, 130, 220,
+ 35, 125, 159, 193, 66, 28, 254, 160, 225, 191, 93, 3, 128, 222, 60, 98,
+ 190, 224, 2, 92, 223, 129, 99, 61, 124, 34, 192, 158, 29, 67, 161, 255,
+ 70, 24, 250, 164, 39, 121, 155, 197, 132, 218, 56, 102, 229, 187, 89, 7,
+ 219, 133, 103, 57, 186, 228, 6, 88, 25, 71, 165, 251, 120, 38, 196, 154,
+ 101, 59, 217, 135, 4, 90, 184, 230, 167, 249, 27, 69, 198, 152, 122, 36,
+ 248, 166, 68, 26, 153, 199, 37, 123, 58, 100, 134, 216, 91, 5, 231, 185,
+ 140, 210, 48, 110, 237, 179, 81, 15, 78, 16, 242, 172, 47, 113, 147,
205,
+ 17, 79, 173, 243, 112, 46, 204, 146, 211, 141, 111, 49, 178, 236, 14,
80,
+ 175, 241, 19, 77, 206, 144, 114, 44, 109, 51, 209, 143, 12, 82,
[U-Boot] Debugging u-boot with bdi3000 basics
I have read section 10 of the manual which describes debugging u-boot and have further questions. 1) In section 10.4, Tips and Tricks, it says To prevent GDB from jumping around in the code when trying to single step, i. e. when it seems as if the code is not executing line by line, you can recompile your code with the following additional compiler options: -fno-schedule-insns -fno-schedule-insns In the u-boot developer world, what is the best practice for adding these compiler options? I see CFLAGS in config.mk and assume that is what needs to be modified. However, I need a HOWTODOITRIGHT 2) I am using a bdi3000. Is there no way to build u-boot so that it is directly loaded to RAM by the debugger and does not relocate itself? 3) The function board_init_f() in board.c makes calls to debug(). I cannot determine how to enable debug() output. I saw one reference in the manual, but it gave no specifics. Thanks, Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
On 05/26/2010 01:19 PM, Timur Tabi wrote: Scott Wood wrote: Perhaps (most of) this information could be put in a data structure to which you point? That doesn't change the amount of information that needs to be passed, it only makes the prototype have fewer lines. Which is relevant, given that you're whipping out a big scary-looking prototype as a reason to avoid refactoring. :-) The point I'm trying to make is that the code in question is not the same code copy/pasted three times. Every line is different. Moving that code into a function is not going to simplify anything. They are not identical lines, but they're doing the same basic thing -- making it data driven would be a proper separation of concerns. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Dear Timur Tabi,
In message 4bfd4e83.2080...@freescale.com you wrote:
Well, in a way that may be image-type dependent, but that is not
board-specific.
Technically, that's true, but in most cases the function that returns the
address/size of the firmware would exist in board code.
For example, the MPC8323 has a bug in its QE UART support, so if you want to
use the QE as a UART, you need to download a special QE firmware to
work-around the bug. So even though all MPC8323 boards have a QE that can
run in UART mode, only those boards that have a QE wired to an RS232 port
need to enable the UART work-around, so only those boards would embed the
firmware in the device tree.
Right. Then these boards can enable the feature in their board config
files, and get what they want. But it's still generic code, and not
spoecific to any special board.
But either way, the firmware needs to be wrapped inside an image object. I
think Kumar was implying that he didn't want to make *any* image type (FIT
or legacy) mandatory.
And where would you then get type and size information from?
For example, QE firmware comes with its own header that includes size
information, as well as a magic number and a CRC. See struct qe_firmware in
But we want a generic solution, and this includes firmware blobs that
may not contain such information. Ergo we use what we use elsewhere in
U-Boot for the very purpose: U-Boot image files.
For those firmware types that don't have such a header built-in, they would
need to be wrapped in a legacy/FIT image.
And for the sake of using common code we will do this always.
Maybe we can abstrct off most of this, and/or leave it to image type
specific handlers?
I'm not sure that's a good idea. We can't predict what kind of firmware
we'll need to support in the future, and a board-specific fdt_board_size()
function is, in my opinion, a more elegant way to solve the problem.
You completely fail to understand what board-specific means. After
so many rounds of discussion and so many attempts to explain this, you
still don't get it. I'm on the verge of giving up.
This code is in no way board-specific, so board-specific functions
make no sense.
Just swallow and accept this if you cannot understand it.
#include qe.h
No. There would be no qe.h needed in that generic code.
if (strcmp(image-ih_name, QE Firmware) == 0) {
/*
* Embed the firmware in the device tree using the binding
* definition in Documentation/powerpc/dts-bindings/fsl/cpm_qe
* /qe.txt
*/
}
No. More like
if (strcmp(image-ih_name, QE Firmware) == 0)
handle_fdt_fw_qe(image);
Where is the function prototype for handle_fdt_fw_qe()? Wouldn't it be in
qe.h?
Grg!
Please open your eyes and start reading!!!
Just 15 lines above I wrote: There would be no qe.h needed in that
generic code. Then what good couldit do if we add a prototype to that
header file that we need in common code? Nothing!
Obviously we need that prototype in a header file included by that
common code, and this has NOTHING to do with any *qe*.h files.
Also, I really think the strcmp is a bad idea, because then we have to put a
specific string in the ih_name field, not something unique to the actual
firmware in the image.
Well, I said that this might need discussion - I offered image
subtypes as an alternative, maybe there are other/better ideas. Input
welcome.
or similar. Probably #ifdef'ed for machines that have enabled QE
support in their board config, or with a weak handle_fdt_fw_qe() that
gets filled in for QE aware boards only so the compiler optimizes away
that call everywhere else.
So it would look like board_init_r()?
Not really. board_init_r() is still architecture specific - ARM and
PowerPC and MIPS and ... use different implementations.
Here this is feature dependent, not architecture or CPU or board
dependent code.
So you agree with Kumar's idea of having a weak function that embeds the
firmware into the device tree, but the firmware must always be wrapped in
an
image format?
Yes. Note that there is NOT any board-specific code.
Kumar's function would be defined in a board-specific source file. Using
I don;t think so. It would not be accepted for mainline then.
the QE firmware example for the 8323 above, I would add this code to
board/freescale/mpc832xemds/mpc832xemds.c:
Do you see my NAK? NAK!!!
In which way is this specific to the mpc832xemds board?
Would my custom 8323 board not need the same thing? Do you expect us
to duplicate this code to all boards which need this QE feature?
In which way would that be worse compared to
if (strcmp(image-ih_name, QE Firmware) == 0)
handle_fdt_fw_qe(image);
else if (strcmp(image-ih_name, AMD FPGA Firmware) == 0)
handle_fdt_fw_amd(image);
...
?
It wouldn't be. I don't like either method.
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Dear Timur Tabi, In message 4bfd6704.2040...@freescale.com you wrote: We have something like that already: #ifndef CONFIG_SYS_FDT_PAD #define CONFIG_SYS_FDT_PAD 0x3000 #endif And Wolfgang doesn't like it. Because nobody can explain where this magic number 0x3000 is coming from or why it is supposed to be sufficient. I was going to do this in my board header file: #define CONFIG_SYS_MAX_QE_FW_SIZE 0x4000 And I rejected this because it is pecific to just one use case (QE support) while I want a generic solution. Also, compile time size limits are always a bad thing if we can have run-time computed limits instead. Are you suggesting that we implement some user interface where the user, on the command line, can specify any number and type of firmware binaries to get embedded in the device tree? No. Such information should be part of the firmware image itself. 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 Documentation is the castor oil of programming. Managers know it must be good because the programmers hate it so much. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] add 1-wire DS2401 serial number chip
On Wed, May 26, 2010 at 1:31 PM, Asen Dimov di...@ronetix.at wrote:
The one-wire bus is generic, so I think it would make sense to split
the bus access logic and the handling of the DS2401 into parts so that
other people could make use of it.
We did an implementation a long time ago for the DS2502, and one of
the problems we ran into was the one wire bus timing was kind of tight
for early code (we were running it in misc_init_r() ), so we ended up
making up our own timer routines instead of the generic udelay stuff.
I include our file for reference below.
Signed-off-by: Asen Dimov di...@ronetix.at
---
drivers/misc/Makefile | 1 +
drivers/misc/ds2401.c | 265
+
include/ds2401.h | 36 +++
3 files changed, 302 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/ds2401.c
create mode 100644 include/ds2401.h
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 96aa331..4355b6e 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -32,6 +32,7 @@ COBJS-$(CONFIG_NS87308) += ns87308.o
COBJS-$(CONFIG_STATUS_LED) += status_led.o
COBJS-$(CONFIG_TWL4030_LED) += twl4030_led.o
COBJS-$(CONFIG_FSL_PMIC) += fsl_pmic.o
+COBJS-$(CONFIG_DS2401) += ds2401.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/misc/ds2401.c b/drivers/misc/ds2401.c
new file mode 100644
index 000..4298d8a
--- /dev/null
+++ b/drivers/misc/ds2401.c
@@ -0,0 +1,265 @@
+/*
+ * Copyright 2009, 2010
+ * Ilko Iliev il...@ronetix.at
+ * Ronetix Development Tools GmbH www.ronetix.at
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * Version 2 as published by the Free Software Foundation.
+ *
+ * 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
+ */
+
+/*
+ * Driver for 1-wire, DS2401, a Silicon Serial Number chip
+ *
+ * Driver usage:
+ *
+ * To build the driver add in a board config file:
+ * #define CONFIG_DS2401 1
+ *
+ * In the board specific file define the get and set functions
+ * to read and write one bit from/to PIO.
+ *
+ * If you want to set a specific first three bytes of the MAC address
+ * define CONFIG_MAC_OUI.
+ */
+
+#include common.h
+#include command.h
+#include ds2401.h
+
+#ifndef CONFIG_MAC_OUI
+#define CONFIG_MAC_OUI 02:00:00 /* Organizationally Unique Identifier*/
+#endif
+
+static DS2401_FUNCS *DS2401_Funcs = NULL;
+
+/*
+ * Generate a 1-wire reset, return 1 if no presence detect was found,
+ * return 0 otherwise.
+ */
+static int ds2401_reset(void)
+{
+ int result;
+
+ DS2401_Funcs-set(0);
+ udelay(480);
+ DS2401_Funcs-set(1);
+ udelay(70);
+
+ result = DS2401_Funcs-get();
+
+ udelay(410);
+ return result;
+}
+
+/*
+ * Send 1 a 1-wire write bit.
+ * Provide 10us recovery time.
+ */
+static void ds2401_write_bit(int bit)
+{
+ if (bit) {
+ /*
+ * write '1' bit
+ */
+ DS2401_Funcs-set(0);
+ udelay(6);
+ DS2401_Funcs-set(1);
+ udelay(64);
+ } else {
+ /*
+ * write '0' bit
+ */
+ DS2401_Funcs-set(0);
+ udelay(60);
+ DS2401_Funcs-set(1);
+ udelay(10);
+ }
+}
+
+/*
+ * Read a bit from the 1-wire bus and return it.
+ * Provide 10us recovery time.
+ */
+static int ds2401_read_bit(void)
+{
+ int result;
+
+ DS2401_Funcs-set(0);
+
+#ifdef __OPTIMIZE__
+ udelay(1);
+#endif
+
+ DS2401_Funcs-set(1);
+ udelay(9);
+
+ result = DS2401_Funcs-get();
+ udelay(55);
+
+ return result;
+}
+
+static void ds2401_write_byte(int data)
+{
+ int loop;
+
+ for (loop = 0; loop 8; loop++) {
+ ds2401_write_bit(data 0x01);
+ data = 1;
+ }
+}
+
+static int ds2401_read_byte(void)
+{
+ int loop, result = 0;
+
+ for (loop = 0; loop 8; loop++) {
+ result = 1;
+ if (ds2401_read_bit())
+ result |= 0x80;
+ }
+
+ return result;
+}
+
+static unsigned char ds2401_crc8_table[] = {
+ 0, 94, 188, 226, 97, 63, 221, 131, 194, 156, 126, 32, 163, 253, 31,
65,
+ 157, 195, 33, 127, 252, 162, 64, 30, 95, 1, 227, 189, 62, 96, 130,
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Scott Wood wrote:
Which is relevant, given that you're whipping out a big scary-looking
prototype as a reason to avoid refactoring. :-)
So instead of this:
configure_pci(PCIE1, PCIE1, Slot 1, pcie_ep, num, LAW_TRGT_IF_PCIE_1,
CONFIG_SYS_PCIE1_MEM_PHYS, LAW_SIZE_512M, CONFIG_SYS_PCIE1_IO_PHYS,
LAW_SIZE_64K, pci_info[num], pcie1_hose);
You want this instead:
struct {
enum srds_prtcl pci;
const char *name;
const char *target;
int endpoint;
int first_free_busno;
enum law_trgt_if law;
phys_addr_t mem_addr;
enum law_size mem_size;
phys_addr_t io_addr;
enum law_size io_size;
struct fsl_pci_info *pci_info;
struct pci_controller *hose;
} x;
x.pci = PCIE1;
x.name = PCIE1;
x.target = Slot 1;
x.endpoint =- pcie_ep;
x.first_free_busno = num;
x.law = LAW_TRGT_IF_PCIE_1;
x.mem_addr = CONFIG_SYS_PCIE1_MEM_PHYS;
x.mem_size = LAW_SIZE_512M;
x.io_addr = CONFIG_SYS_PCIE1_IO_PHYS;
x.io_size = LAW_SIZE_64K;
x.pci_info = pci_info[num];
x.hose = pcie1_hose;
configure_pci(x);
I don't see how this is an improvement.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
On 05/26/2010 02:34 PM, Timur Tabi wrote:
Scott Wood wrote:
Which is relevant, given that you're whipping out a big scary-looking
prototype as a reason to avoid refactoring. :-)
So instead of this:
configure_pci(PCIE1, PCIE1, Slot 1, pcie_ep, num, LAW_TRGT_IF_PCIE_1,
CONFIG_SYS_PCIE1_MEM_PHYS, LAW_SIZE_512M, CONFIG_SYS_PCIE1_IO_PHYS,
LAW_SIZE_64K,pci_info[num],pcie1_hose);
You want this instead:
struct {
enum srds_prtcl pci;
const char *name;
const char *target;
int endpoint;
int first_free_busno;
enum law_trgt_if law;
phys_addr_t mem_addr;
enum law_size mem_size;
phys_addr_t io_addr;
enum law_size io_size;
struct fsl_pci_info *pci_info;
struct pci_controller *hose;
} x;
x.pci = PCIE1;
x.name = PCIE1;
x.target = Slot 1;
x.endpoint =- pcie_ep;
x.first_free_busno = num;
x.law = LAW_TRGT_IF_PCIE_1;
x.mem_addr = CONFIG_SYS_PCIE1_MEM_PHYS;
x.mem_size = LAW_SIZE_512M;
x.io_addr = CONFIG_SYS_PCIE1_IO_PHYS;
x.io_size = LAW_SIZE_64K;
x.pci_info =pci_info[num];
x.hose =pcie1_hose;
configure_pci(x);
I don't see how this is an improvement.
Much of that struct could be defined statically, with the board or soc
file providing an array of PCI info structs. Look at how the 83xx PCI
code does it -- you'll need more than just the generic u-boot pci_region
struct, though you could have it as a member of the hw-specific struct.
A few of those things don't belong there -- I think first_free_busno
should be a static variable inside the pci setup function, for example
(does Linux still even need separate bus number spaces on different
hoses?). pcie_ep should just be a local variable. The hose could maybe
just be an uninitialized member of the struct instead of a pointer to an
arbitrary other symbol.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Timur Tabi,
In message 4bfc1736.5030...@freescale.com you wrote:
+ { 0, 333,1,5, 31,3, 0},
+ {334, 400,1,5, 31,3, 0},
+ {401, 549,1,5, 31,3, 0},
+ {550, 680,1,5, 31,5, 0},
+ {681, 850,1,5, 31,5, 0},
+ { 0, 333,2,5, 31,3, 0},
+ {334, 400,2,5, 31,3, 0},
+ {401, 549,2,5, 31,3, 0},
+ {550, 680,2,5, 31,5, 0},
+ {681, 850,2,5, 31,5, 0},
Please use TABs for vertical alignment.
Ok, I understand now what you mean. However, the columns are
right-justified. You can't use tabs to align right-justified columns.
There is exactly two entries in that table where it would make any
difference, and if that's really that important to you, adding two
spaces after the TAB would work wonders.
How about using get_ram_size() for autosizing / testing?
It appears get_ram_size() has never been used on PowerPC before. This
It appears you really haven't bothered checking. We have been using
it on PowerPC since day 1 - for well over 10 years by now. On many,
many systems. Get a clue!
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
Making files is easy under the UNIX operating system. Therefore,
users tend to create numerous files using large amounts of file
space. It has been said that the only standard thing about all UNIX
systems is the message-of-the-day telling users to clean up their
files.-- System V.2 administrator's guide
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] libfdt: introduce function fdt_get_max_phandle
Dear Timur Tabi,
In message 1274308618-2974-1-git-send-email-ti...@freescale.com you wrote:
Introduce function fdt_get_max_phandle(), which returns the largest value
of all phandles in a device tree. This is useful for allocating a new phandle
property, since all phandles must be unique.
Signed-off-by: Timur Tabi ti...@freescale.com
---
include/libfdt.h| 20
lib/libfdt/fdt_ro.c | 17 +
2 files changed, 37 insertions(+), 0 deletions(-)
Please submit as part of a patch / patch series that acrtually uses
this feature. As is, it's just dead code that has no users.
+int fdt_get_max_phandle(const void *fdt)
+{
+ int offset;
+ uint32_t temp, phandle = 0;
+
+ FDT_CHECK_HEADER(fdt);
+
+ for (offset = fdt_next_node(fdt, -1, NULL); offset = 0;
+ offset = fdt_next_node(fdt, offset, NULL)) {
+ temp = fdt_get_phandle(fdt, offset);
+ if (temp phandle)
+ phandle = temp;
+ }
+
+ return phandle;
+}
As fdt_get_phandle() returns a uint32_t, fdt_get_max_phandle() should
return the same type, not int.
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
Star Trek Lives!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Wolfgang Denk wrote:
There is exactly two entries in that table where it would make any
difference, and if that's really that important to you, adding two
spaces after the TAB would work wonders.
The column headers would be unaligned:
static const board_specific_parameters_t bsp[] = {
/*
* memory controller 0
*lo| hi| num| clk| cpo|wrdata|2T
* mhz| mhz|ranks|adjst|| delay|
*/
{ 0, 333,1,5, 31,3, 0},
{334, 400,1,5, 31,3, 0},
{401, 549,1,5, 31,3, 0},
{550, 680,1,5, 31,5, 0},
{681, 850,1,5, 31,5, 0},
{ 0, 333,2,5, 31,3, 0},
{334, 400,2,5, 31,3, 0},
{401, 549,2,5, 31,3, 0},
{550, 680,2,5, 31,5, 0},
{681, 850,2,5, 31,5, 0},
};
How about using get_ram_size() for autosizing / testing?
It appears get_ram_size() has never been used on PowerPC before. This
It appears you really haven't bothered checking. We have been using
it on PowerPC since day 1 - for well over 10 years by now. On many,
many systems. Get a clue!
Sorry, I must have used grep wrong or something. I see what you're talking
about now.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:io.h: define __io() macro if not defined erlier
Dear Mike Frysinger, In message 201005261350.16464.vap...@gentoo.org you wrote: i changed the accessors to use in/out macros as i thought that was the correct set of accessor functions to use. looking at a set of definitions and picking a set because they look like they'll just work isnt how i set about it. after having read the deviceiobook in the Linux kernel, i think the correct funcs to use here are the read/write helpers. now that i have that information, looking at the definitions shows that this should work for ARM just fine. so, to be clear, i think we should do: -#define DM9000_outb(d,r) outb(d, r) +#define DM9000_outb(d,r) writeb(d, r) etc... This seems to work for me. Will send a patch to do this ASAP. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I am a computer. I am dumber than any human and smarter than any ad- ministrator. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm9000x.c: fix compile problems
Use readX() / writeX() accessors instead of inX() / outX(). Suggested-by: Mike Frysinger vap...@gentoo.org Signed-off-by: Wolfgang Denk w...@denx.de --- drivers/net/dm9000x.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c index f121286..137e41f 100644 --- a/drivers/net/dm9000x.c +++ b/drivers/net/dm9000x.c @@ -117,12 +117,12 @@ static void DM9000_iow(int reg, u8 value); /* DM9000 network board routine */ -#define DM9000_outb(d,r) outb(d, r) -#define DM9000_outw(d,r) outw(d, r) -#define DM9000_outl(d,r) outl(d, r) -#define DM9000_inb(r) inb(r) -#define DM9000_inw(r) inw(r) -#define DM9000_inl(r) inl(r) +#define DM9000_outb(d,r) writeb(d, r) +#define DM9000_outw(d,r) writew(d, r) +#define DM9000_outl(d,r) writel(d, r) +#define DM9000_inb(r) readb(r) +#define DM9000_inw(r) readw(r) +#define DM9000_inl(r) readl(r) #ifdef CONFIG_DM9000_DEBUG static void -- 1.6.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Wolfgang Denk wrote: It appears you really haven't bothered checking. We have been using it on PowerPC since day 1 - for well over 10 years by now. On many, many systems. Get a clue! I've looked at get_ram_size(), and I don't think I can use it. We use phys_addr_t to represent DDR sizes, which is a 64-bit integer on the P1022DS. get_ram_size() takes a 'long' and returns a 'long', so it's not capable of handling the amount of memory that we support on the board. I can use get_ram_size() to test the lower 2GB of DDR, but I can't use it to verify the amount of RAM in the system. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/bootcount: Fix endianness problem
Dear Detlev Zundel, In message 1274364575-9764-2-git-send-email-...@denx.de you wrote: From: Michael Weiss michael.we...@ifm.com For CONFIG_SYS_BOOTCOUNT_SINGLEWORD the code had an endianness problem. Signed-off-by: Michael Weiss michael.we...@ifm.com Signed-off-by: Detlev Zundel d...@denx.de --- arch/powerpc/lib/bootcount.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) Applied, thanks. [Patch 1/2 is not a fix but new code, it is on hold for the next branch.] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is necessary to have purpose. -- Alice #1, I, Mudd, stardate 4513.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Convert Makefiles from COBJS-${} to COBJS-$()
Dear Kumar Gala, In message 1274433468-31825-1-git-send-email-ga...@kernel.crashing.org you wrote: Match style we use almost everywhere else Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/cpu/mpc512x/Makefile| 10 +- board/freescale/common/Makefile | 22 +++--- board/freescale/mpc8610hpcd/Makefile |2 +- 3 files changed, 17 insertions(+), 17 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Hindsight is an exact science. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] config.mk: use different host compiler for OS X 10.6
Dear Andreas Bießmann, In message 1274527041-62757-1-git-send-email-andreas.de...@googlemail.com you wrote: Compiling tools subdirectory on Mac OS X 10.6 (Snow Leopard) complains about wrong syntax in system includes. In file included from /usr/include/stdio.h:444, from ../source/u-boot/include/compiler.h:26, from ../source/u-boot/lib/crc32.c:15: /usr/include/secure/_stdio.h:46: error: syntax error in macro parameter list This can be fixed by reverting the workaround for prior OS X releases in config.mk conditionally for OS X 10.6+. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- config.mk | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) Applied,t hanks. 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 Time is an illusion perpetrated by the manufacturers of space. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Please pull u-boot-mpc83xx.git
Dear Kim Phillips, In message 20100521153045.5b6f38a8.kim.phill...@freescale.com you wrote: Wolfgang, please pull one cpu init fix, and a typo fix*: The following changes since commit 2f05e394fccf62a4693c6b8323de725f90d1f003: fsl_diu_fb.c: fix build warnings (2010-05-17 23:34:18 +0200) are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master Horst Kronstorfer (1): Fixed two typos in arch/powerpc/cpu/mpc83xx/start.S. Kim Phillips (1): mpc83xx: don't shift pre-shifted ACR, SPCR, SCCR bitfield masks in cpu_init.c arch/powerpc/cpu/mpc83xx/cpu_init.c | 36 +- arch/powerpc/cpu/mpc83xx/start.S|4 +- 2 files changed, 20 insertions(+), 20 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The joys of love made her human and the agonies of love destroyed her. -- Spock, Requiem for Methuselah, stardate 5842.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/17] GRETH: Added support for selecting PHY address from config, PHY address was always set to zero before.
Dear Daniel Hellstrom, In message 1274194143-8994-1-git-send-email-dan...@gaisler.com you wrote: Signed-off-by: Daniel Hellstrom dan...@gaisler.com --- drivers/net/greth.c | 69 +++--- 1 files changed, 43 insertions(+), 26 deletions(-) Sorry for the late review... +#ifdef CONFIG_SYS_GRLIB_GRETH_PHYADDR + int phyaddr = CONFIG_SYS_GRLIB_GRETH_PHYADDR; +#else + int phyaddr = 0; +#endif Please make this: #ifndef CONFIG_SYS_GRLIB_GRETH_PHYADDR #define CONFIG_SYS_GRLIB_GRETH_PHYADDR 0 #endif int phyaddr = CONFIG_SYS_GRLIB_GRETH_PHYADDR; +#ifdef DEBUG + printf(greth_init_phy: PHY read 1 failed\n); +#endif ... +#ifdef DEBUG + printf(greth_init_phy: PHY read 2 failed\n); +#endif Please change all these into debug() calls and drop the #ifdef's. Also, this patch needs to go through Ben's networking repository. 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 Do you suppose the reason the ends of the `Intel Inside' logo don't match up is that it was drawn on a Pentium? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/17] GRETH: Added extra RESET, this is needed if GRETH was stopped during an ethernet frame reception.
Dear Daniel Hellstrom,
In message 1274194143-8994-2-git-send-email-dan...@gaisler.com you wrote:
Signed-off-by: Daniel Hellstrom dan...@gaisler.com
---
drivers/net/greth.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index a1a88f9..143c773 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -146,13 +146,23 @@ int greth_init(struct eth_device *dev, bd_t * bis)
printf(greth_init\n);
#endif
+ /* Reset core */
+ GRETH_REGSAVE(regs-control, (GRETH_RESET | (greth-gb 8) |
+ (greth-sp 7) | (greth-fd 4)));
+
+ /* Wait for Reset to complete */
+ while ( GRETH_REGLOAD(regs-control) GRETH_RESET) ;
+
+ GRETH_REGSAVE(regs-control,
+ ((greth-gb 8) | (greth-sp 7) | (greth-fd 4)));
+
if (!greth-rxbd_base) {
/* allocate descriptors */
greth-rxbd_base = (greth_bd *)
memalign(0x1000, GRETH_RXBD_CNT * sizeof(greth_bd));
greth-txbd_base = (greth_bd *)
- memalign(0x1000, GRETH_RXBD_CNT * sizeof(greth_bd));
+ memalign(0x1000, GRETH_TXBD_CNT * sizeof(greth_bd));
This...
/* allocate buffers to all descriptors */
greth-rxbuf_base =
@@ -185,7 +195,7 @@ int greth_init(struct eth_device *dev, bd_t * bis)
for (i = 0; i GRETH_TXBD_CNT; i++) {
greth-txbd_base[i].addr = 0;
/* enable desciptor set wrap bit if last descriptor */
- if (i = (GRETH_RXBD_CNT - 1)) {
+ if (i = (GRETH_TXBD_CNT - 1)) {
... and these seem to be unrelated bug fixes. These should go into a
separate commit.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A failure will not appear until a unit has passed final inspection.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx/p2020ds: Use is_serdes_configured() to determine of PCIe enabled
On Fri, May 21, 2010 at 4:17 AM, Kumar Gala ga...@kernel.crashing.org wrote: #ifdef CONFIG_PCIE3 ft_fsl_pci_setup(blob, pci0, pcie3_hose); +#else + ft_fsl_pci_setup(blob, pci0, NULL); #endif What is the reason why CONFIG_PCIE3 setups up the pci node called pci0? Is it because CONFIG_SYS_PCIE3_ADDR is the address of the pci0 node in the p2020ds device tree? If so, why can't we do this is P2020DS.h: #define CONFIG_SYS_PCIE1_ADDR (CONFIG_SYS_CCSRBAR+0x8000) /* pci0 */ #define CONFIG_SYS_PCIE2_ADDR (CONFIG_SYS_CCSRBAR+0x9000) /* pci1 */ #define CONFIG_SYS_PCIE3_ADDR (CONFIG_SYS_CCSRBAR+0xa000) /* pci2 */ -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/17] LEON3: reimplemented AMBA PlugPlay scanning routines.
Dear Daniel Hellstrom,
In message 1274194143-8994-3-git-send-email-dan...@gaisler.com you wrote:
Signed-off-by: Daniel Hellstrom dan...@gaisler.com
...
- * (C) Copyright 2007
- * Daniel Hellstrom, Gaisler Research, dan...@gaisler.com
+ * (C) Copyright 2010
+ * Daniel Hellstrom, Aeroflex Gaisler, dan...@gaisler.com.
Thsi cannot be. Make this Copyright 2007, 2010 or Copyright
2007-2010.
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
+ *
Please drop this empty line.
+/* #define DEBUG */
+
Please do not add dead code.
...
+ int i;
+
+ ambapp_find_buses(ioarea, abus);
+ for(i=0; i6; i++)
+ if ( abus-ioareas[i] == 0 )
+ break;
Multiline if's require braces. Please also fix white space:
for (i=0; i6; i++) {
if (abus-ioareas[i] == 0)
break;
}
+ if ( type == AMBA_TYPE_AHBIO ) {
Please fix white spaces as above. Please fix this globally.
+ if ( found == 1 ) {
+ ambapp_apb_parse(apbdev, dev);
+ }
No braces for one liners. And fix the white space.
...
+ found = ambapp_find_ahb(abus, devid, 63, type, ahbdev);
+ if ( found == 1 ) {
+ return 64;
+ } else {
+ return 63 - ahbdev.dec_index;
}
Seems I have seen semi-identical code above. Factor out as function?
+/* The define CONFIG_SYS_GRLIB_SINGLE_BUS may be defined on GRLIB systems
+ * where only one AHB Bus is available - no bridges are present. This option
+ * is available only to reduce the footprint.
+ *
+ * Defining this on a multi-bus GRLIB system may also work depending on the
+ * design.
+ */
Incorrect multiline comment style.
+/* Get Parent bus frequency. Note that since we go from a child bus
+ * to a parent bus, the frequency factor direction is inverted.
+ */
Incorrect multiline comment style. Please fix globally.
+ if ( dir ) {
+ freq = freq * ffact;
+ } else {
+ freq = freq / ffact;
+ }
No braces for oneliners. Please fix globally.
+unsigned int gaisler_ahb2ahb_v2_freq(ambapp_ahbdev *ahb, unsigned int freq)
{
- /* find first device of this */
- return ambapp_ahb_scan(vendor, driver, dev, index, 1, AHB_SCAN_SLAVE);
+ printf(gaisler_ahb2ahb_v2_freq: AHB2AHB ver 2 not supported\n);
+ while(1) ;
Consider calling hang() instead ? [globally]
...
+ /* Get parent bus */
+ parent = (ioarea 0x7);
+ if ( parent == 0 ) {
+ printf(ambapp_bus_freq: parent=0 indicates no parent!
Stopping.\n);
Line too long. Please fix globally.
...
+init_ahb_bridges:
+ mov %g0, %i0
+ mov %g0, %i1
+ mov %g0, %i2
+ mov %g0, %i3
+ mov %g0, %i4
+ retl
+ mov%g0, %i5
Incorrect indentation. Please fix globally.
...
void cpu_init_f(void)
{
- /* these varaiable must not be initialized */
- ambapp_dev_irqmp *irqmp;
- ambapp_apbdev apbdev;
- register unsigned int apbmst;
-
- /* find AMBA APB Master */
- apbmst = (unsigned int)
- ambapp_ahb_next_nomem(VENDOR_GAISLER, GAISLER_APBMST, 1, 0);
- if (!apbmst) {
- /*
- * no AHB/APB bridge, something is wrong
- * == jump to start (or hang)
- */
- while (1) ;
- }
- /* Init memory controller */
- if (init_memory_ctrl()) {
- while (1) ;
- }
-
- /
- * From here we can use the main memory and the stack.
- */
- /* Find AMBA APB IRQMP Controller */
- if (ambapp_apb_first(VENDOR_GAISLER, GAISLER_IRQMP, apbdev) != 1) {
- /* no IRQ controller, something is wrong
- * == jump to start (or hang)
- */
- while (1) ;
- }
- irqmp = (ambapp_dev_irqmp *) apbdev.address;
-
- /* initialize the IRQMP */
- irqmp-ilevel = 0xf;/* all IRQ off */
- irqmp-iforce = 0;
- irqmp-ipend = 0;
- irqmp-iclear = 0xfffe; /* clear all old pending interrupts */
- irqmp-cpu_mask[0] = 0; /* mask all IRQs on CPU 0 */
- irqmp-cpu_force[0] = 0;/* no force IRQ on CPU 0 */
-
- /* cache */
}
Seems this becomes an empty function? Drop it, then!
+/* Routine called from start.S,
+ *
+ * Run from FLASH/PROM:
+ * - memory controller has already been setup up, stack can be used
+ * - global variables available for read/writing
+ * - constants avaiable
+ */
void cpu_init_f2(void)
{
-
+ /* Initialize the AMBA Plug Play bus structure, the bus
+ * structure represents the AMBA bus that the CPU is located at.
+ */
+ ambapp_bus_init(CONFIG_AMBAPP_IOAREA, CONFIG_SYS_CLK_FREQ, ambapp_plb);
}
Or rename this into cpu_init_f() ?
+/** Vendor
Re: [U-Boot] [PATCH 05/17] LEON3: added memory controller initialization using the new AMBA PnP routines.
Dear Daniel Hellstrom, In message 1274194143-8994-4-git-send-email-dan...@gaisler.com you wrote: Signed-off-by: Daniel Hellstrom dan...@gaisler.com --- arch/sparc/cpu/leon3/Makefile |5 +- arch/sparc/cpu/leon3/memcfg.c | 276 + arch/sparc/cpu/leon3/memcfg.h | 106 ++ arch/sparc/cpu/leon3/memcfg_low.S | 270 arch/sparc/cpu/leon3/start.S | 36 + include/configs/gr_cpci_ax2000.h | 27 ++-- include/configs/gr_ep2s60.h | 32 +++-- include/configs/gr_xc3s_1500.h| 23 ++-- include/configs/grsim.h | 27 ++-- 9 files changed, 754 insertions(+), 48 deletions(-) create mode 100644 arch/sparc/cpu/leon3/memcfg.c create mode 100644 arch/sparc/cpu/leon3/memcfg.h create mode 100644 arch/sparc/cpu/leon3/memcfg_low.S diff --git a/arch/sparc/cpu/leon3/Makefile b/arch/sparc/cpu/leon3/Makefile index d8f89bc..f1bb808 100644 --- a/arch/sparc/cpu/leon3/Makefile +++ b/arch/sparc/cpu/leon3/Makefile @@ -26,8 +26,9 @@ include $(TOPDIR)/config.mk LIB = $(obj)lib$(CPU).a START= start.o -SOBJS= ambapp_low.o ambapp_low_c.o -COBJS= cpu_init.o serial.o cpu.o ambapp.o interrupts.o prom.o usb_uhci.o +SOBJS= ambapp_low.o ambapp_low_c.o memcfg_low.o +COBJS= cpu_init.o serial.o cpu.o ambapp.o interrupts.o prom.o usb_uhci.o \ + memcfg.o Please sort lists. SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) diff --git a/arch/sparc/cpu/leon3/memcfg.c b/arch/sparc/cpu/leon3/memcfg.c new file mode 100644 index 000..4a9bded --- /dev/null +++ b/arch/sparc/cpu/leon3/memcfg.c @@ -0,0 +1,276 @@ +/* GRLIB Memory controller setup. The register values are used + * from the associated low level assembler routine implemented + * in memcfg_low.S. Please apply all review comments to the previous patch here, too (white space, multiline comment style, brace style, etc.) Ditto for your other patches. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Vor allem kein Gedanke! Nichts ist kompromittierender als ein Gedan- ke!- Friedrich Wilhelm Nietzsche _Der Fall Wagner_ (1888) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/17] LEON3: Moved GRLIB core header files to common include/grlib directory
Dear Daniel Hellstrom, In message 1274194143-8994-5-git-send-email-dan...@gaisler.com you wrote: Signed-off-by: Daniel Hellstrom dan...@gaisler.com --- arch/sparc/cpu/leon3/cpu_init.c | 10 +-- arch/sparc/cpu/leon3/interrupts.c |7 +- arch/sparc/cpu/leon3/memcfg.h |1 - arch/sparc/cpu/leon3/prom.c |7 ++- arch/sparc/cpu/leon3/serial.c | 16 ++-- drivers/net/greth.c |2 +- include/ambapp.h | 137 - include/grlib/apbuart.h | 63 + include/grlib/gptimer.h | 50 + include/grlib/greth.h | 103 include/grlib/irqmp.h | 39 +++ 11 files changed, 277 insertions(+), 158 deletions(-) create mode 100644 include/grlib/apbuart.h create mode 100644 include/grlib/gptimer.h create mode 100644 include/grlib/greth.h create mode 100644 include/grlib/irqmp.h ... --- /dev/null +++ b/include/grlib/apbuart.h @@ -0,0 +1,63 @@ +/* GRLIB APBUART definitions + * + * (C) Copyright 2010 + * Daniel Hellstrom, Aeroflex Gaisler, dan...@gaisler.com ... Incorrect multiline comment style. OK, I give up review on this patch series now. Please apply all previously made review comments globally, to all patches in this series. Then resubmit. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Drawing on my fine command of language, I said nothing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-sparc.git
Dear Daniel Hellstrom, In message 4bfd1176.6080...@gaisler.com you wrote: Please pull the 17 patches in the master branch of u-boot-sparc repository. I have rebased the patches and updated the first patch according to Mike Drysingers comments. Sorry, but I won't. I have found a number of issues that need to be fixed first. Sorry for the late review. 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 Overdrawn? But I still have checks left! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-sparc.git
On Wed, 26 May 2010 23:02:43 0200, Wolfgang Denk wrote: Dear Daniel Hellstrom, In message 4bfd1176.6080...@gaisler.com you wrote: Please pull the 17 patches in the master branch of u-boot-sparc repository. I have rebased the patches and updated the first patch according to Mike Drysingers comments. Sorry, but I won't. I have found a number of issues that need to be fixed first. Sorry for the late review. No problem, thank you for your comments, I will go through them. Best regards, Daniel Hellstrom 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 Overdrawn? But I still have checks left! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-sparc.git
Just a codeing-style question, I have seen other writers of assembly code add an extra space before instruction executed in a delay-slot (typically after a branch for SPARC) just to make it clear that instruction is executed as well. I find that quite good and have adopted that habit too, is that allowed? Daniel On Wed, 26 May 2010 17:20:35 -0400, dan...@gaisler.com wrote: On Wed, 26 May 2010 23:02:43 0200, Wolfgang Denk wrote: Dear Daniel Hellstrom, In message 4bfd1176.6080...@gaisler.com you wrote: Please pull the 17 patches in the master branch of u-boot-sparc repository. I have rebased the patches and updated the first patch according to Mike Drysingers comments. Sorry, but I won't. I have found a number of issues that need to be fixed first. Sorry for the late review. No problem, thank you for your comments, I will go through them. Best regards, Daniel Hellstrom 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 Overdrawn? But I still have checks left! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm9000x.c: fix compile problems
Dear Wolfgang, Am 26.05.2010 um 22:21 schrieb Wolfgang Denk: Use readX() / writeX() accessors instead of inX() / outX(). this works for me. Suggested-by: Mike Frysinger vap...@gentoo.org Signed-off-by: Wolfgang Denk w...@denx.de Tested-by: Andreas Bießmann biessm...@corscience.de regards Andreas Bießmann___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx/p2020ds: Use is_serdes_configured() to determine of PCIe enabled
On Fri, May 21, 2010 at 4:17 AM, Kumar Gala ga...@kernel.crashing.org wrote:
#ifdef CONFIG_PCIE2
- pcie_configured = is_fsl_pci_cfg(LAW_TRGT_IF_PCIE_2, io_sel);
+ pcie_configured = is_serdes_configured(PCIE2);
if (pcie_configured !(devdisr MPC85xx_DEVDISR_PCIE2)) {
+ set_next_law(CONFIG_SYS_PCIE2_MEM_PHYS, LAW_SIZE_512M,
+ LAW_TRGT_IF_PCIE_2);
+ set_next_law(CONFIG_SYS_PCIE2_IO_PHYS, LAW_SIZE_64K,
+ LAW_TRGT_IF_PCIE_2);
SET_STD_PCIE_INFO(pci_info[num], 2);
Are you sure that pci_info needs to be an array? It looks as if
pci_info[num] is only used inside the #ifdef block. That is, I think
we can do this:
struct fsl_pci_info pci_info;
...
#ifdef CONFIG_PCIE3
pcie_configured = is_serdes_configured(PCIE3);
if (pcie_configured !(devdisr MPC85xx_DEVDISR_PCIE3)) {
set_next_law(CONFIG_SYS_PCIE3_MEM_PHYS, LAW_SIZE_512M,
LAW_TRGT_IF_PCIE_3);
set_next_law(CONFIG_SYS_PCIE3_IO_PHYS, LAW_SIZE_64K,
LAW_TRGT_IF_PCIE_3);
SET_STD_PCIE_INFO(pci_info, 3);
pcie_ep = fsl_setup_hose(pcie3_hose, pci_info.regs);
printf(PCIE3 connected to Slot 1 as %s (base addr %lx)\n,
pcie_ep ? Endpoint : Root Complex,
pci_info.regs);
first_free_busno = fsl_pci_init_port(pci_info,
pcie3_hose, first_free_busno);
} else {
printf(PCIE3: disabled\n);
}
puts(\n);
#else
Each #ifdef CONFIG_PCIEx block is self-contained, with respect to
pci_info. It appears that there's no need to remember pci_info[0] and
use pci_info[1] for the next PCIE device.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm9000x.c: fix compile problems
Hi Wolfgang, On 5/26/2010 1:21 PM, Wolfgang Denk wrote: Use readX() / writeX() accessors instead of inX() / outX(). Suggested-by: Mike Frysingervap...@gentoo.org Signed-off-by: Wolfgang Denkw...@denx.de --- drivers/net/dm9000x.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c index f121286..137e41f 100644 --- a/drivers/net/dm9000x.c +++ b/drivers/net/dm9000x.c @@ -117,12 +117,12 @@ static void DM9000_iow(int reg, u8 value); /* DM9000 network board routine */ -#define DM9000_outb(d,r) outb(d, r) -#define DM9000_outw(d,r) outw(d, r) -#define DM9000_outl(d,r) outl(d, r) -#define DM9000_inb(r) inb(r) -#define DM9000_inw(r) inw(r) -#define DM9000_inl(r) inl(r) +#define DM9000_outb(d,r) writeb(d, r) +#define DM9000_outw(d,r) writew(d, r) +#define DM9000_outl(d,r) writel(d, r) +#define DM9000_inb(r) readb(r) +#define DM9000_inw(r) readw(r) +#define DM9000_inl(r) readl(r) #ifdef CONFIG_DM9000_DEBUG static void Looks good to me. Please apply directly. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Scott Wood wrote:
A few of those things don't belong there -- I think first_free_busno
should be a static variable inside the pci setup function, for example
(does Linux still even need separate bus number spaces on different
hoses?). pcie_ep should just be a local variable. The hose could maybe
just be an uninitialized member of the struct instead of a pointer to an
arbitrary other symbol.
I'm not sure what you mean about the 'hose'. How about this:
static void configure_pcie(enum srds_prtcl pci,
u32 devdisr_mask,
const char *target,
enum law_trgt_if law,
phys_addr_t mem_addr,
enum law_size mem_size,
phys_addr_t io_addr,
enum law_size io_size,
struct pci_controller *hose)
{
volatile ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
struct fsl_pci_info pci_info;
u32 devdisr;
static int first_free_busno = 0;
int is_endpoint;
int num;
devdisr = in_be32(gur-devdisr);
if (is_serdes_configured(pci) !(devdisr devdisr_mask)) {
set_next_law(mem_addr, mem_size, law);
set_next_law(io_addr, io_size, law);
switch (pci) {
#ifdef CONFIG_PCIE1
case PCIE1:
num = 1;
SET_STD_PCIE_INFO(pci_info, 1);
break;
#endif
#ifdef CONFIG_PCIE2
case PCIE2:
num = 2;
SET_STD_PCIE_INFO(pci_info, 2);
break;
#endif
#ifdef CONFIG_PCIE3
case PCIE3:
num = 3;
SET_STD_PCIE_INFO(pci_info, 3);
break;
#endif
#ifdef CONFIG_PCIE4
case PCIE4:
num = 4;
SET_STD_PCIE_INFO(pci_info, 4);
break;
#endif
default:
break;
}
is_endpoint = fsl_setup_hose(hose, pci_info.regs);
printf(PCIE%u: connected to %s as %s (base addr %lx)\n,
num, target, is_endpoint ? Endpoint : Root Complex,
pci_info.regs);
first_free_busno = fsl_pci_init_port(pci_info, hose,
first_free_busno);
} else {
printf(PCIE%u: disabled\n, num);
}
}
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm9000x.c: fix compile problems
Dear Ben Warren, In message 4bfd9623.3070...@gmail.com you wrote: Looks good to me. Please apply directly. Done, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There is enough for the need of everyone in this world, but not for the greed of everyone. - Mahatma Gandhi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-sparc.git
Dear dan...@gaisler.com, In message 20100526172855.2w3qpyvp3akgc...@webmail.bluegenesis.com you wrote: Just a codeing-style question, I have seen other writers of assembly code add an extra space before instruction executed in a delay-slot (typically after a branch for SPARC) just to make it clear that instruction is executed as well. I find that quite good and have adopted that habit too, is that allowed? Ah, that was the meaning. I thought so initially, but then saw a lot of empty lines separating such blocks, so I assumed it was just incorrect indentation. When this is used consistently through all of the code (at least in the changed files), than it's OK with me. Ideally it should be documented. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de After a heated argument on some trivial matter Nancy [Astor] . . . shouted, ``If I were your wife I would put poison in your coffee!'' Whereupon Winston Churchill with equal heat and sincerity answered, ``And if I were your husband I would drink it.'' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] TI: DaVinci: Add board specific code for da850 EVM
On Fri, May 21, 2010 at 1:39 AM, Sudhakar Rajashekhara
sudhakar@ti.com wrote:
Provides initial support for TI OMAP-L138/DA850 SoC devices on
a Logic PD EVM board.
Provides:
Initial boot and configuration.
Support for i2c.
UART support (console).
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
This is great! With the NAND defines of the da850 config from the
omap-l1 git repo this patch set also provides NAND reading and writing
on the da850evm. I'm looking forward to future da850 support patches!
I got one whitespace error applying this patch on-top of 'da830: Move
common code out of da830evm.c file' and 'TI: DaVinci: Prepare for
da850 support' starting with 40792d675a609c83621d098e48a89de07463b3cd
of git://git.denx.de/u-boot.git .
--
Applying: TI: DaVinci: Add board specific code for da850 EVM
removed.git/rebase-apply/patch:83: new blank line at EOF.
+
warning: 1 line adds whitespace errors.
--
+
+static const struct lpsc_resource lpsc[] = {
+ DAVINCI_LPSC_AEMIF, /* NAND, NOR */
+ DAVINCI_LPSC_SPI1, /* Serial Flash */
+ DAVINCI_LPSC_EMAC, /* image download */
+ DAVINCI_LPSC_UART2, /* console */
+ DAVINCI_LPSC_GPIO,
+};
I get the following warning when compiling :
--
da850evm.c:65: warning: missing braces around initializer
da850evm.c:65: warning: (near initialization for 'lpsc[0]')
--
which can be fixed by the following:
diff --git a/board/davinci/da8xxevm/da850evm.c
b/board/davinci/da8xxevm/da850evm.c
index 197df22..ba70352 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -62,11 +62,11 @@ static const struct pinmux_resource pinmuxes[] = {
};
static const struct lpsc_resource lpsc[] = {
- DAVINCI_LPSC_AEMIF, /* NAND, NOR */
- DAVINCI_LPSC_SPI1, /* Serial Flash */
- DAVINCI_LPSC_EMAC, /* image download */
- DAVINCI_LPSC_UART2, /* console */
- DAVINCI_LPSC_GPIO,
+ { DAVINCI_LPSC_AEMIF }, /* NAND, NOR */
+ { DAVINCI_LPSC_SPI1 }, /* Serial Flash */
+ { DAVINCI_LPSC_EMAC }, /* image download */
+ { DAVINCI_LPSC_UART2 }, /* console */
+ { DAVINCI_LPSC_GPIO },
};
int board_init(void)
+
+int board_init(void)
+{
+#ifndef CONFIG_USE_IRQ
+ irq_init();
+#endif
If CONFIG_USE_IRQ is defined (as it is in the da850evm config in the
omap-l1 git repo) I get the following warning:
--
da850evm.c: In function 'board_init':
da850evm.c:75: warning: implicit declaration of function 'irq_init'
--
which can be fixed by the following:
diff --git a/board/davinci/common/misc.h b/board/davinci/common/misc.h
index 84fafe9..ee35f01 100644
--- a/board/davinci/common/misc.h
+++ b/board/davinci/common/misc.h
@@ -49,6 +49,7 @@ struct lpsc_resource {
const int lpsc_no;
};
+void irq_init(void);
int dvevm_read_mac_address(uint8_t *buf);
void dv_configure_mac_address(uint8_t *rom_enetaddr);
int davinci_configure_pin_mux(const struct pinmux_config *pins, int n_pins);
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
new file mode 100644
index 000..8fa7f01
--- /dev/null
+++ b/include/configs/da850evm.h
@@ -0,0 +1,140 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ *
+ * Based on davinci_dvevm.h. Original Copyrights follow:
+ *
+ * Copyright (C) 2007 Sergey Kubushyn k...@koi8.net
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*
+ * Board
+ */
+
+/*
+ * SoC Configuration
+ */
+#define CONFIG_MACH_DAVINCI_DA850_EVM
from here
+#define CONFIG_ARM926EJS /* arm926ejs CPU core */
+#define CONFIG_SOC_DA8XX /* TI DA8xx SoC */
+#define CONFIG_SYS_CLK_FREQ clk_get(DAVINCI_ARM_CLKID)
+#define CONFIG_SYS_OSCIN_FREQ 2400
+#define CONFIG_SYS_TIMERBASE DAVINCI_TIMER0_BASE
+#define CONFIG_SYS_HZ_CLOCK clk_get(DAVINCI_AUXCLK_CLKID)
+#define CONFIG_SYS_HZ 1000
+#define CONFIG_SKIP_LOWLEVEL_INIT
+#define CONFIG_SKIP_RELOCATE_UBOOT /* to a proper address, init done */
+
+/*
+ * Memory Info
+ */
+#define CONFIG_SYS_MALLOC_LEN (0x1 + 1*1024*1024) /* malloc() len */
+#define CONFIG_SYS_GBL_DATA_SIZE 128 /* reserved for
Re: [U-Boot] [PATCH] NAND: Support dynamic location of enviromnent (CONFIG_ENV_OFFSET_OOB)
On Mon, May 17, 2010 at 05:04:30PM -0400, Ben Gardiner wrote:
diff --git a/common/cmd_dynenv.c b/common/cmd_dynenv.c
new file mode 100644
index 000..5167875
--- /dev/null
+++ b/common/cmd_dynenv.c
@@ -0,0 +1,112 @@
+/*
+ * (C) Copyright 2006-2007 OpenMoko, Inc.
+ * Author: Harald Welte lafo...@openmoko.org
+ * (C) Copyright 2008 Harald Welte lafo...@openmoko.org
Is this correct and up-to-date?
+unsigned long env_offset;
This is a pretty generic name for something NAND-specific -- as is dynenv.
Maybe this should be a nand subcommand? Putting it in cmd_nand.c would also
eliminate the need to export arg_off_size().
+ if(mtd-oobavail CONFIG_ENV_OFFSET_SIZE){
Please put a space after if and before the opening brace (in fact, there's
no need for the braces at all on this one-liner).
+ printf(Insufficient available OOB bytes: %d OOB bytes
available but %d required for dynenv support\n,mtd-oobavail,8);
Keep lines under 80 columns (both in source code and in output), and put
spaces after commas.
+ }
+
+ oob_buf = malloc(mtd-oobsize);
+ if(!oob_buf)
+ return -ENOMEM;
Let the user know it didn't work?
You only really need 8 bytes, why not just put it on the stack? Likewise in
get_dynenv().
+ ops.datbuf = NULL;
+ ops.mode = MTD_OOB_AUTO;
+ ops.ooboffs = 0;
+ ops.ooblen = CONFIG_ENV_OFFSET_SIZE;
+ ops.oobbuf = (void *) oob_buf;
+
+ ret = mtd-read_oob(mtd, CONFIG_ENV_OFFSET_SIZE, ops);
+ oob_buf[0] = ENV_OOB_MARKER;
+
+ if (!ret) {
+ if(addr ~oob_buf[1]) {
+ printf(ERROR: erase OOB block 0 to
+ write this value\n);
You cannot erase OOB without erasing the entire block, so this message
is a little confusing.
Do you really expect to make use of the ability to set a new address
without erasing, if it only clears bits?
+ ret = mtd-write_oob(mtd, CONFIG_ENV_OFFSET_SIZE, ops);
+ if (!ret)
+ CONFIG_ENV_OFFSET = addr;
+ else {
+ printf(Error writing OOB block 0\n);
+ goto fail;
+ }
If you put braces on one side of the else, put them on both.
+
+ free(oob_buf);
+ } else
+ goto usage;
Likewise.
Is there anything you can do on dynenv set so that the user won't have to
reboot after setting the dynenv to be able to saveenv into the new
environment?
+U_BOOT_CMD(dynenv, 4, 1, do_dynenv,
+ dynenv - dynamically placed (NAND) environment,
+ set off- set enviromnent offset\n
+ dynenv get - get environment offset);
\ No newline at end of file
Please put a newline at the end of the file.
diff --git a/common/cmd_nand.h b/common/cmd_nand.h
new file mode 100644
index 000..023ed4f
--- /dev/null
+++ b/common/cmd_nand.h
@@ -0,0 +1,33 @@
+/*
+ * cmd_nand.h - Convenience functions
+ *
+ * (C) Copyright 2006-2007 OpenMoko, Inc.
+ * Author: Werner Almesberger wer...@openmoko.org
Is this really the right copyright/authorship for this file?
+#ifndef CMD_NAND_H
+#define CMD_NAND_H
+
+#include nand.h
+
+
+/* common/cmd_nand.c */
+int nand_arg_off_size(int argc, char *argv[], nand_info_t *nand, ulong *off,
+ ulong *size, int net);
Just put it in nand.h.
+ if(!ret) {
+ if(oob_buf[0] == ENV_OOB_MARKER) {
+ *result = oob_buf[1];
Should probably encode the environment location as a block number, rather
than as a byte, for flashes larger than 4GiB (there are other places in the
environment handling where this won't work, but let's not add more).
+ }
+ else {
} else {
#ifdef CONFIG_ENV_OFFSET_REDUND
void env_relocate_spec (void)
{
@@ -357,12 +398,23 @@ void env_relocate_spec (void)
#if !defined(ENV_IS_EMBEDDED)
int ret;
+#if defined(CONFIG_ENV_OFFSET_OOB)
+ ret = get_dynenv(CONFIG_ENV_OFFSET);
Taking the address of a macro looks really weird. This will only work if
the macro is defined as env_offset, so why not just use env_offset?
ret = readenv(CONFIG_ENV_OFFSET, (u_char *) env_ptr);
if (ret)
return use_default();
if (crc32(0, env_ptr-data, ENV_SIZE) != env_ptr-crc)
return use_default();
+
#endif /* ! ENV_IS_EMBEDDED */
Unrelated whitespace change, please leave out.
#endif /* CONFIG_ENV_OFFSET_REDUND */
diff --git a/include/environment.h b/include/environment.h
index b9924fd..03b6c92 100644
--- a/include/environment.h
+++ b/include/environment.h
@@ -74,15 +74,24 @@
#endif /* CONFIG_ENV_IS_IN_FLASH */
#if defined(CONFIG_ENV_IS_IN_NAND)
-# ifndef CONFIG_ENV_OFFSET
-# error Need to define CONFIG_ENV_OFFSET when using CONFIG_ENV_IS_IN_NAND
-# endif
+# if
[U-Boot] Pull request: nand flash
The following changes since commit 01f03bda5b22e5aeae5f02fd537da97a41485c73: Wolfgang Denk (1): Prepare v2010.06-rc1 are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master Andrew Caldwell (1): Blackfin: nand: drain the write buffer before returning drivers/mtd/nand/bfin_nand.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: Support dynamic location of enviromnent (CONFIG_ENV_OFFSET_OOB)
Thank you for the thorough review, Scott.
On Wed, May 26, 2010 at 6:58 PM, Scott Wood scottw...@freescale.com wrote:
On Mon, May 17, 2010 at 05:04:30PM -0400, Ben Gardiner wrote:
diff --git a/common/cmd_dynenv.c b/common/cmd_dynenv.c
new file mode 100644
index 000..5167875
--- /dev/null
+++ b/common/cmd_dynenv.c
@@ -0,0 +1,112 @@
+/*
+ * (C) Copyright 2006-2007 OpenMoko, Inc.
+ * Author: Harald Welte lafo...@openmoko.org
+ * (C) Copyright 2008 Harald Welte lafo...@openmoko.org
Is this correct and up-to-date?
The code was taken from Harald's patches he submitted to the mailing
list. I didn't do much to them except to re-factor the 'get'
functionality. Should I have added myself / my organization to the
copyright list? I figured my changes were not enough to warrant the
additional attribution of copyright.
+unsigned long env_offset;
This is a pretty generic name for something NAND-specific -- as is dynenv.
Maybe this should be a nand subcommand? Putting it in cmd_nand.c would also
eliminate the need to export arg_off_size().
I'm glad you brought this up. I was wondering if the command might be
better suited under the nand command -- I agree that it would
eliminate the export of arg_off_size and all the renames, which would
be very nice. Would 'nand dynenv' do? How about 'nand env.oob' ?
+ if(mtd-oobavail CONFIG_ENV_OFFSET_SIZE){
Please put a space after if and before the opening brace (in fact, there's
no need for the braces at all on this one-liner).
will do
+ printf(Insufficient available OOB bytes: %d OOB bytes
available but %d required for dynenv support\n,mtd-oobavail,8);
Keep lines under 80 columns (both in source code and in output), and put
spaces after commas.
sorry about that, I should know better :)
+ }
+
+ oob_buf = malloc(mtd-oobsize);
+ if(!oob_buf)
+ return -ENOMEM;
Let the user know it didn't work?
You only really need 8 bytes, why not just put it on the stack? Likewise in
get_dynenv().
good ideas
+ ops.datbuf = NULL;
+ ops.mode = MTD_OOB_AUTO;
+ ops.ooboffs = 0;
+ ops.ooblen = CONFIG_ENV_OFFSET_SIZE;
+ ops.oobbuf = (void *) oob_buf;
+
+ ret = mtd-read_oob(mtd, CONFIG_ENV_OFFSET_SIZE, ops);
+ oob_buf[0] = ENV_OOB_MARKER;
+
+ if (!ret) {
+ if(addr ~oob_buf[1]) {
+ printf(ERROR: erase OOB block 0 to
+ write this value\n);
You cannot erase OOB without erasing the entire block, so this message
is a little confusing.
Do you really expect to make use of the ability to set a new address
without erasing, if it only clears bits?
No, I suppose not. The main use-case seems to be 'dynenv set' on a
freshly erased nand when using u-boot for programming. OTOH I have
noticed that (one of) the nand erase utility that comes with the TI
OMAP L138 EVM erases the NAND w/o erasing the OOB; so it was useful
during testing to know if I was able to write the correct value to the
OOB. I could replace this with a read-back check to accomplish the
same task -- this will also make 'set' commit the new offset 'live'
(see below)
+ ret = mtd-write_oob(mtd, CONFIG_ENV_OFFSET_SIZE, ops);
+ if (!ret)
+ CONFIG_ENV_OFFSET = addr;
+ else {
+ printf(Error writing OOB block 0\n);
+ goto fail;
+ }
If you put braces on one side of the else, put them on both.
+
+ free(oob_buf);
+ } else
+ goto usage;
Likewise.
will do
Is there anything you can do on dynenv set so that the user won't have to
reboot after setting the dynenv to be able to saveenv into the new
environment?
Good catch. Yes I think this could also be handled by replacing the
OOB bit-check with a call and check of the 'dynenv get' command after
set. In this way the global variable that has been swapped inplace of
CONFIG_ENV_OFFSET will have the value of the newly set dynamic
environment.
+U_BOOT_CMD(dynenv, 4, 1, do_dynenv,
+ dynenv - dynamically placed (NAND) environment,
+ set off - set enviromnent offset\n
+ dynenv get - get environment offset);
\ No newline at end of file
Please put a newline at the end of the file.
sorry I really should have caught that one.
diff --git a/common/cmd_nand.h b/common/cmd_nand.h
new file mode 100644
index 000..023ed4f
--- /dev/null
+++ b/common/cmd_nand.h
@@ -0,0 +1,33 @@
+/*
+ * cmd_nand.h - Convenience functions
+ *
+ * (C) Copyright 2006-2007 OpenMoko, Inc.
+ * Author: Werner Almesberger wer...@openmoko.org
Is this really the right copyright/authorship for this file?
see answer above; but this file will be removed in the next version
since I will stick the dynenv command under the nand
Re: [U-Boot] [PATCH] libfdt: introduce function fdt_get_max_phandle
Wolfgang Denk wrote: Dear Timur Tabi, In message 1274308618-2974-1-git-send-email-ti...@freescale.com you wrote: Introduce function fdt_get_max_phandle(), which returns the largest value of all phandles in a device tree. This is useful for allocating a new phandle property, since all phandles must be unique. Signed-off-by: Timur Tabi ti...@freescale.com --- include/libfdt.h| 20 lib/libfdt/fdt_ro.c | 17 + 2 files changed, 37 insertions(+), 0 deletions(-) Please submit as part of a patch / patch series that acrtually uses this feature. As is, it's just dead code that has no users. I'm happy with this in principle, and will ack formally when the community is OK with the code change. It looks like a positive improvement to me, reducing complexity and addressing Timur/Freescale's needs. Anyway, I envision acking the patch and having FSL include it in whatever MPC8xxx patchset that actually needs the changes. Thanks and best regards, gvb [snip improvement suggestion] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Debugging u-boot with bdi3000 basics
Hi Mark, On 5/27/10, Mark Fanara mark.fan...@gmail.com wrote: ... 2) I am using a bdi3000. Is there no way to build u-boot so that it is directly loaded to RAM by the debugger and does not relocate itself? #define CONFIG_SKIP_RELOCATE_UBOOT BRs, Alan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
