Re: [U-Boot] [PATCH 1/2 v2] net, fec_mxc: only setup the device enetaddr with eeprom value, if ethaddr is not setup
On Wednesday 02 June 2010 21:57:42 Heiko Schocher wrote: Actual fec_mxc.c driver is *not* correct, because if in eeprom is a correct mac, it *always* programms this in the mac address registers from the chip! This is not OK, and must be fixed! i agree 100% 2. Read from environment in net/eth.c after initialize() 3. Give priority to the value in the environment if a conflict 4. Program hardware in the device's init() function. If somebody wants to subvert the 'design philosophy', the right way is to call eth_dev-init() in board code. Maybe this list should go in a doc? the 1. - 4. is already in the documents ive mentioned multiple times, but they arent short to the point like Ben has summarized, so that would probably be good to add as a summary and/or intro to one of them. Ben's suggestion on how to subvert things by forcibly calling eth_dev- init() sits best in my book for people insisting on throwing in a hack today. it could even be done today in the board-specific board_eth_init() function by calling eth_init() after all the NICs have been registered. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 v3] net, fec_mxc: only setup the device enetaddr with eeprom value
only fill the device enetaddr with the contents of the eeprom,
not program it in mac address registers
Signed-off-by: Heiko Schocher h...@denx.de
---
- changes since v1 posted here:
http://lists.denx.de/pipermail/u-boot/2010-March/069192.html
- splitted in two patches as Wolfgang suggested
- changes since v2 posted here:
http://lists.denx.de/pipermail/u-boot/2010-March/069244.html
- add comment from Ben and Mike:
- not to look in content from ethaddr
- only read the mac from eeprom to ethdevices enetaddr and
do not program it in mac address registers
drivers/net/fec_mxc.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 5af9cdb..8c4ade5 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -752,7 +752,6 @@ static int fec_probe(bd_t *bd)
if (fec_get_hwaddr(edev, ethaddr) == 0) {
printf(got MAC address from EEPROM: %pM\n, ethaddr);
memcpy(edev-enetaddr, ethaddr, 6);
- fec_set_hwaddr(edev);
}
return 0;
--
1.6.2.5
--
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] net, doc: how to setup mac address correct.
as this seems unclear, document how the flow of setting up the mac address is correct. Signed-off-by: Heiko Schocher h...@denx.de --- doc/README.enetaddr | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/doc/README.enetaddr b/doc/README.enetaddr index 1d75aa3..9edb6cd 100644 --- a/doc/README.enetaddr +++ b/doc/README.enetaddr @@ -28,6 +28,18 @@ Here are the places where MAC addresses might be stored: purpose of passing this information to an OS kernel we are about to boot +--- + correct flow of setting up the mac address (summarized) +--- + +1. Read from hardware in initialize() function +2. Read from environment in net/eth.c after initialize() +3. Give priority to the value in the environment if a conflict +4. Program hardware in the device's init() function. + +If somebody wants to subvert the 'design philosophy', the right way is to +call eth_dev-init() in board code. + --- Usage --- -- 1.6.2.5 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Loading and Running u-boot from context RAM
Hi Ronny, On Wednesday 31 March 2010 07:16:33 Ronny D wrote: I am working on PPC440 based customized board having 4MB context ram. what are all changes need to perform to skip relocation of u-boot in DDR and relocated it to context ram and run from the same location. I'm not sure if I understand your question correctly. Are you looking for a way to skip the SDRAM initialisation and relocation from FLASH to SDRAM and directly jump to the U-Boot code already located somewhere in RAM? If yes, then you should take a look at the Sequoia (440EPx) ramboot build target. Here the commit log from the base support patch: ppc4xx: Add Sequoia RAM-booting target This patch adds another build target for the AMCC Sequoia PPC440EPx eval board. This RAM-booting version is targeted for boards without NOR FLASH (NAND booting) which need a possibility to initially program their NAND FLASH. Using a JTAG debugger (e.g. BDI2000/3000) configured to setup the SDRAM, this debugger can load this RAM- booting image to the target address in SDRAM (in this case 0x100) and start it there. Then U-Boot's standard NAND commands can be used to program the NAND FLASH (e.g. nand write ...). Here the commands to load and start this image from the BDI2000: 440EPXreset halt 440EPXload 0x100 /tftpboot/sequoia/u-boot.bin 440EPXgo 0x100 Please note that this image automatically scans for an already initialized SDRAM TLB (detected by EPN=0). This TLB will not be cleared. This TLB doesn't need to be TLB #0, this RAM-booting version will detect it and preserve it. So booting via BDI2000 will work and booting with a complete different TLB init via U-Boot works as well. Hope this helps. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Loading and Running u-boot from context RAM
Dear Ronny D, In message 875745.66478...@web46116.mail.sp1.yahoo.com you wrote: I am working on PPC440 based customized board having 4MB context ram. what are all changes need to perform to skip relocation of u-boot in DDR and relocated it to context ram and run from the same location. first: why would you want to do that? Which advantages do you expect compared to running from DDR? It might be sufficient to change the initialization of addr in board_init_f() in lib_ppc/board.c; instead of basing it on CONFIG_SYS_SDRAM_BASE + get_effective_memsize() set it to the end address of your contaxt RAM (+1). Be careful about the relocation of the exception vectors, though. These probably still need to be relocated to 0. I don't know which other obstacles might be on that way - U-Boot's memory map on Power silently assumes that it has contiguous memory from 0 through the current image address. Also, 4 MB might not be sufficient for example to hold the malloc arena if you want to uncompress bigger bz2 compressed images, and so on. All in all I expect some effort especially for debugging, and little or no benefit. 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 no distinctly American criminal class except Congress. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v3] net, fec_mxc: only setup the device enetaddr with eeprom value
Hi Heiko,
Much better. Thanks, and sorry again for not responding sooner.
Wolfgang - please apply this to the current release.
On Tue, Mar 30, 2010 at 11:34 PM, Heiko Schocher h...@denx.de wrote:
only fill the device enetaddr with the contents of the eeprom,
not program it in mac address registers
Signed-off-by: Heiko Schocher h...@denx.de
Acked-by: Ben Warren biggerbadder...@gmail.com
---
- changes since v1 posted here:
http://lists.denx.de/pipermail/u-boot/2010-March/069192.html
- splitted in two patches as Wolfgang suggested
- changes since v2 posted here:
http://lists.denx.de/pipermail/u-boot/2010-March/069244.html
- add comment from Ben and Mike:
- not to look in content from ethaddr
- only read the mac from eeprom to ethdevices enetaddr and
do not program it in mac address registers
drivers/net/fec_mxc.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 5af9cdb..8c4ade5 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -752,7 +752,6 @@ static int fec_probe(bd_t *bd)
if (fec_get_hwaddr(edev, ethaddr) == 0) {
printf(got MAC address from EEPROM: %pM\n, ethaddr);
memcpy(edev-enetaddr, ethaddr, 6);
- fec_set_hwaddr(edev);
}
return 0;
--
1.6.2.5
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v3] net, fec_mxc: only setup the device enetaddr with eeprom value
Dear Ben Warren, In message w2if8328f7c1003302350o154a5e96k25d7f8674657...@mail.gmail.com you wrote: Wolfgang - please apply this to the current release. On Tue, Mar 30, 2010 at 11:34 PM, Heiko Schocher h...@denx.de wrote: only fill the device enetaddr with the contents of the eeprom, not program it in mac address registers Signed-off-by: Heiko Schocher h...@denx.de Acked-by: Ben Warren biggerbadder...@gmail.com 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 As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v3] net, fec_mxc: only setup the device enetaddr with eeprom value
Dear Heiko Schocher, In message 4bb2ed06.3010...@denx.de you wrote: only fill the device enetaddr with the contents of the eeprom, not program it in mac address registers Signed-off-by: Heiko Schocher h...@denx.de --- - changes since v1 posted here: http://lists.denx.de/pipermail/u-boot/2010-March/069192.html - splitted in two patches as Wolfgang suggested - changes since v2 posted here: http://lists.denx.de/pipermail/u-boot/2010-March/069244.html - add comment from Ben and Mike: - not to look in content from ethaddr - only read the mac from eeprom to ethdevices enetaddr and do not program it in mac address registers drivers/net/fec_mxc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) Thanks. Applied after reverting v2. 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 An Elephant is a mouse with an Operating System. - Knuth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net, doc: how to setup mac address correct.
Dear Heiko Schocher, In message 4bb2ed0b.6030...@denx.de you wrote: as this seems unclear, document how the flow of setting up the mac address is correct. Signed-off-by: Heiko Schocher h...@denx.de --- doc/README.enetaddr | 12 1 files changed, 12 insertions(+), 0 deletions(-) Thanks. Applied (as discussed internally) with slight changes, adding Mike Frysinger's input. 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 would seem that evil retreats when forcibly confronted -- Yarnek of Excalbia, The Savage Curtain, stardate 5906.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MX51EVK: Remove CPLD related code
Fabio Estevam wrote: There is no CPLD on MX51EVK board, so remove CPLD related function. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Agree. Thanks to point out this issue. The code is not needed. - mx51_io_board = (struct io_board_ctrl *)(CS5_BASE_ADDR + - IO_BOARD_OFFSET); You should remove the #define for IO_BOARD_OFFSET from mx51evk.h, too. Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] net, fec_mxc: only setup the device enetaddr with eeprom value, if ethaddr is not setup
thanks Heiko for the followups -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] may i get in
thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Saving environment variables in MMC
Frans Meulenbroeks wrote: 2010/3/30 Nitin Mahajan nitin...@yahoo.com: Hi, Found this in the past: http://bitshrine.org/gpp/u-boot-200910-cd77dd10-save-the-env-var-to-SDcard-and-SPI.patch You can take a look at this one, too: http://lists.denx.de/pipermail/u-boot/2009-November/063775.html The patch has open comments, but the developer stated he will send an updated version for review. Regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Booting from ext2/ext3
Hi all, how does the implementation of the ext2 module work in u-boot? As I see, u-boot can load the kernel from an ext2 file system using ext2load. Unfortunately, this command is not included in my build of u-boot. Did I miss some compile-switch, or do I have to explicitly include ext2fs.h somewhere? How can I enable the ext2/ext3 functionality? Another related question is, if I can format an ext2/ext3 drive from u-boot or how I can bring up a new image to my internal device, once u-boot is running. Cheers Matthias Dunda ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Saving environment variables in MMC
Hello, --- On Wed, 31/3/10, Stefano Babic sba...@denx.de wrote: From: Stefano Babic sba...@denx.de Subject: Re: [U-Boot] Saving environment variables in MMC To: nitin...@yahoo.com Cc: Frans Meulenbroeks fransmeulenbro...@gmail.com, U-Boot user list u-boot@lists.denx.de Date: Wednesday, 31 March, 2010, 4:17 PM Frans Meulenbroeks wrote: 2010/3/30 Nitin Mahajan nitin...@yahoo.com: Hi, Found this in the past: http://bitshrine.org/gpp/u-boot-200910-cd77dd10-save-the-env-var-to-SDcard-and-SPI.patch You can take a look at this one, too: http://lists.denx.de/pipermail/u-boot/2009-November/063775.html Thanks for the information. I just wanted to have a feedback, whether having a use-case of writing env variables from Linux User space is a good idea or is not recommended? regards -Nitin New Email addresses available on Yahoo! Get the Email name you#39;ve always wanted on the new @ymail and @rocketmail. Hurry before someone else does! http://mail.promotions.yahoo.com/newdomains/aa/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting from ext2/ext3
Dear Dunda, Matthias, In message 569685f045b85741820d0265e0d2999d019cf...@tddhh01.hh.thales-naval.de you wrote: As I see, u-boot can load the kernel from an ext2 file system using ext2load. Unfortunately, this command is not included in my build of u-boot. Did I miss some compile-switch, or do I have to explicitly include ext2fs.h somewhere? How can I enable the ext2/ext3 functionality? This depends on CONFIG_CMD_EXT2 Another related question is, if I can format an ext2/ext3 drive from u-boot or how I can bring up a new image to my internal device, once u-boot is running. You cannot. U-Boot supports only read-only accesses to the file systems. You can load and write complete images to flash, but you cannot use U-Boot to mkfs or to write individual files. 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 No question is too silly to ask. Of course, some questions are too silly to to answer... - L. Wall R. L. Schwartz, _Programming Perl_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Enable PXAFB for PXA27X and PXA3XX
Dne Pá 26. března 2010 06:57:50 Marek Vasut napsal(a):
---
common/lcd.c| 12 ++--
cpu/pxa/pxafb.c |9 -
include/lcd.h |2 +-
3 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 64fb1c6..c2e350e 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -41,7 +41,7 @@
#include lcd.h
#include watchdog.h
-#if defined(CONFIG_PXA250)
+#if defined CONFIG_PXA250 || defined CONFIG_PXA27X || defined
CONFIG_CPU_MONAHANS #include asm/byteorder.h
#endif
@@ -503,7 +503,7 @@ void bitmap_plot (int x, int y)
uchar *bmap;
uchar *fb;
ushort *fb16;
-#if defined(CONFIG_PXA250)
+#if defined CONFIG_PXA250 || defined CONFIG_PXA27X || defined
CONFIG_CPU_MONAHANS struct pxafb_info *fbi = panel_info.pxa;
#elif defined(CONFIG_MPC823)
volatile immap_t *immr = (immap_t *) CONFIG_SYS_IMMR;
@@ -519,7 +519,7 @@ void bitmap_plot (int x, int y)
if (NBITS(panel_info.vl_bpix) 12) {
/* Leave room for default color map */
-#if defined(CONFIG_PXA250)
+#if defined CONFIG_PXA250 || defined CONFIG_PXA27X || defined
CONFIG_CPU_MONAHANS cmap = (ushort *)fbi-palette;
#elif defined(CONFIG_MPC823)
cmap = (ushort
*)(cp-lcd_cmap[BMP_LOGO_OFFSET*sizeof(ushort)]);
@@ -615,7 +615,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
unsigned long pwidth = panel_info.vl_col;
unsigned colors, bpix, bmp_bpix;
unsigned long compression;
-#if defined(CONFIG_PXA250)
+#if defined CONFIG_PXA250 || defined CONFIG_PXA27X || defined
CONFIG_CPU_MONAHANS struct pxafb_info *fbi = panel_info.pxa;
#elif defined(CONFIG_MPC823)
volatile immap_t *immr = (immap_t *) CONFIG_SYS_IMMR;
@@ -656,7 +656,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
#if !defined(CONFIG_MCC200)
/* MCC200 LCD doesn't need CMAP, supports 1bpp bw only */
if (bmp_bpix == 8) {
-#if defined(CONFIG_PXA250)
+#if defined CONFIG_PXA250 || defined CONFIG_PXA27X || defined
CONFIG_CPU_MONAHANS cmap = (ushort *)fbi-palette;
#elif defined(CONFIG_MPC823)
cmap = (ushort *)(cp-lcd_cmap[255*sizeof(ushort)]);
@@ -745,7 +745,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
WATCHDOG_RESET();
for (j = 0; j width; j++) {
if (bpix != 16) {
-#if defined(CONFIG_PXA250) || defined(CONFIG_ATMEL_LCD)
+#if defined CONFIG_PXA250 || defined CONFIG_PXA27X || defined
CONFIG_CPU_MONAHANS || defined(CONFIG_ATMEL_LCD) *(fb++) = *(bmap++);
#elif defined(CONFIG_MPC823) || defined(CONFIG_MCC200)
*(fb++) = 255 - *(bmap++);
diff --git a/cpu/pxa/pxafb.c b/cpu/pxa/pxafb.c
index d56c5f0..1cb78f0 100644
--- a/cpu/pxa/pxafb.c
+++ b/cpu/pxa/pxafb.c
@@ -292,7 +292,9 @@ static int pxafb_init_mem (void *lcdbase, vidinfo_t
*vid)
return 0;
}
-
+#ifdef CONFIG_CPU_MONAHANS
+static inline void pxafb_setup_gpio (vidinfo_t *vid) {}
+#else
static void pxafb_setup_gpio (vidinfo_t *vid)
{
u_long lccr0;
@@ -349,6 +351,7 @@ static void pxafb_setup_gpio (vidinfo_t *vid)
printf(pxafb_setup_gpio: unable to determine bits per
pixel\n);
}
}
+#endif
static void pxafb_enable_controller (vidinfo_t *vid)
{
@@ -363,7 +366,11 @@ static void pxafb_enable_controller (vidinfo_t *vid)
FDADR1 = vid-pxa.fdadr1;
LCCR0 |= LCCR0_ENB;
+#ifdef CONFIG_CPU_MONAHANS
+ CKENA |= CKENA_1_LCD;
+#else
CKEN |= CKEN16_LCD;
+#endif
debug(FDADR0 = 0x%08x\n, (unsigned int)FDADR0);
debug(FDADR1 = 0x%08x\n, (unsigned int)FDADR1);
diff --git a/include/lcd.h b/include/lcd.h
index 1f85daa..cd9d49d 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -87,7 +87,7 @@ typedef struct vidinfo {
u_char vl_wbf; /* Wait between frames */
} vidinfo_t;
-#elif defined CONFIG_PXA250
+#elif defined CONFIG_PXA250 || defined CONFIG_PXA27X || defined
CONFIG_CPU_MONAHANS /*
* PXA LCD DMA descriptor
*/
Hi,
any updates on this ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] MX51EVK: Remove CPLD related code
There is no CPLD on MX51EVK board, so remove CPLD related function.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx51evk/mx51evk.c | 67 -
board/freescale/mx51evk/mx51evk.h |1 -
2 files changed, 0 insertions(+), 68 deletions(-)
diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index 8754563..f0b7abc 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -72,72 +72,6 @@ static void setup_iomux_uart(void)
mxc_iomux_set_pad(MX51_PIN_UART1_CTS, pad);
}
-static void setup_expio(void)
-{
- u32 reg;
- struct weim *pweim = (struct weim *)WEIM_BASE_ADDR;
- struct clkctl *pclkctl = (struct clkctl *)CCM_BASE_ADDR;
-
- /* CS5 setup */
- mxc_request_iomux(MX51_PIN_EIM_CS5, IOMUX_CONFIG_ALT0);
- writel(0x00410089, pweim[5].csgcr1);
- writel(0x0002, pweim[5].csgcr2);
-
- /* RWSC=50, RADVA=2, RADVN=6, OEA=0, OEN=0, RCSA=0, RCSN=0 */
- writel(0x3226, pweim[5].csrcr1);
-
- /* APR = 0 */
- writel(0x, pweim[5].csrcr2);
-
- /*
-* WAL=0, WBED=1, WWSC=50, WADVA=2, WADVN=6, WEA=0, WEN=0,
-* WCSA=0, WCSN=0
-*/
- writel(0x72080F00, pweim[5].cswcr1);
-
- mx51_io_board = (struct io_board_ctrl *)(CS5_BASE_ADDR +
- IO_BOARD_OFFSET);
- if ((readw(mx51_io_board-id1) == 0x)
- (readw(mx51_io_board-id2) == 0x)) {
- if (is_soc_rev(CHIP_REV_2_0) 0) {
- reg = readl(pclkctl-cbcdr);
- reg = (reg (~0x7)) | 0x3;
- writel(reg, pclkctl-cbcdr);
- /* make sure divider effective */
- while (readl(pclkctl-cdhipr) != 0)
- ;
- writel(0x0, pclkctl-ccdr);
- }
- } else {
- /* CS1 */
- writel(0x00410089, pweim[1].csgcr1);
- writel(0x0002, pweim[1].csgcr2);
- /* RWSC=50, RADVA=2, RADVN=6, OEA=0, OEN=0, RCSA=0, RCSN=0 */
- writel(0x3226, pweim[1].csrcr1);
- /* APR=0 */
- writel(0x, pweim[1].csrcr2);
- /*
-* WAL=0, WBED=1, WWSC=50, WADVA=2, WADVN=6, WEA=0,
-* WEN=0, WCSA=0, WCSN=0
-*/
- writel(0x72080F00, pweim[1].cswcr1);
- mx51_io_board = (struct io_board_ctrl *)(CS1_BASE_ADDR +
- IO_BOARD_OFFSET);
- }
-
- /* Reset interrupt status reg */
- writew(0x1F, (mx51_io_board-int_rest));
- writew(0x00, (mx51_io_board-int_rest));
- writew(0x, (mx51_io_board-int_mask));
-
- /* Reset the XUART and Ethernet controllers */
- reg = readw((mx51_io_board-sw_reset));
- reg |= 0x9;
- writew(reg, (mx51_io_board-sw_reset));
- reg = ~0x9;
- writew(reg, (mx51_io_board-sw_reset));
-}
-
static void setup_iomux_fec(void)
{
/*FEC_MDIO*/
@@ -349,7 +283,6 @@ int board_init(void)
gd-bd-bi_boot_params = PHYS_SDRAM_1 + 0x100;
setup_iomux_uart();
- setup_expio();
setup_iomux_fec();
return 0;
}
diff --git a/board/freescale/mx51evk/mx51evk.h
b/board/freescale/mx51evk/mx51evk.h
index 524cdcc..2854e71 100644
--- a/board/freescale/mx51evk/mx51evk.h
+++ b/board/freescale/mx51evk/mx51evk.h
@@ -47,5 +47,4 @@ struct io_board_ctrl {
};
#endif
-#define IO_BOARD_OFFSET(0x2)
#endif
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] net, fec_mxc: only setup the device enetaddr with eeprom value, if ethaddr is not setup
Hi Ben, Hold on a second. This patch is wrong. As Mike has pointed out, the net library already gets the MAC address from the environment. The correct flow is: 1. Read from hardware in initialize() function 2. Read from environment in net/eth.c after initialize() 3. Give priority to the value in the environment if a conflict 4. Program hardware in the device's init() function. If somebody wants to subvert the 'design philosophy', the right way is to call eth_dev-init() in board code. This would mean that for the real problem of a missing mac address, the device then is initialized completely adding the autonegotation timeout to every bootup sequence, correct? If it is, then it doesn't solve my problem in an acceptable way. On the other hand a different route occured to Wolfgang and me in a lengthy discussion. This will need a little broader interpretation of the design guidelines, but as I still cannot see any downside to this and it will also fix some inconsistent behaviour _that we currently have_ (setenv ethaddr ..., do not do any network transfer and boot linux), I want to follow this route. I will try to implement this in form of a patch in order to keep the discussion close to the effects on the code base. Cheers Detlev -- #!/usr/bin/perl $c=print\\#\!\/usr\/bin\/perl\ \\\$c\=\.quotemeta\(\$c\)\.\;\\n\$c;\; print#!/usr/bin/perl\n\$c=\.quotemeta($c).\;\n$c;; -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Saving environment variables in MMC
Nitin Mahajan wrote: Hello, --- On Wed, 31/3/10, Stefano Babic sba...@denx.de wrote: Thanks for the information. I just wanted to have a feedback, whether having a use-case of writing env variables from Linux User space is a good idea or is not recommended? Yes, it is possible to share info between Linux and u-boot. Take a look at the tools/env directory to see how. Regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] net, fec_mxc: only setup the device enetaddr with eeprom value, if ethaddr is not setup
Hi Detlev, On Wed, Mar 31, 2010 at 6:44 AM, Detlev Zundel d...@denx.de wrote: Hi Ben, Hold on a second. This patch is wrong. As Mike has pointed out, the net library already gets the MAC address from the environment. The correct flow is: 1. Read from hardware in initialize() function 2. Read from environment in net/eth.c after initialize() 3. Give priority to the value in the environment if a conflict 4. Program hardware in the device's init() function. If somebody wants to subvert the 'design philosophy', the right way is to call eth_dev-init() in board code. This would mean that for the real problem of a missing mac address, the device then is initialized completely adding the autonegotation timeout to every bootup sequence, correct? My suggestion here is a crude hack, and definitely does more than needed. It has the advantage of having narrow scope (is limited to the board in question). If it is, then it doesn't solve my problem in an acceptable way. On the other hand a different route occured to Wolfgang and me in a lengthy discussion. This will need a little broader interpretation of the design guidelines, but as I still cannot see any downside to this and it will also fix some inconsistent behaviour _that we currently have_ (setenv ethaddr ..., do not do any network transfer and boot linux), I want to follow this route. I will try to implement this in form of a patch in order to keep the discussion close to the effects on the code base. I'm looking forward to seeing what you come up with. I personally don't have a problem with adding the few ns to boot-up time that programming an SOC's MAC would take, but dislike the piece-meal approach that's been done so far. Cheers Detlev regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting from ext2/ext3
Unfortunately, this command is not included in my build of u-boot. Did I miss some compile-switch, or do I have to explicitly include ext2fs.h somewhere? How can I enable the ext2/ext3 functionality? This depends on CONFIG_CMD_EXT2 Thanks, I added this along with CONFIG_DOS_PARTITION to my board configuration file - which so far is a copy of the MPC8568MDS.h During the final linking I get the following errors: common/libcommon.a(cmd_ext2.o): In function `do_ext2load': u-boot-2009.11.1/common/cmd_ext2.c:193: undefined reference to `get_partition_info' fs/ext2/libext2fs.a(dev.o): In function `ext2fs_set_blk_dev': u-boot-2009.11.1/fs/ext2/dev.c:45: undefined reference to `get_partition_info' make: *** [u-boot] Error 1 Full build output is attached. What's the issue here? Cheers Matthias uboot.log.gz Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] may i get in
Hi Wan Jin, thanks If you want to get in to the mailing list, try the webinterface: ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Cheers Detlev -- More than any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other to total extinction. Let us pray, we have the wisdom to choose correctly. -- Woody Allen -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Saving environment variables in MMC
Hi Nitin, Thanks for the information. I just wanted to have a feedback, whether having a use-case of writing env variables from Linux User space is a good idea or is not recommended? You found tools/env/fw_env.c showing that this functionality is indeed foreseen and used. It is rather common to write to the U-Boot environment in projects for example to switch to a new set of kernel+file system after an update from within linux for the next boot. Is this feedback enough? Cheers Detlev -- The structure of a system reflects the structure of the organization that built it. -- Richard E. Fairley -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ati_radeon: return error with when emulator fails
Console was being switched to video even if emulator fails and causing this hang: Scanning PCI bus 04 04 00 1095 3132 0104 00 PCIE3 on bus 03 - 04 Video: ATI Radeon video card (1002, 5b60) found @(2:0:0) videoboot: Booting PCI video card bus 2, function 0, device 0 videoboot: Video ROM failed to map! 640x480x8 31kHz 59Hz radeonfb: FIFO Timeout ! Signed-off-by: Ed Swarthout ed.swarth...@freescale.com --- I consider this a bug fix. I'm also sending an independent patch that fixes the problem that caused this error. drivers/bios_emulator/atibios.c |3 ++- drivers/video/ati_radeon_fb.c |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/bios_emulator/atibios.c b/drivers/bios_emulator/atibios.c index 5f9bd10..2881449 100644 --- a/drivers/bios_emulator/atibios.c +++ b/drivers/bios_emulator/atibios.c @@ -315,7 +315,8 @@ int BootVideoCardBIOS(pci_dev_t pcidev, BE_VGAInfo ** pVGAInfo, int cleanUp) BE_init(0, 65536, VGAInfo, 0); /*Post all the display controller BIOS'es*/ - PCI_postController(pcidev, VGAInfo); + if (!PCI_postController(pcidev, VGAInfo)) + return false; /*Cleanup and exit the emulator if requested. If the BIOS emulator is needed after booting the card, we will not call BE_exit and diff --git a/drivers/video/ati_radeon_fb.c b/drivers/video/ati_radeon_fb.c index 9ebb0b0..529ddae 100644 --- a/drivers/video/ati_radeon_fb.c +++ b/drivers/video/ati_radeon_fb.c @@ -597,7 +597,8 @@ int radeon_probe(struct radeonfb_info *rinfo) rinfo-fb_local_base = INREG(MC_FB_LOCATION) 16; DPRINT(rinfo-fb_local_base = 0x%x\n,rinfo-fb_local_base); /* PostBIOS with x86 emulater */ - BootVideoCardBIOS(pdev, NULL, 0); + if (!BootVideoCardBIOS(pdev, NULL, 0)) + return -1; /* * Check for errata -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ati_radeon: Support PCI virtual not eq bus mapping.
Use pci_bus_to_virt() to convert the bus address from the BARs to
virtual address' to eliminate the direct mapping requirement.
Rename variables to better match usage (_phys - _bus or no-suffix)
This fixes the mpc8572ds CONFIG_PYS_64BIT mode failure:
videoboot: Vidoe ROM failed to map!
Tested on mpc8572ds with and without CONFIG_PHYS_64BIT.
Signed-off-by: Ed Swarthout ed.swarth...@freescale.com
---
This patch is independent of the ati radeon return error patch,
but for ease of debug it should be applied with this one.
drivers/bios_emulator/atibios.c |9 ---
drivers/video/ati_radeon_fb.c | 45 --
drivers/video/ati_radeon_fb.h |4 +-
3 files changed, 31 insertions(+), 27 deletions(-)
diff --git a/drivers/bios_emulator/atibios.c b/drivers/bios_emulator/atibios.c
index 2881449..f488259 100644
--- a/drivers/bios_emulator/atibios.c
+++ b/drivers/bios_emulator/atibios.c
@@ -173,7 +173,7 @@ Maps a pointer to the BIOS image on the graphics card on
the PCI bus.
/
void *PCI_mapBIOSImage(pci_dev_t pcidev)
{
- u32 BIOSImagePhys;
+ u32 BIOSImageBus;
int BIOSImageBAR;
u8 *BIOSImage;
@@ -195,16 +195,17 @@ void *PCI_mapBIOSImage(pci_dev_t pcidev)
specific programming for different cards to solve this problem.
*/
- if ((BIOSImagePhys = PCI_findBIOSAddr(pcidev, BIOSImageBAR)) == 0) {
+ if ((BIOSImageBus = PCI_findBIOSAddr(pcidev, BIOSImageBAR)) == 0) {
printf(Find bios addr error\n);
return NULL;
}
- BIOSImage = (u8 *) BIOSImagePhys;
+ BIOSImage = pci_bus_to_virt(pcidev, BIOSImageBus,
+ PCI_REGION_MEM, 0, MAP_NOCACHE);
/*Change the PCI BAR registers to map it onto the bus.*/
pci_write_config_dword(pcidev, BIOSImageBAR, 0);
- pci_write_config_dword(pcidev, PCI_ROM_ADDRESS, BIOSImagePhys | 0x1);
+ pci_write_config_dword(pcidev, PCI_ROM_ADDRESS, BIOSImageBus | 0x1);
udelay(1);
diff --git a/drivers/video/ati_radeon_fb.c b/drivers/video/ati_radeon_fb.c
index 529ddae..a74f724 100644
--- a/drivers/video/ati_radeon_fb.c
+++ b/drivers/video/ati_radeon_fb.c
@@ -210,7 +210,7 @@ static void radeon_identify_vram(struct radeonfb_info
*rinfo)
* ToDo: identify these cases
*/
- DPRINT(radeonfb: Found %ldk of %s %d bits wide videoram\n,
+ DPRINT(radeonfb: Found %dk of %s %d bits wide videoram\n,
rinfo-video_ram / 1024,
rinfo-vram_ddr ? DDR : SDRAM,
rinfo-vram_width);
@@ -586,14 +586,16 @@ int radeon_probe(struct radeonfb_info *rinfo)
rinfo-pdev.device = did;
rinfo-family = get_radeon_id_family(rinfo-pdev.device);
pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0,
- rinfo-fb_base_phys);
+ rinfo-fb_base_bus);
pci_read_config_dword(pdev, PCI_BASE_ADDRESS_2,
- rinfo-mmio_base_phys);
- rinfo-fb_base_phys = 0xf000;
- rinfo-mmio_base_phys = ~0x04;
-
- rinfo-mmio_base = (void *)rinfo-mmio_base_phys;
- DPRINT(rinfo-mmio_base = 0x%x\n,rinfo-mmio_base);
+ rinfo-mmio_base_bus);
+ rinfo-fb_base_bus = 0xf000;
+ rinfo-mmio_base_bus = ~0x04;
+
+ rinfo-mmio_base = pci_bus_to_virt(pdev, rinfo-mmio_base_bus,
+ PCI_REGION_MEM, 0, MAP_NOCACHE);
+ DPRINT(rinfo-mmio_base = 0x%x bus=0x%x\n,
+ rinfo-mmio_base, rinfo-mmio_base_bus);
rinfo-fb_local_base = INREG(MC_FB_LOCATION) 16;
DPRINT(rinfo-fb_local_base = 0x%x\n,rinfo-fb_local_base);
/* PostBIOS with x86 emulater */
@@ -611,14 +613,15 @@ int radeon_probe(struct radeonfb_info *rinfo)
rinfo-mapped_vram = min_t(unsigned long, MAX_MAPPED_VRAM,
rinfo-video_ram);
- rinfo-fb_base = (void *)rinfo-fb_base_phys;
-
- DPRINT(Radeon: framebuffer base phy address 0x%08x, \
- MMIO base phy address 0x%08x, \
- framebuffer local base 0x%08x.\n ,
- rinfo-fb_base_phys, rinfo-mmio_base_phys,
- rinfo-fb_local_base);
-
+ rinfo-fb_base = pci_bus_to_virt(pdev, rinfo-fb_base_bus,
+ PCI_REGION_MEM, 0, MAP_NOCACHE);
+ DPRINT(Radeon: framebuffer base address 0x%08x,
+ bus address 0x%08x\n
+ MMIO base address 0x%08x, bus address 0x%08x,
+ framebuffer local base 0x%08x.\n ,
+ (u32)rinfo-fb_base, rinfo-fb_base_bus,
+
Re: [U-Boot] [PATCH 1/2 v2] net, fec_mxc: only setup the device enetaddr with eeprom value, if ethaddr is not setup
Hi Ben, Hi Detlev, On Wed, Mar 31, 2010 at 6:44 AM, Detlev Zundel d...@denx.de wrote: Hi Ben, Hold on a second. This patch is wrong. As Mike has pointed out, the net library already gets the MAC address from the environment. The correct flow is: 1. Read from hardware in initialize() function 2. Read from environment in net/eth.c after initialize() 3. Give priority to the value in the environment if a conflict 4. Program hardware in the device's init() function. If somebody wants to subvert the 'design philosophy', the right way is to call eth_dev-init() in board code. This would mean that for the real problem of a missing mac address, the device then is initialized completely adding the autonegotation timeout to every bootup sequence, correct? My suggestion here is a crude hack, and definitely does more than needed. It has the advantage of having narrow scope (is limited to the board in question). This specific problem in the meantime hit me on multiple arm boards with different network interfaces so I think it has a broader audience than a single board. If it is, then it doesn't solve my problem in an acceptable way. On the other hand a different route occured to Wolfgang and me in a lengthy discussion. This will need a little broader interpretation of the design guidelines, but as I still cannot see any downside to this and it will also fix some inconsistent behaviour _that we currently have_ (setenv ethaddr ..., do not do any network transfer and boot linux), I want to follow this route. I will try to implement this in form of a patch in order to keep the discussion close to the effects on the code base. I'm looking forward to seeing what you come up with. I personally don't have a problem with adding the few ns to boot-up time that programming an SOC's MAC would take, but dislike the piece-meal approach that's been done so far. I fully agree. Previously I was under the impression that we already have a fast initialization (probe) and a full initialization (init) of the network interfaces, where programming the mac would (on a first stab) fit into the probe part (and some drivers obviously do/did this). In the meantime it seems like it is a broader problem of keeping ethaddr and friends in sync with the real hardware. Although this is something I personally always took for granted, it currently is most of the time but not always correct. If we solve the latter problem in a nice way, the initial problem will simply disappear (or so I hope) ;) Cheers Detlev -- You live and learn -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Added serial loopback tests accessible via CLI and POST
Dear Wolfgang, On Wed, Mar 31, 2010 at 12:27 AM, Wolfgang Denk w...@denx.de wrote: I think this is a consequence of trying to squeeze soemthing into a framework which doesn't fit. POST and production test code should be kept separate. If they share common code, fine. Best regards, Wolfgang Denk Strange, is not it what I did in the patch? I added POST uart tests for 16550 compatible uarts in the post/drivers/serial.c file and added uarttest command for production testing in the drivers/serial/serial.c file. Thus these tests are separated and serve different purposes. And both of them share common code. Probably it makes sense to divide the patch into two separate patches? Regards, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] TI: TNETV107X EVM initial support
Wolfgang, [...] Is davinci correct here? Yes, this SOC has the exact same controller as on Davinci, and therefore the NAND driver is reused. But you don't call this a Davinci-Board, or do you? Davinci NAND is a bit of a misnomer since this particular EMIF block is commonly used across multiple TI devices. Unfortunately, this misnomer (amongst others) carries forward into the kernel too. Consequently, if we use a different device name here, the mtdparts variable won't be usable as a kernel command-line argument. Regards Cyril. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: Trivial coding style issue with empty for statement
Signed-off-by: Detlev Zundel d...@denx.de
CC: Ben Warren biggerbadder...@gmail.com
---
net/eth.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/eth.c b/net/eth.c
index b650a20..aff6987 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -1,5 +1,5 @@
/*
- * (C) Copyright 2001-2004
+ * (C) Copyright 2001-2010
* Wolfgang Denk, DENX Software Engineering, w...@denx.de.
*
* See file CREDITS for list of people who contributed to this
@@ -173,7 +173,8 @@ int eth_register(struct eth_device* dev)
}
#endif
} else {
- for (d=eth_devices; d-next!=eth_devices; d=d-next);
+ for (d=eth_devices; d-next!=eth_devices; d=d-next)
+ ;
d-next = dev;
}
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ati_radeon: Support PCI virtual not eq bus mapping.
On Wed, 31 Mar 2010 09:54:57 -0500
Ed Swarthout ed.swarth...@freescale.com wrote:
Use pci_bus_to_virt() to convert the bus address from the BARs to
virtual address' to eliminate the direct mapping requirement.
Rename variables to better match usage (_phys - _bus or no-suffix)
This fixes the mpc8572ds CONFIG_PYS_64BIT mode failure:
videoboot: Vidoe ROM failed to map!
s/CONFIG_PYS_64BIT/CONFIG_PHYS_64BIT
s/Vidoe/Video
Tested on mpc8572ds with and without CONFIG_PHYS_64BIT.
Signed-off-by: Ed Swarthout ed.swarth...@freescale.com
---
This patch is independent of the ati radeon return error patch,
but for ease of debug it should be applied with this one.
drivers/bios_emulator/atibios.c |9 ---
drivers/video/ati_radeon_fb.c | 45 --
drivers/video/ati_radeon_fb.h |4 +-
3 files changed, 31 insertions(+), 27 deletions(-)
With this patch applied following warnings appear:
ati_radeon_fb.c: In function 'video_hw_init':
ati_radeon_fb.c:740: warning: assignment makes integer from pointer without a
cast
ati_radeon_fb.c:741: warning: assignment makes integer from pointer without a
cast
ati_radeon_fb.c:746: warning: assignment makes integer from pointer without a
cast
ati_radeon_fb.c:754: warning: assignment makes integer from pointer without a
cast
ati_radeon_fb.c:755: warning: assignment makes integer from pointer without a
cast
Please include inlined patch below to fix them. Thanks.
Other than this, I tested this patch on PPC440EPx based sequoia board
with ATI Radeon 9250 PCI card, it works.
Anatolij
diff --git a/drivers/video/ati_radeon_fb.c b/drivers/video/ati_radeon_fb.c
index a74f724..c2c2096 100644
--- a/drivers/video/ati_radeon_fb.c
+++ b/drivers/video/ati_radeon_fb.c
@@ -737,13 +737,13 @@ void *video_hw_init(void)
}
pGD-isaBase = CONFIG_SYS_ISA_IO_BASE_ADDRESS;
- pGD-pciBase = rinfo-fb_base;
- pGD-frameAdrs = rinfo-fb_base;
+ pGD-pciBase = (unsigned int)rinfo-fb_base;
+ pGD-frameAdrs = (unsigned int)rinfo-fb_base;
pGD-memSize = 64 * 1024 * 1024;
/* Cursor Start Address */
- pGD-dprBase =
- (pGD-winSizeX * pGD-winSizeY * pGD-gdfBytesPP) + rinfo-fb_base;
+ pGD-dprBase = (pGD-winSizeX * pGD-winSizeY * pGD-gdfBytesPP) +
+ (unsigned int)rinfo-fb_base;
if ((pGD-dprBase 0x0fff) != 0) {
/* allign it */
pGD-dprBase = 0xf000;
@@ -751,8 +751,8 @@ void *video_hw_init(void)
}
DPRINT (Cursor Start %x Pattern Start %x\n, pGD-dprBase,
PATTERN_ADR);
- pGD-vprBase = rinfo-fb_base; /* Dummy */
- pGD-cprBase = rinfo-fb_base; /* Dummy */
+ pGD-vprBase = (unsigned int)rinfo-fb_base;/* Dummy */
+ pGD-cprBase = (unsigned int)rinfo-fb_base;/* Dummy */
/* set up Hardware */
/* Clear video memory (only visible screen area) */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ati_radeon: return error with when emulator fails
On Wed, 31 Mar 2010 09:54:28 -0500 Ed Swarthout ed.swarth...@freescale.com wrote: Console was being switched to video even if emulator fails and causing this hang: Scanning PCI bus 04 04 00 1095 3132 0104 00 PCIE3 on bus 03 - 04 Video: ATI Radeon video card (1002, 5b60) found @(2:0:0) videoboot: Booting PCI video card bus 2, function 0, device 0 videoboot: Video ROM failed to map! 640x480x8 31kHz 59Hz radeonfb: FIFO Timeout ! Signed-off-by: Ed Swarthout ed.swarth...@freescale.com Tested-by: Anatolij Gustschin ag...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] ARM1176: Coexist with other ARM1176 platforms
The current ARM1176 CPU specific code is too specific to the SMDK6400 architecture. The following changes were necessary prerequisites for the addition of other SoCs based on ARM1176. Existing board's (SMDK6400) configuration has been modified to keep behavior unchanged despite these changes. 1. Peripheral port remap configurability The earlier code had hardcoded remap values specific to s3c64xx in start.S. This change makes the peripheral port remap addresses and sizes configurable. 2. Skip low level initialization Ability to skip low level initialization if necessary. Many other platforms have a similar capability, and this is quite useful during debug/bring-up. 3. U-Boot code relocation support Most architectures allow u-boot code to run initially at a different address (possibly in NOR) and then get relocated to its final resting place in RAM. Added support for this capability in ARM1176 architecture. 4. Disable TCM if necessary If a ROM based bootloader happened to have initialized TCM, we disable it here to keep things sane. 5. Remove unnecessary SoC specific includes ARM1176 code does not really need this SoC specific include. The presence of this include prevents builds on other ARM1176 archs. 6. ARM926 style MMU disable when !CONFIG_ENABLE_MMU The original MMU disable code masks out too many bits from the load address when it tries to figure out the physical address of the jump target label. Consequently, it ends up branching to the wrong address after disabling the MMU. Signed-off-by: Cyril Chemparathy cy...@ti.com --- Unchanged from v1 cpu/arm1176/cpu.c |1 - cpu/arm1176/start.S| 60 ++-- include/configs/smdk6400.h |6 3 files changed, 58 insertions(+), 9 deletions(-) diff --git a/cpu/arm1176/cpu.c b/cpu/arm1176/cpu.c index 2c0014f..c0fd114 100644 --- a/cpu/arm1176/cpu.c +++ b/cpu/arm1176/cpu.c @@ -33,7 +33,6 @@ #include common.h #include command.h -#include asm/arch/s3c6400.h #include asm/system.h static void cache_flush (void); diff --git a/cpu/arm1176/start.S b/cpu/arm1176/start.S index 68a356d..beec574 100644 --- a/cpu/arm1176/start.S +++ b/cpu/arm1176/start.S @@ -1,5 +1,5 @@ /* - * armboot - Startup Code for S3C6400/ARM1176 CPU-core + * armboot - Startup Code for ARM1176 CPU-core * * Copyright (c) 2007 Samsung Electronics * @@ -35,7 +35,6 @@ #ifdef CONFIG_ENABLE_MMU #include asm/proc/domain.h #endif -#include asm/arch/s3c6400.h #if !defined(CONFIG_ENABLE_MMU) !defined(CONFIG_SYS_PHY_UBOOT_BASE) #define CONFIG_SYS_PHY_UBOOT_BASE CONFIG_SYS_UBOOT_BASE @@ -145,6 +144,7 @@ reset: * * */ +#ifndef CONFIG_SKIP_LOWLEVEL_INIT /* * we do sys-critical inits only at reboot, * not when booting from ram! @@ -170,6 +170,8 @@ cpu_init_crit: bic r0, r0, #0x0087 @ clear bits 7, 2:0 (B--- -CAM) orr r0, r0, #0x0002 @ set bit 2 (A) Align orr r0, r0, #0x1000 @ set bit 12 (I) I-Cache + +#ifdef CONFIG_ENABLE_MMU /* Prepare to disable the MMU */ adr r1, mmu_disable_phys /* We presume we're within the first 1024 bytes */ @@ -187,20 +189,60 @@ mmu_disable: nop nop mov pc, r2 +mmu_disable_phys: +#else + mcr p15, 0, r0, c1, c0, 0 #endif -mmu_disable_phys: +#ifdef CONFIG_DISABLE_TCM + /* +* Disable the TCMs +*/ + mrc p15, 0, r0, c0, c0, 2 /* Return TCM details */ + cmp r0, #0 + beq skip_tcmdisable + mov r1, #0 + mov r2, #1 + tst r0, r2 + mcrne p15, 0, r1, c9, c1, 1 /* Disable Instruction TCM if present*/ + tst r0, r2, LSL #16 + mcrne p15, 0, r1, c9, c1, 0 /* Disable Data TCM if present*/ +skip_tcmdisable: +#endif +#endif + +#ifdef CONFIG_PERIPORT_REMAP /* Peri port setup */ - ldr r0, =0x7000 - orr r0, r0, #0x13 + ldr r0, =CONFIG_PERIPORT_BASE + orr r0, r0, #CONFIG_PERIPORT_SIZE mcr p15,0,r0,c15,c2,4 @ 256M (0x7000 - 0x7fff) +#endif /* * Go setup Memory and board specific bits prior to relocation. */ bl lowlevel_init /* go setup pll,mux,memory */ +#endif /* CONFIG_SKIP_LOWLEVEL_INIT */ + +#ifndef CONFIG_SKIP_RELOCATE_UBOOT +relocate: /* relocate U-Boot to RAM */ + adr r0, _start /* r0 - current position of code */ + ldr r1, _TEXT_BASE /* test if we run from flash or RAM */ + cmp r0, r1 /* don't reloc during debug */ + beq stack_setup + + ldr r2, _armboot_start + ldr r3, _bss_start + sub r2, r3, r2 /* r2 - size of armboot*/ + add r2, r0, r2
[U-Boot] [PATCH v2 0/3] TI: tnetv107x patch series
TNETV107X is a Texas Instruments SoC based on an ARM1176 core, and with a bunch on on-chip integrated peripherals. This patch series generalizes current ARM1176 code to allow for the addition of new ARM1176 SOCs. The remaining patches in this series add arch and board support. The contents of this series are identical to the larger patch posted earlier. The only difference here is that these changes have been split up as per feedback from Sandeep. Cyril Chemparathy (3): ARM1176: Coexist with other ARM1176 platforms ARM1176: TI: TNETV107X soc initial support TI: TNETV107X EVM initial support MAINTAINERS|4 + MAKEALL|1 + Makefile |3 + board/ti/tnetv107xevm/Makefile | 49 +++ board/ti/tnetv107xevm/config.mk| 20 + board/ti/tnetv107xevm/sdb_board.c | 66 cpu/arm1176/cpu.c |1 - cpu/arm1176/start.S| 60 +++- cpu/arm1176/tnetv107x/Makefile | 44 +++ cpu/arm1176/tnetv107x/aemif.c | 151 cpu/arm1176/tnetv107x/clock.c | 542 cpu/arm1176/tnetv107x/init.c | 41 ++ cpu/arm1176/tnetv107x/lowlevel_init.S | 25 ++ cpu/arm1176/tnetv107x/mux.c| 463 cpu/arm1176/tnetv107x/timer.c | 125 +++ cpu/arm1176/tnetv107x/wdt.c| 172 + include/asm-arm/arch-tnetv107x/clock.h | 50 +++ include/asm-arm/arch-tnetv107x/emif_defs.h |1 + include/asm-arm/arch-tnetv107x/hardware.h | 184 ++ include/asm-arm/arch-tnetv107x/mux.h | 307 include/asm-arm/arch-tnetv107x/nand_defs.h | 38 ++ include/configs/smdk6400.h |6 + include/configs/tnetv107x_evm.h| 206 +++ 23 files changed, 2550 insertions(+), 9 deletions(-) create mode 100644 board/ti/tnetv107xevm/Makefile create mode 100644 board/ti/tnetv107xevm/config.mk create mode 100644 board/ti/tnetv107xevm/sdb_board.c create mode 100644 cpu/arm1176/tnetv107x/Makefile create mode 100644 cpu/arm1176/tnetv107x/aemif.c create mode 100644 cpu/arm1176/tnetv107x/clock.c create mode 100644 cpu/arm1176/tnetv107x/init.c create mode 100644 cpu/arm1176/tnetv107x/lowlevel_init.S create mode 100644 cpu/arm1176/tnetv107x/mux.c create mode 100644 cpu/arm1176/tnetv107x/timer.c create mode 100644 cpu/arm1176/tnetv107x/wdt.c create mode 100644 include/asm-arm/arch-tnetv107x/clock.h create mode 100644 include/asm-arm/arch-tnetv107x/emif_defs.h create mode 100644 include/asm-arm/arch-tnetv107x/hardware.h create mode 100644 include/asm-arm/arch-tnetv107x/mux.h create mode 100644 include/asm-arm/arch-tnetv107x/nand_defs.h create mode 100644 include/configs/tnetv107x_evm.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] TI: TNETV107X EVM initial support
TNETV107X is a Texas Instruments SoC based on an ARM1176 core, and with a bunch on on-chip integrated peripherals. This patch adds support for the TNETV107X EVM board. Signed-off-by: Cyril Chemparathy cy...@ti.com --- 1. Added maintainers entry 2. Fixed sort order in main makefile 3. Remove board specific linker script 4. Style fixes - multiline comments 5. Replaced clk_get() with clk_get_rate() MAINTAINERS |4 + MAKEALL |1 + Makefile |3 + board/ti/tnetv107xevm/Makefile| 49 + board/ti/tnetv107xevm/config.mk | 20 board/ti/tnetv107xevm/sdb_board.c | 66 include/configs/tnetv107x_evm.h | 206 + 7 files changed, 349 insertions(+), 0 deletions(-) create mode 100644 board/ti/tnetv107xevm/Makefile create mode 100644 board/ti/tnetv107xevm/config.mk create mode 100644 board/ti/tnetv107xevm/sdb_board.c create mode 100644 include/configs/tnetv107x_evm.h diff --git a/MAINTAINERS b/MAINTAINERS index bb03f17..daa074c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -62,6 +62,10 @@ Oliver Brown obr...@adventnetworks.com gw8260 MPC8260 +Cyril Chemparathy cy...@ti.com + + tnetv107x_evm tnetv107x + Conn Clark cl...@esteem.com ESTEEM192E MPC8xx diff --git a/MAKEALL b/MAKEALL index a88c31e..63d8d16 100755 --- a/MAKEALL +++ b/MAKEALL @@ -623,6 +623,7 @@ LIST_ARM11=\ mx31pdk_nand\ qong\ smdk6400\ + tnetv107x_evm \ # diff --git a/Makefile b/Makefile index c0e73de..0e509d0 100644 --- a/Makefile +++ b/Makefile @@ -3313,6 +3313,9 @@ smdk6400_config : unconfig fi @echo CONFIG_NAND_U_BOOT = y $(obj)include/config.mk +tnetv107x_evm_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm1176 tnetv107xevm ti tnetv107x + # # i386 # diff --git a/board/ti/tnetv107xevm/Makefile b/board/ti/tnetv107xevm/Makefile new file mode 100644 index 000..2446c2a --- /dev/null +++ b/board/ti/tnetv107xevm/Makefile @@ -0,0 +1,49 @@ +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS += sdb_board.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +.PHONY: all + +all: $(LIB) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak *~ .depend + +# +# This is for $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/ti/tnetv107xevm/config.mk b/board/ti/tnetv107xevm/config.mk new file mode 100644 index 000..d24d49a --- /dev/null +++ b/board/ti/tnetv107xevm/config.mk @@ -0,0 +1,20 @@ +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +# + +TEXT_BASE = 0x83FC diff --git a/board/ti/tnetv107xevm/sdb_board.c b/board/ti/tnetv107xevm/sdb_board.c new file mode 100644 index
Re: [U-Boot] Booting from ext2/ext3
Dear Matthias, In message 569685f045b85741820d0265e0d2999d019cf...@tddhh01.hh.thales-naval.de you wrote: I miss some compile-switch, or do I have to explicitly include ext2fs.h somewhere? How can I enable the ext2/ext3 functionality? This depends on CONFIG_CMD_EXT2 Thanks, I added this along with CONFIG_DOS_PARTITION to my board configuration file - which so far is a copy of the MPC8568MDS.h During the final linking I get the following errors: common/libcommon.a(cmd_ext2.o): In function `do_ext2load': u-boot-2009.11.1/common/cmd_ext2.c:193: undefined reference to `get_partition_info' ... What's the issue here? Hm... this is U-Boot release v2009.11.1, correct? In your log you can see that the relevant source file, disk/part.c, gets compiled: ... 219 make -C disk/ 220 make[1]: Entering directory `u-boot-2009.11.1/disk' 221 ppc_85xx-gcc -g -Os -mrelocatable -fPIC -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfff8 -Iu-boot-2009.11.1/include -fno-builtin -ffreestanding -nostdinc -isystem /data/opt/eldk/usr/bin/../lib/gcc/powerpc-linux/4.2.2/include -pipe -DCONFIG_PPC -D__powerpc__ -ffixed-r2 -Wa,-me500 -msoft-float -mno-string -mspe=yes -mno-spe -Wall -Wstrict-prototypes -fno-stack-protector -o part.o part.c -c ... Try running nm on the object file; you should see something like this: - ppc_85xx-nm disk/part.o d block_drvr 00dc T dev_print 031c T get_dev 02a0 T get_partition_info U get_partition_info_dos 02dc T init_part 0004 T print_part U print_part_dos U printf U puts U scsi_get_dev U strlen U strncmp U test_part_dos In my test get_partition_info gets defined as Text symbol as needed. What do you get? 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 all seemed, he thought, to be rather a lot of trouble to go to just sharpen a razor blade. - Terry Pratchett, _The Light Fantastic_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] net, fec_mxc: only setup the device enetaddr with eeprom value, if ethaddr is not setup
On Wednesday 31 March 2010 10:46:25 Detlev Zundel wrote: I fully agree. Previously I was under the impression that we already have a fast initialization (probe) and a full initialization (init) of the network interfaces, where programming the mac would (on a first stab) fit into the probe part (and some drivers obviously do/did this). In the meantime it seems like it is a broader problem of keeping ethaddr and friends in sync with the real hardware. Although this is something I personally always took for granted, it currently is most of the time but not always correct. If we solve the latter problem in a nice way, the initial problem will simply disappear (or so I hope) ;) the latter problem is already solved in the general case. the first initialize path gets the hw mac address and gives it to the common layers. common layers take care of keeping the structures in sync. when the slow init path gets called to actually bring up the hardware, the mac has already been synced to the structures. correctly written devices never have to care about anything other than dev-enetaddr and should not be programming the MAC with the MAC address in the fast initialize path. really what you want is a new eth entry point like eth_write_mac() that goes through the common layers and programs the MAC with the MAC address. this isnt a problem with the current net framework. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] net, fec_mxc: only setup the device enetaddr with eeprom value, if ethaddr is not setup
Hi Mike, On 3/31/2010 12:59 PM, Mike Frysinger wrote: On Wednesday 31 March 2010 10:46:25 Detlev Zundel wrote: I fully agree. Previously I was under the impression that we already have a fast initialization (probe) and a full initialization (init) of the network interfaces, where programming the mac would (on a first stab) fit into the probe part (and some drivers obviously do/did this). In the meantime it seems like it is a broader problem of keeping ethaddr and friends in sync with the real hardware. Although this is something I personally always took for granted, it currently is most of the time but not always correct. If we solve the latter problem in a nice way, the initial problem will simply disappear (or so I hope) ;) the latter problem is already solved in the general case. the first initialize path gets the hw mac address and gives it to the common layers. common layers take care of keeping the structures in sync. when the slow init path gets called to actually bring up the hardware, the mac has already been synced to the structures. correctly written devices never have to care about anything other than dev-enetaddr and should not be programming the MAC with the MAC address in the fast initialize path. really what you want is a new eth entry point like eth_write_mac() that goes through the common layers and programs the MAC with the MAC address. this isnt a problem with the current net framework. Detlev and I were just talking off-list about exactly that. I guess 'great minds think alike', as my grandma used to say. -mike regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] 30-Second TFTP Timeout at Start-Up
Hi All,
I'm seeing a strange TFTP issue and hoping someone on the list can help.
I'm running a Sequoia reference board and at start-up my TFTP transfer
always times out for 30 seconds, then proceeds without error or
further issue.
I ran Wireshark on my TFTP server, and also performed a port mirror of
the Sequoia board. I can confirm TFTP requests are only initiated 30
seconds after tftpboot is run.
Running with a static IP and the latest RC2 release of U-Boot. Boot
command is as follows:
net_nfs_fdt=tftp 20 ${bootfile};tftp ${fdt_addr} ${fdt_file};run
nfsargs addip addtty;bootm 20 - ${fdt_addr}
Startup log always looks the same...
U-Boot 2010.03-rc2-00011-gc0bf2cf-dirty (Mar 30 2010 - 20:10:06)
CPU: AMCC PowerPC 440EPx Rev. A at 666.667 MHz (PLB=166 OPB=83
EBC=55 PCI=83 MHz)
Security/Kasumi support
Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
Internal PCI arbiter enabled, PCI async ext clock used
32 kB I-Cache 32 kB D-Cache
Board: Sequoia - AMCC PPC440EPx Evaluation Board, Rev. F, PCI-Async=66 MHz
I2C: ready
DRAM: 256 MB
FLASH: 64 MB
NAND: 32 MiB
PCI: Bus Dev VenId DevId Class Int
USB: Host(int phy) Device(ext phy)
DTT: 1 is 38 C
Net: ppc_4xx_eth0, ppc_4xx_eth1
Type run net_nfs_fdt to load via TFTP and mount root via NFS
Hit any key to stop autoboot: 0
Waiting for PHY auto negotiation to complete... done
ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)
Using ppc_4xx_eth0 device
TFTP from server X.X.X.X; our IP address is X.X.X.Y
Filename 'sequoia/uImage'.
Load address: 0x20
Loading: T T T T T T
#
done
Bytes transferred = 1528036 (1750e4 hex)
Using ppc_4xx_eth0 device
TFTP from server X.X.X.X; our IP address is X.X.X.Y
Filename 'sequoia/sequoia.dtb'.
Load address: 0x100
Loading: #
done
Bytes transferred = 8669 (21dd hex)
I think this has always been happening, even with older versions of
U-Boot. I finally got annoyed enough with this problem to dig a little
further.
:-)
Thanks,
-jmh
Jason Hanna
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] ati_radeon: Support PCI virtual not eq bus mapping.
Use pci_bus_to_virt() to convert the bus address from the BARs to
virtual address' to eliminate the direct mapping requirement.
Rename variables to better match usage (_phys - _bus or no-suffix)
This fixes the mpc8572ds CONFIG_PHYS_64BIT mode failure:
videoboot: Video ROM failed to map!
Tested on mpc8572ds with and without CONFIG_PHYS_64BIT.
Signed-off-by: Ed Swarthout ed.swarth...@freescale.com
---
V2:
Fix typos and warnings as pointed out by Anatolij Gustschin. -thanks
Fixed checkpatch error:
ERROR: do not use assignment in if condition
#41: FILE: drivers/bios_emulator/atibios.c:198:
+ if ((BIOSImageBus = PCI_findBIOSAddr(pcidev, BIOSImageBAR)) == 0) {
drivers/bios_emulator/atibios.c | 10 +---
drivers/video/ati_radeon_fb.c | 47 --
drivers/video/ati_radeon_fb.h |4 +-
3 files changed, 33 insertions(+), 28 deletions(-)
diff --git a/drivers/bios_emulator/atibios.c b/drivers/bios_emulator/atibios.c
index 2881449..dbb5e8c 100644
--- a/drivers/bios_emulator/atibios.c
+++ b/drivers/bios_emulator/atibios.c
@@ -173,7 +173,7 @@ Maps a pointer to the BIOS image on the graphics card on
the PCI bus.
/
void *PCI_mapBIOSImage(pci_dev_t pcidev)
{
- u32 BIOSImagePhys;
+ u32 BIOSImageBus;
int BIOSImageBAR;
u8 *BIOSImage;
@@ -195,16 +195,18 @@ void *PCI_mapBIOSImage(pci_dev_t pcidev)
specific programming for different cards to solve this problem.
*/
- if ((BIOSImagePhys = PCI_findBIOSAddr(pcidev, BIOSImageBAR)) == 0) {
+ BIOSImageBus = PCI_findBIOSAddr(pcidev, BIOSImageBAR);
+ if (BIOSImageBus == 0) {
printf(Find bios addr error\n);
return NULL;
}
- BIOSImage = (u8 *) BIOSImagePhys;
+ BIOSImage = pci_bus_to_virt(pcidev, BIOSImageBus,
+ PCI_REGION_MEM, 0, MAP_NOCACHE);
/*Change the PCI BAR registers to map it onto the bus.*/
pci_write_config_dword(pcidev, BIOSImageBAR, 0);
- pci_write_config_dword(pcidev, PCI_ROM_ADDRESS, BIOSImagePhys | 0x1);
+ pci_write_config_dword(pcidev, PCI_ROM_ADDRESS, BIOSImageBus | 0x1);
udelay(1);
diff --git a/drivers/video/ati_radeon_fb.c b/drivers/video/ati_radeon_fb.c
index 529ddae..f797104 100644
--- a/drivers/video/ati_radeon_fb.c
+++ b/drivers/video/ati_radeon_fb.c
@@ -210,7 +210,7 @@ static void radeon_identify_vram(struct radeonfb_info
*rinfo)
* ToDo: identify these cases
*/
- DPRINT(radeonfb: Found %ldk of %s %d bits wide videoram\n,
+ DPRINT(radeonfb: Found %dk of %s %d bits wide videoram\n,
rinfo-video_ram / 1024,
rinfo-vram_ddr ? DDR : SDRAM,
rinfo-vram_width);
@@ -586,14 +586,16 @@ int radeon_probe(struct radeonfb_info *rinfo)
rinfo-pdev.device = did;
rinfo-family = get_radeon_id_family(rinfo-pdev.device);
pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0,
- rinfo-fb_base_phys);
+ rinfo-fb_base_bus);
pci_read_config_dword(pdev, PCI_BASE_ADDRESS_2,
- rinfo-mmio_base_phys);
- rinfo-fb_base_phys = 0xf000;
- rinfo-mmio_base_phys = ~0x04;
-
- rinfo-mmio_base = (void *)rinfo-mmio_base_phys;
- DPRINT(rinfo-mmio_base = 0x%x\n,rinfo-mmio_base);
+ rinfo-mmio_base_bus);
+ rinfo-fb_base_bus = 0xf000;
+ rinfo-mmio_base_bus = ~0x04;
+
+ rinfo-mmio_base = pci_bus_to_virt(pdev, rinfo-mmio_base_bus,
+ PCI_REGION_MEM, 0, MAP_NOCACHE);
+ DPRINT(rinfo-mmio_base = 0x%x bus=0x%x\n,
+ rinfo-mmio_base, rinfo-mmio_base_bus);
rinfo-fb_local_base = INREG(MC_FB_LOCATION) 16;
DPRINT(rinfo-fb_local_base = 0x%x\n,rinfo-fb_local_base);
/* PostBIOS with x86 emulater */
@@ -611,14 +613,15 @@ int radeon_probe(struct radeonfb_info *rinfo)
rinfo-mapped_vram = min_t(unsigned long, MAX_MAPPED_VRAM,
rinfo-video_ram);
- rinfo-fb_base = (void *)rinfo-fb_base_phys;
-
- DPRINT(Radeon: framebuffer base phy address 0x%08x, \
- MMIO base phy address 0x%08x, \
- framebuffer local base 0x%08x.\n ,
- rinfo-fb_base_phys, rinfo-mmio_base_phys,
- rinfo-fb_local_base);
-
+ rinfo-fb_base = pci_bus_to_virt(pdev, rinfo-fb_base_bus,
+ PCI_REGION_MEM, 0, MAP_NOCACHE);
+ DPRINT(Radeon: framebuffer base address 0x%08x,
+ bus address 0x%08x\n
+ MMIO base
Re: [U-Boot] 30-Second TFTP Timeout at Start-Up
Are you connected directly to the tftp server or is there switches in between?
Feng Kan
On 03/31/2010 01:09 PM, Jason Hanna wrote:
Hi All,
I'm seeing a strange TFTP issue and hoping someone on the list can help.
I'm running a Sequoia reference board and at start-up my TFTP transfer
always times out for 30 seconds, then proceeds without error or
further issue.
I ran Wireshark on my TFTP server, and also performed a port mirror of
the Sequoia board. I can confirm TFTP requests are only initiated 30
seconds after tftpboot is run.
Running with a static IP and the latest RC2 release of U-Boot. Boot
command is as follows:
net_nfs_fdt=tftp 20 ${bootfile};tftp ${fdt_addr} ${fdt_file};run
nfsargs addip addtty;bootm 20 - ${fdt_addr}
Startup log always looks the same...
U-Boot 2010.03-rc2-00011-gc0bf2cf-dirty (Mar 30 2010 - 20:10:06)
CPU: AMCC PowerPC 440EPx Rev. A at 666.667 MHz (PLB=166 OPB=83
EBC=55 PCI=83 MHz)
Security/Kasumi support
Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
Internal PCI arbiter enabled, PCI async ext clock used
32 kB I-Cache 32 kB D-Cache
Board: Sequoia - AMCC PPC440EPx Evaluation Board, Rev. F, PCI-Async=66 MHz
I2C: ready
DRAM: 256 MB
FLASH: 64 MB
NAND: 32 MiB
PCI: Bus Dev VenId DevId Class Int
USB: Host(int phy) Device(ext phy)
DTT: 1 is 38 C
Net: ppc_4xx_eth0, ppc_4xx_eth1
Type run net_nfs_fdt to load via TFTP and mount root via NFS
Hit any key to stop autoboot: 0
Waiting for PHY auto negotiation to complete... done
ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)
Using ppc_4xx_eth0 device
TFTP from server X.X.X.X; our IP address is X.X.X.Y
Filename 'sequoia/uImage'.
Load address: 0x20
Loading: T T T T T T
#
done
Bytes transferred = 1528036 (1750e4 hex)
Using ppc_4xx_eth0 device
TFTP from server X.X.X.X; our IP address is X.X.X.Y
Filename 'sequoia/sequoia.dtb'.
Load address: 0x100
Loading: #
done
Bytes transferred = 8669 (21dd hex)
I think this has always been happening, even with older versions of
U-Boot. I finally got annoyed enough with this problem to dig a little
further.
:-)
Thanks,
-jmh
Jason Hanna
___
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] 30-Second TFTP Timeout at Start-Up
Are you connected directly to the tftp server or is there switches in between? I'm running a Cisco/Linksys SLM2024 24-port switch. The embedded board and TFTP server are on the same subnet and VLAN, however. That's how I enabled the port mirroring so that I could watch traffic on the Sequoia interface. Does that help? -jmh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 30-Second TFTP Timeout at Start-Up
Dear Jason Hanna, In message j2u8f9e78f01003311309g55c49db8kaa9a466002c8d...@mail.gmail.com you wrote: I'm seeing a strange TFTP issue and hoping someone on the list can help. I'm running a Sequoia reference board and at start-up my TFTP transfer always times out for 30 seconds, then proceeds without error or further issue. I ran Wireshark on my TFTP server, and also performed a port mirror of the Sequoia board. I can confirm TFTP requests are only initiated 30 seconds after tftpboot is run. And what did you see before that? For example, when was the ARP request sent, and how many of them? When were replies sent? Do you have any information when the link on tyour switch was established? Is there any chance that you have duplicated MAC and/or IP addresses on your network? Are you using STP etc. on your switches? Can you read out the error statistics for the respective ports on your switch? 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 GUIs are virtually useless. Learn tools. They're configurable, scriptable, automatable, cron-able, interoperable, etc. We don't need no brain-dead winslurping monolithic claptrap. -- Tom Christiansen in 37114...@csnews ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v2] fsl: improve the PIXIS code and fix a few bugs
Refactor and document the Freescale PIXIS code, used on most 85xx and 86xx
boards. This makes the code easier to read and more flexible.
Delete pixis.h, because none of the exported functions were actually being
used by any other file. Make all of the functions in pixis.c 'static'.
Remove #include pixis.h from every file that has it.
Remove some unnecessary #includes.
Make 'pixis_base' into a macro, so that we don't need to define it in every
function.
Add while(1); loops at the end of functions that reset the board, so that
execution doesn't continue while the reset is in progress.
Replace in_8/out_8 calls with clrbits_8, setbits_8, or clrsetbits_8, where
appropriate.
Replace ulong/uint with their spelled-out equivalents. Remove unnecessary
typecasts, changing the types of some variables if necessary.
Add CONFIG_SYS_PIXIS_VCFGEN0_ENABLE and CONFIG_SYS_PIXIS_VBOOT_ENABLE to make
it easier for specific boards to support variations in the PIXIS registers
sets. No current boards appears to need this feature.
Fix the definition of CONFIG_SYS_PIXIS_VBOOT_MASK for the MPC8610 HPCD.
Apparently, pixis_reset altbank has never worked on this board.
Signed-off-by: Timur Tabi ti...@freescale.com
---
board/freescale/common/pixis.c| 254 -
board/freescale/common/pixis.h| 31 ---
board/freescale/mpc8536ds/mpc8536ds.c |1 -
board/freescale/mpc8544ds/mpc8544ds.c |1 -
board/freescale/mpc8572ds/mpc8572ds.c |1 -
board/freescale/mpc8610hpcd/mpc8610hpcd.c |2 -
board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c |1 -
board/freescale/mpc8641hpcn/mpc8641hpcn.c |2 -
board/freescale/p2020ds/p2020ds.c |1 -
cpu/mpc512x/diu.c |1 -
include/configs/MPC8610HPCD.h |2 +-
11 files changed, 127 insertions(+), 170 deletions(-)
delete mode 100644 board/freescale/common/pixis.h
diff --git a/board/freescale/common/pixis.c b/board/freescale/common/pixis.c
index 7210512..119eaf9 100644
--- a/board/freescale/common/pixis.c
+++ b/board/freescale/common/pixis.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2006 Freescale Semiconductor
+ * Copyright 2006,2010 Freescale Semiconductor
* Jeff Brown
* Srikanth Srinivasan (srikanth.sriniva...@freescale.com)
*
@@ -24,33 +24,26 @@
#include common.h
#include command.h
-#include watchdog.h
-#include asm/cache.h
#include asm/io.h
-#include pixis.h
-
-
-static ulong strfractoint(uchar *strptr);
-
+#define pixis_base (u8 *)PIXIS_BASE
/*
* Simple board reset.
*/
void pixis_reset(void)
{
- u8 *pixis_base = (u8 *)PIXIS_BASE;
out_8(pixis_base + PIXIS_RST, 0);
-}
+ while (1);
+}
/*
* Per table 27, page 58 of MPC8641HPCN spec.
*/
-int set_px_sysclk(ulong sysclk)
+static int set_px_sysclk(unsigned long sysclk)
{
u8 sysclk_s, sysclk_r, sysclk_v, vclkh, vclkl, sysclk_aux;
- u8 *pixis_base = (u8 *)PIXIS_BASE;
switch (sysclk) {
case 33:
@@ -117,13 +110,13 @@ int set_px_sysclk(ulong sysclk)
return 1;
}
-
-int set_px_mpxpll(ulong mpxpll)
+/* Set the CFG_SYSPLL bits
+ *
+ * This only has effect if PX_VCFGEN0[SYSPLL]=1, which is true if
+ * read_from_px_regs() is called.
+ */
+static int set_px_mpxpll(unsigned long mpxpll)
{
- u8 tmp;
- u8 val;
- u8 *pixis_base = (u8 *)PIXIS_BASE;
-
switch (mpxpll) {
case 2:
case 4:
@@ -133,28 +126,19 @@ int set_px_mpxpll(ulong mpxpll)
case 12:
case 14:
case 16:
- val = (u8) mpxpll;
- break;
- default:
- printf(Unsupported MPXPLL ratio.\n);
- return 0;
+ clrsetbits_8(pixis_base + PIXIS_VSPEED1, 0x1F, mpxpll);
+ return 1;
}
- tmp = in_8(pixis_base + PIXIS_VSPEED1);
- tmp = (tmp 0xF0) | (val 0x0F);
- out_8(pixis_base + PIXIS_VSPEED1, tmp);
-
- return 1;
+ printf(Unsupported MPXPLL ratio.\n);
+ return 0;
}
-
-int set_px_corepll(ulong corepll)
+static int set_px_corepll(unsigned long corepll)
{
- u8 tmp;
u8 val;
- u8 *pixis_base = (u8 *)PIXIS_BASE;
- switch ((int)corepll) {
+ switch (corepll) {
case 20:
val = 0x08;
break;
@@ -178,113 +162,132 @@ int set_px_corepll(ulong corepll)
return 0;
}
- tmp = in_8(pixis_base + PIXIS_VSPEED0);
- tmp = (tmp 0xE0) | (val 0x1F);
- out_8(pixis_base + PIXIS_VSPEED0, tmp);
-
+ clrsetbits_8(pixis_base + PIXIS_VSPEED0, 0x1F, val);
return 1;
}
+#ifndef CONFIG_SYS_PIXIS_VCFGEN0_ENABLE
+#define CONFIG_SYS_PIXIS_VCFGEN0_ENABLE0x1C
+#endif
-void read_from_px_regs(int set)
+/* Tell the PIXIS where to find the COREPLL, MPXPLL, SYSCLK values
+ *
+ * The PIXIS can be programmed to look at either the on-board dip switches
+ * or various other
[U-Boot] [PATCH] cfi_flash: reset timer in flash status check
This patch adds reset_timer() before the flash status check
waiting loop.
Since the timer is basically running asynchronous to the cfi
code, it is possible to call get_timer(0), then only a few
_SYSCLK_ cycles later an interrupt is generated. This causes
timeout even though much less time has elapsed. So the timer
period registers should be reset before get_timer(0) is
called.
There is similar usage in nand_base.c.
Signed-off-by: Thomas Chou tho...@wytron.com.tw
---
drivers/mtd/cfi_flash.c |2 ++
include/configs/EP3C120.h | 10 +-
include/configs/NEEK.h| 10 +-
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index aae93bd..99300ba 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -544,6 +544,7 @@ static int flash_status_check (flash_info_t * info,
flash_sect_t sector,
#endif
/* Wait for command completion */
+ reset_timer();
start = get_timer (0);
while (flash_is_busy (info, sector)) {
if (get_timer (start) tout) {
@@ -630,6 +631,7 @@ static int flash_status_poll(flash_info_t *info, void *src,
void *dst,
#endif
/* Wait for command completion */
+ reset_timer();
start = get_timer(0);
while (1) {
switch (info-portwidth) {
diff --git a/include/configs/EP3C120.h b/include/configs/EP3C120.h
index cfd5569..6734a65 100644
--- a/include/configs/EP3C120.h
+++ b/include/configs/EP3C120.h
@@ -152,10 +152,10 @@
*/
#define CONFIG_SYS_NIOS_TMRBASE(LINUX_TIMER_1MS_BASE | IO_REGION_BASE)
#define CONFIG_SYS_NIOS_TMRIRQ LINUX_TIMER_1MS_IRQ
-#define CONFIG_SYS_NIOS_TMRCNT ((LINUX_TIMER_1MS_FREQ / \
- CONFIG_SYS_HZ) - 1)
-#define CONFIG_SYS_NIOS_TMRMS 1 /* Must be one */
-#define CONFIG_SYS_HZ 1000
+#define CONFIG_SYS_HZ 1000/* Always 1000 */
+#define CONFIG_SYS_NIOS_TMRMS 10 /* Desired period (msec)*/
+#define CONFIG_SYS_NIOS_TMRCNT \
+ (CONFIG_SYS_NIOS_TMRMS * (LINUX_TIMER_1MS_FREQ / 1000) - 1)
/*
* STATUS LED
@@ -167,7 +167,7 @@
#define STATUS_LED_BIT 1 /* Bit-0 on PIO */
#define STATUS_LED_STATE 1 /* Blinking */
-#define STATUS_LED_PERIOD (CONFIG_SYS_HZ / 2) /* 500 mS */
+#define STATUS_LED_PERIOD (500 / CONFIG_SYS_NIOS_TMRMS) /* 500 msec */
/*
* IDE support
diff --git a/include/configs/NEEK.h b/include/configs/NEEK.h
index f42701e..432a582 100644
--- a/include/configs/NEEK.h
+++ b/include/configs/NEEK.h
@@ -149,10 +149,10 @@
*/
#define CONFIG_SYS_NIOS_TMRBASE(SYS_CLK_TIMER_BASE | IO_REGION_BASE)
#define CONFIG_SYS_NIOS_TMRIRQ SYS_CLK_TIMER_IRQ
-#define CONFIG_SYS_NIOS_TMRCNT ((SYS_CLK_TIMER_FREQ / \
- CONFIG_SYS_HZ) - 1)
-#define CONFIG_SYS_NIOS_TMRMS 1 /* Must be one */
-#define CONFIG_SYS_HZ 1000
+#define CONFIG_SYS_HZ 1000/* Always 1000 */
+#define CONFIG_SYS_NIOS_TMRMS 10 /* Desired period (msec)*/
+#define CONFIG_SYS_NIOS_TMRCNT \
+ (CONFIG_SYS_NIOS_TMRMS * (SYS_CLK_TIMER_FREQ / 1000) - 1)
/*
* STATUS LED
@@ -162,7 +162,7 @@
#define STATUS_LED_BIT CONFIG_SYS_GPIO_HBT
#define STATUS_LED_STATE 1 /* Blinking */
-#define STATUS_LED_PERIOD (CONFIG_SYS_HZ / 2) /* 500 mS */
+#define STATUS_LED_PERIOD (500 / CONFIG_SYS_NIOS_TMRMS) /* 500 msec */
/*
* IDE support
--
1.6.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] cfi_flash: reset timer in flash status check
This patch adds reset_timer() before the flash status check
waiting loop.
Since the timer is basically running asynchronous to the cfi
code, it is possible to call get_timer(0), then only a few
_SYSCLK_ cycles later an interrupt is generated. This causes
timeout even though much less time has elapsed. So the timer
period registers should be reset before get_timer(0) is
called.
There is similar usage in nand_base.c.
Signed-off-by: Thomas Chou tho...@wytron.com.tw
---
Please ignore the earlier patch, which messed up when I added comments.
drivers/mtd/cfi_flash.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index aae93bd..99300ba 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -544,6 +544,7 @@ static int flash_status_check (flash_info_t * info,
flash_sect_t sector,
#endif
/* Wait for command completion */
+ reset_timer();
start = get_timer (0);
while (flash_is_busy (info, sector)) {
if (get_timer (start) tout) {
@@ -630,6 +631,7 @@ static int flash_status_poll(flash_info_t *info, void *src,
void *dst,
#endif
/* Wait for command completion */
+ reset_timer();
start = get_timer(0);
while (1) {
switch (info-portwidth) {
--
1.6.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Saving environment variables in MMC
Thanks Detlev, --- On Wed, 31/3/10, Detlev Zundel d...@denx.de wrote: From: Detlev Zundel d...@denx.de Subject: Re: [U-Boot] Saving environment variables in MMC To: nitin...@yahoo.com Cc: U-Boot user list u-boot@lists.denx.de Date: Wednesday, 31 March, 2010, 8:04 PM Hi Nitin, Thanks for the information. I just wanted to have a feedback, whether having a use-case of writing env variables from Linux User space is a good idea or is not recommended? You found tools/env/fw_env.c showing that this functionality is indeed foreseen and used. It is rather common to write to the U-Boot environment in projects for example to switch to a new set of kernel+file system after an update from within linux for the next boot. My use case is exactly same, to switch to a new set of kernel+fs after an update for the next boot. I also have another usecase of updating the env variable 'bootargs' if required in the field. So this use-case combined with fw_env, what is your feedback? Could you give me some pointers on upgrading u-boot itself, but I don't have a spare partition for that. I would have to replace working copy itself? I would wanted to have more info(in addition to what I have implemented) regarding the failsafe upgrade mechanisms for embedded-linux apps and kernel? Could you please point me to right forums regarding this. I understand that this is not specific to u-boot, but just give me some pointers. regards -Nitin Is this feedback enough? Cheers Detlev -- The structure of a system reflects the structure of the organization that built it. -- Richard E. Fairley -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de Get your new Email address! Grab the Email name you#39;ve always wanted before someone else does! http://mail.promotions.yahoo.com/newdomains/aa/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] nios2: Reload timer count in reset_timer()
When the timestamp is incremented via interrupt and the interrupt
period is greater than 1 msec, successive calls to get_timer() can
produce inaccurate timing since the interrupts are asynchronous
to the timing loop. For example, with an interrupt period of 10 msec
two successive calls to get_timer() could indicate an elapsed time
of 10 msec after only several hundred usecs -- depending on when
the next interrupt actually occurs. This behavior can cause
reliability issues with components such as CFI and NAND.
This can be remedied by calling reset_timer() prior to establishing
the base timestamp with get_timer(0), provided reset_timer()
resets the hardware timer (rather than simply resetting only the
timestamp). This has the effect of synchronizing the interrupts
(and the advance of the timestamp) with the timing loop.
Signed-off-by: Scott McNutt smcn...@psyent.com
---
cpu/nios2/interrupts.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/cpu/nios2/interrupts.c b/cpu/nios2/interrupts.c
index 5c3b5e6..b552db4 100644
--- a/cpu/nios2/interrupts.c
+++ b/cpu/nios2/interrupts.c
@@ -56,7 +56,40 @@ volatile ulong timestamp = 0;
void reset_timer (void)
{
+ nios_timer_t *tmr =(nios_timer_t *)CONFIG_SYS_NIOS_TMRBASE;
+
+ /* From Embedded Peripherals Handbook:
+*
+* When the hardware is configured with Writeable period
+* disabled, writing to one of the period_n registers causes
+* the counter to reset to the fixed Timeout Period specified
+* at system generation time.
+*
+* Here we force a reload to prevent early timeouts from
+* get_timer() when the interrupt period is greater than
+* than 1 msec.
+*
+* Simply write to periodl with its own value to force an
+* internal counter reload, THEN reset the timestamp.
+*/
+ writel (readl (tmr-periodl), tmr-periodl);
timestamp = 0;
+
+ /* From Embedded Peripherals Handbook:
+*
+* Writing to one of the period_n registers stops the internal
+* counter, except when the hardware is configured with Start/Stop
+* control bits off. If Start/Stop control bits is off, writing
+* either register does not stop the counter.
+*
+* In order to accomodate either configuration, the control
+* register is re-written. If the counter is stopped, it will
+* be restarted. If it is running, the write is essentially
+* a nop.
+*/
+ writel (NIOS_TIMER_ITO | NIOS_TIMER_CONT | NIOS_TIMER_START,
+ tmr-control);
+
}
ulong get_timer (ulong base)
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot env variables parsing
Hi!
I am doing env settings some thing like this,
ROOT1=/dev/mmcblk0p1
ROOT2=/dev/mmcblk0p2
ROOT=${ROOT1}
bootargs1=console=ttyS0,115200n8 mem=256M noinitrd rw rootdelay=1 ${ROOT}
when I say 'setenv bootargs ${bootargs1}', ${ROOT} gets resolved to 'ROOT1', it
does not get completely resolved to '/dev/mmcblk0p1'.
Is there something fundamentally wrong in setting the env variables this way?
What would be the right way to achieve this, as I want ROOT to be ${ROOT1}
sometimes and ${ROOT2} some times?
regards
-Nitin
Get your preferred Email name!
Now you can @ymail.com and @rocketmail.com.
http://mail.promotions.yahoo.com/newdomains/aa/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
