Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
-Original Message- From: Scott Wood [mailto:scottw...@freescale.com] Sent: Tuesday, June 23, 2009 3:35 AM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver On Sun, Jun 14, 2009 at 10:32:47PM +0530, Prafulla Wadaskar wrote: diff --git a/drivers/mtd/nand/kirkwood_nand.c b/drivers/mtd/nand/kirkwood_nand.c new file mode 100644 index 000..9cdbe20 --- /dev/null +++ b/drivers/mtd/nand/kirkwood_nand.c @@ -0,0 +1,81 @@ +/* + * Copyright (C) Marvell International Ltd. and its affiliates No year? I will correct this. +#include common.h +#include asm/io.h +#include asm/arch/kirkwood.h +#include nand.h I don't see kirkwood.h in upstream, so I guess this should go via an arch tree. Kirkwood support is available in arm/next, I hope it will be pulled soon :-) Any way this is dependency for this driver but is this blocker? I have two options- 1. remove dependency from this patch or 2. get Basic Kirkwood support up streamed There are some other drivers in pipeline i.e. i2c,spi,usb that needs Basic Kirkwood support. So I wish to go for second option Hi Jean, Can you pls help to resolve this dependency? Please let me know your feedback on this issue ASAP so that I can release next spin Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Problem with uboot booting image
Hi All, I am trying to boot Linux from uboot. I have cross compiled Linux and ramdisk for my board. After cross compilation i did a tftp to download the image(Linux + Filesystem) to RAM(0x8080) . From there i copied it to flash(0xad04). Now on a reset u boot comes up and then when trying to bring LINUX it throws an error saying Verifying Checksum...Bad data CRC. Then uboot prompt appears. This is what happened. U-Boot 1.1.2 (Jun 10 2008 - 18:55:13) Board: MIPS CPU Speed 200 MHz DRAM: 16 MB sflash.c:266:DF_F_DataflashProbe: Entered sflash.c:269:DF_F_DataflashProbe: flash type is 0x1 sflash.c:270:DF_F_DataflashProbe: num pages 32768 DataFlash:Nb pages: 32768 Page Size:256 Size= 8388608 bytes Logical address: 0xAD00 Nb Erase Blocks:128 Erase Block Size: 65536 Area 0: AD00 to AD003FFF Area 1: AD004000 to AD03 Area 2: AD04 to AD30BFFF Area 3: AD30C000 to AD7F crc matched In:serial Out: serial Err: serial Net:Eth. Type run flash_nfs to mount root filesystem over NFS Hit any key to stop autoboot: 0 ### JFFS2 loading '/boot/uImage' to 0x8080 Scanning JFFS2 FS: done. ### JFFS2 load complete: 3249008 bytes loaded to 0x8080 ## Booting image at 8080 ... Image Name: Linux Kernel Image with ramdisk. Created: 2009-06-22 4:37:12 UTC Image Type: MIPS Linux Kernel Image (gzip compressed) Data Size:3248944 Bytes = 3.1 MB Load Address: 8010 Entry Point: 80578000 Verifying Checksum ... Bad Data CRC UBOOT UBOOT # printenv bootargs=console=ttyS0,38400 nofpu mem=14M root=/dev/ram0 rw bootcmd=fsload 0x8080 /boot/uImage; bootm 0x8080 bootdelay=5 baudrate=38400 ethaddr=00:06:0D:00:00:00 preboot=echo;echo Type run flash_nfs to mount root filesystem over NFS;echo nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpath) btargs=setenv bootargs console=ttyS0,$(baudrate) nofpu mem=30M root=/dev/ram0 rw addip=setenv bootargs $(bootargs) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmas k):$(hostname):$(netdev):off addmisc=setenv bootargs $(bootargs) console=ttyS0,$(baudrate) ethaddr=$(ethaddr) panic=1 flash_nfs=run nfsargs addip addmisc;bootm $(kernel_addr) flash_self=run ramargs addip addmisc;bootm $(kernel_addr) $(ramdisk_addr) net_nfs=tftp 8050 $(bootfile);run nfsargs addip addmisc;bootm netbootfile=uImage jffsfile=jffs.1.1 progjffs=tftp 0x8080 $(jffsfile); erase 0xad04 0xad3b; cp.b 0x808000 00 0xad04 $(filesize) imget=tftp 0x8080 refmta.bin;erase 0xad00 0xad3e;cp.b 0x8080 0xa d00 $(filesize) localbootfile=/boot/uImage bootnet=tftp 0x8080 $(netbootfile); bootm 0x8080 kernel_addr=AD04 u-bootfile=u-boot.ctlm.bin load-ub=tftp 80504000 $(u-bootfile) update-ub=protect off 1:0-4;cp.b AD00 8050 4000;cp.b AD03F000 8053F000 1 000;erase 0xAD00 0xAD03;cp.b 8050 AD00 0x4 btlinux=fsload 0x8080 $(localbootfile); bootm 0x8080 ethact=Eth. netmask=255.255.0.0 serverip=10.47.3.54 ipaddr=10.47.252.254 stdin=serial stdout=serial stderr=serial filesize=319370 Environment size: 1554/4092 bytes Please throw some light on this. Thanks Rahanesh -- View this message in context: http://www.nabble.com/Problem-with-uboot-booting-image-tp24160664p24160664.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ... resent] Atmel LCD driver GUARDTIME fix
Jean-Christophe PLAGNIOL-VILLARD wrote: for at91 the GUARD_TIME is 1 and IIRC it's lcd specific You just contradicted yourself. The Guard time is the number of empty frames (with control signals enabled but no data) to wait before starting to send valid data to the display. Setting it slightly too high shouldn't make any difference. However, setting it slightly too low may cause strange failures every now and then. Haavard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
On 23:08 Mon 22 Jun , Prafulla Wadaskar wrote: -Original Message- From: Scott Wood [mailto:scottw...@freescale.com] Sent: Tuesday, June 23, 2009 3:35 AM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver On Sun, Jun 14, 2009 at 10:32:47PM +0530, Prafulla Wadaskar wrote: diff --git a/drivers/mtd/nand/kirkwood_nand.c b/drivers/mtd/nand/kirkwood_nand.c new file mode 100644 index 000..9cdbe20 --- /dev/null +++ b/drivers/mtd/nand/kirkwood_nand.c @@ -0,0 +1,81 @@ +/* + * Copyright (C) Marvell International Ltd. and its affiliates No year? I will correct this. +#include common.h +#include asm/io.h +#include asm/arch/kirkwood.h +#include nand.h I don't see kirkwood.h in upstream, so I guess this should go via an arch tree. Kirkwood support is available in arm/next, I hope it will be pulled soon :-) Any way this is dependency for this driver but is this blocker? I have two options- 1. remove dependency from this patch or 2. get Basic Kirkwood support up streamed There are some other drivers in pipeline i.e. i2c,spi,usb that needs Basic Kirkwood support. So I wish to go for second option Hi Jean, Can you pls help to resolve this dependency? Wolfgang is in vacancy so we will have to wait until he will came back the will be present in the arm tree until and then I will send him a pull request Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ... resent] Atmel LCD driver GUARDTIME fix
On 08:53 Tue 23 Jun , Haavard Skinnemoen wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: for at91 the GUARD_TIME is 1 and IIRC it's lcd specific You just contradicted yourself. at91 boards The Guard time is the number of empty frames (with control signals enabled but no data) to wait before starting to send valid data to the display. Setting it slightly too high shouldn't make any difference. However, setting it slightly too low may cause strange failures every now and then. for at91 boards it's 1 and I've never seen any problem, same in the kernel So I'll prefer to make it optionial and no hardcoded for all boards. Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ... resent] Atmel LCD driver GUARDTIME fix
Jean-Christophe PLAGNIOL-VILLARD wrote: On 08:53 Tue 23 Jun , Haavard Skinnemoen wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: for at91 the GUARD_TIME is 1 and IIRC it's lcd specific You just contradicted yourself. at91 boards Ok, I see. The Guard time is the number of empty frames (with control signals enabled but no data) to wait before starting to send valid data to the display. Setting it slightly too high shouldn't make any difference. However, setting it slightly too low may cause strange failures every now and then. for at91 boards it's 1 and I've never seen any problem, same in the kernel So I'll prefer to make it optionial and no hardcoded for all boards. Good point. How about if we turn it into a configuration symbol and default to 1 if it's unset? Haavard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
Prafulla, -Original Message- From: Scott Wood [mailto:scottw...@freescale.com] Sent: Tuesday, June 23, 2009 3:35 AM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver On Sun, Jun 14, 2009 at 10:32:47PM +0530, Prafulla Wadaskar wrote: diff --git a/drivers/mtd/nand/kirkwood_nand.c b/drivers/mtd/nand/kirkwood_nand.c new file mode 100644 index 000..9cdbe20 --- /dev/null +++ b/drivers/mtd/nand/kirkwood_nand.c @@ -0,0 +1,81 @@ +/* + * Copyright (C) Marvell International Ltd. and its affiliates No year? I will correct this. +#include common.h +#include asm/io.h +#include asm/arch/kirkwood.h +#include nand.h I don't see kirkwood.h in upstream, so I guess this should go via an arch tree. Kirkwood support is available in arm/next, I hope it will be pulled soon :-) Any way this is dependency for this driver but is this blocker? I have two options- 1. remove dependency from this patch or 2. get Basic Kirkwood support up streamed There are some other drivers in pipeline i.e. i2c,spi,usb that needs Basic Kirkwood support. So I wish to go for second option Hi Jean, Can you pls help to resolve this dependency? Could you give me a rough time schedule for these new drivers? Do we talk from a view weeks or months? I have to start writing my board support functions and it would be helpful to decide on which u-boot I want to start (1.1.4 marvell or marvell git). Thanks, Dieter Please let me know your feedback on this issue ASAP so that I can release next spin Regards.. Prafulla . . ___ 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 v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
-Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Tuesday, June 23, 2009 1:23 PM To: u-boot@lists.denx.de Cc: Prafulla Wadaskar; Scott Wood; Jean-Christophe PLAGNIOL-VILLARD; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver Prafulla, -Original Message- From: Scott Wood [mailto:scottw...@freescale.com] Sent: Tuesday, June 23, 2009 3:35 AM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver On Sun, Jun 14, 2009 at 10:32:47PM +0530, Prafulla Wadaskar wrote: diff --git a/drivers/mtd/nand/kirkwood_nand.c b/drivers/mtd/nand/kirkwood_nand.c new file mode 100644 index 000..9cdbe20 --- /dev/null +++ b/drivers/mtd/nand/kirkwood_nand.c @@ -0,0 +1,81 @@ +/* + * Copyright (C) Marvell International Ltd. and its affiliates No year? I will correct this. +#include common.h +#include asm/io.h +#include asm/arch/kirkwood.h +#include nand.h I don't see kirkwood.h in upstream, so I guess this should go via an arch tree. Kirkwood support is available in arm/next, I hope it will be pulled soon :-) Any way this is dependency for this driver but is this blocker? I have two options- 1. remove dependency from this patch or 2. get Basic Kirkwood support up streamed There are some other drivers in pipeline i.e. i2c,spi,usb that needs Basic Kirkwood support. So I wish to go for second option Hi Jean, Can you pls help to resolve this dependency? Could you give me a rough time schedule for these new drivers? Do we talk from a view weeks or months? SPI is ready to use (available on git.marvell.com) USB will be ready latest by ~10thJuly2009 I2C lowest priority (as per need) I have to start writing my board support functions and it would be helpful to decide on which u-boot I want to start (1.1.4 marvell or marvell git). Please use marvell git, 1.1.4 is now outdated and not recommended for new development Regards.. Prafulla . . Thanks, Dieter Please let me know your feedback on this issue ASAP so that I can release next spin Regards.. Prafulla . . ___ 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 v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
Am Dienstag 23 Juni 2009 10:01:28 schrieb Prafulla Wadaskar: -Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Tuesday, June 23, 2009 1:23 PM To: u-boot@lists.denx.de Cc: Prafulla Wadaskar; Scott Wood; Jean-Christophe PLAGNIOL-VILLARD; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver Prafulla, -Original Message- From: Scott Wood [mailto:scottw...@freescale.com] Sent: Tuesday, June 23, 2009 3:35 AM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver On Sun, Jun 14, 2009 at 10:32:47PM +0530, Prafulla Wadaskar wrote: diff --git a/drivers/mtd/nand/kirkwood_nand.c b/drivers/mtd/nand/kirkwood_nand.c new file mode 100644 index 000..9cdbe20 --- /dev/null +++ b/drivers/mtd/nand/kirkwood_nand.c @@ -0,0 +1,81 @@ +/* + * Copyright (C) Marvell International Ltd. and its affiliates No year? I will correct this. +#include common.h +#include asm/io.h +#include asm/arch/kirkwood.h +#include nand.h I don't see kirkwood.h in upstream, so I guess this should go via an arch tree. Kirkwood support is available in arm/next, I hope it will be pulled soon :-) Any way this is dependency for this driver but is this blocker? I have two options- 1. remove dependency from this patch or 2. get Basic Kirkwood support up streamed There are some other drivers in pipeline i.e. i2c,spi,usb that needs Basic Kirkwood support. So I wish to go for second option Hi Jean, Can you pls help to resolve this dependency? Could you give me a rough time schedule for these new drivers? Do we talk from a view weeks or months? SPI is ready to use (available on git.marvell.com) USB will be ready latest by ~10thJuly2009 Thats fine - you made me a birthday present :) I2C lowest priority (as per need) Can I do something to push I2C priority? I have to start writing my board support functions and it would be helpful to decide on which u-boot I want to start (1.1.4 marvell or marvell git). Please use marvell git, 1.1.4 is now outdated and not recommended for new development Thats my opinion, too. Thanks, Dieter Regards.. Prafulla . . Thanks, Dieter Please let me know your feedback on this issue ASAP so that I can release next spin Regards.. Prafulla . . ___ 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: Fixed PPC4xx debug compilation error in uic.c
Hi Alessio,
a few general comments to your patch:
Please add ppc4xx: at the start of the commit subject and change PATCH to
[PATCH]. The line should look like this:
[PATCH] ppc4xx: Fixed PPC4xx debug compilation error in uic.c
I really suggest that you use the git tools to create and send such patches
(git format-patch and git send-email). This really simplifies things.
This patch doesn't apply:
[ste...@stefan-desktop u-boot-ppc4xx (master)]$ git am patches_misc/PATCH\:\
Fixed\ PPC4xx\ debug\ compilation\ error\ in\ uic.mbox
Applying: PATCH: Fixed PPC4xx debug compilation error in uic.c
error: patch failed: cpu/ppc4xx/uic.c:164
error: cpu/ppc4xx/uic.c: patch does not apply
Patch failed at 0001 PATCH: Fixed PPC4xx debug compilation error in uic.c
More comments below:
So please fix the problems mentioned above and resubmit. Thanks.
On Wednesday 17 June 2009 08:40:54 Alessio Centazzo wrote:
This patch fixes a debug compilation error for PPC4xx platforms, all other
architectures are not affected by this change. The 'handler' pointer was
undefined. The fix is exercised and has effect only if DEBUG is defined.
Too long line. Please use something like 70 chars max. for commit text.
Signed-off-by: Alessio Centazzo acpatin {AT} yahoo {DOT} com
Use real email address here.
diff u-boot-2009.06/cpu/ppc4xx/uic.c.orig u-boot-2009.06/cpu/ppc4xx/uic.c
--- u-boot-2009.06/cpu/ppc4xx/uic.c.orig2009-06-14 12:30:39.0
-0700 +++ u-boot-2009.06/cpu/ppc4xx/uic.c2009-06-16 23:04:14.0
-0700 @@ -164,7 +164,7 @@
else if (vec = 96)
mtdcr(uic3er, mfdcr(uic3er) | UIC_MASK(vec));
-debug(Install interrupt for vector %d == %p\n, vec, handler);
+debug(Enable interrupt for vector %d\n, vec);
}
void pic_irq_disable(unsigned int vec)
So please fix the problems mentioned above and resubmit. Thanks.
Best regards,
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] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
I2C lowest priority (as per need) Can I do something to push I2C priority? If the I/O is shared with gpio you can use bitbanging with few hours Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Fix FDT EBC mappings on Canyonlands
On Monday 22 June 2009 14:30:42 Felix Radensky wrote: This patch fixes 2 problems with FDT EBC mappings on Canyonlands. First, NAND EBC mapping was missing, making Linux NAND driver unusable on this board. Second, NOR remapping code assumed that NOR is always on CS0, however when booting from NAND NOR is on CS3. --- You forgot you signed-off-by line here. I added it manually and pushed it into the u-boot-ppc4xx/master repo. Thanks. Best regards, 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] [PATCH ... resent] Atmel LCD driver GUARDTIME fix
On 09:21 Tue 23 Jun , Haavard Skinnemoen wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: On 08:53 Tue 23 Jun , Haavard Skinnemoen wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: for at91 the GUARD_TIME is 1 and IIRC it's lcd specific You just contradicted yourself. at91 boards Ok, I see. The Guard time is the number of empty frames (with control signals enabled but no data) to wait before starting to send valid data to the display. Setting it slightly too high shouldn't make any difference. However, setting it slightly too low may cause strange failures every now and then. for at91 boards it's 1 and I've never seen any problem, same in the kernel So I'll prefer to make it optionial and no hardcoded for all boards. Good point. How about if we turn it into a configuration symbol and default to 1 if it's unset? fine for me Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
Am Dienstag 23 Juni 2009 10:35:31 schrieb Jean-Christophe PLAGNIOL-VILLARD: I2C lowest priority (as per need) Can I do something to push I2C priority? If the I/O is shared with gpio you can use bitbanging with few hours I think this would be the best to start - due to the fact that I need bitbanging for FPGA flashing, too. Best Regards, J. @Prafulla: in kirkwood/cpu.c there are 2 functions: kw_config_gpio() kw_config_mpp() If I implement additional functions like kw_gpio_direction(int gpio, enum direction) kw_gpio_set(int gpio, int value) int value kw_gpio_get(int gpio) If the functions are implemented in cpu.c are they accessible from cmd_xxx.c functions? Would this be ok to get it mainline or should there be an special driver for gpio access? Sorry for my newbie questions :) Dieter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mips, U-Boot and ramdisk
Hi Robert, Can anybody help me? I'm working on this for a few days... I'm working on a custom developed board, with Au1200, and I'd like to use the U-Boot as bootloader. I ported the U-Boot to my board, made a Linux kernel image, and a ramdisk image. To try out the configuration, I burn the U-Boot image into the flash (it works well), and after I start the board, it download the kernel image and the ramdisk image through TFTP. I'm using the following two commands: tftp 8100 uImage tftp 81C0 uRamdisk I set the bootargs variable to: root=\dev\ram (I used: set bootargs root=/dev/ram) root=/dev/ram is definitely correct. It was MS-DOS a while ago, which switched the '/'s to '\'s on stealing the hierarchical file system concept from Unix ;) But when I'm trying to start the Linux with the bootm 8100 81C0 the Linux can't find the ramdisk. It write out: Initrd not found or empty - disabling initrd But when I set its address into the bootargs (so the bootargs: root=/dev/ram rd_start=0x8200 rd_size=0x191160), it works well; it successfully find the image, and can mount it. How does the U-Boot pass the ramdisk information? This is highly specific to the architecture. Looking into MIPS code, it an environment like datastructure is built and passes that to the kernel (lib_mips/bootm.c). It sets some kind of environment variables in the bootm.c. Right, that's what I see also. But it doesn't work for me. Why? I can't help you here, the best thing would be to debug this. Maybe the MIPS kernel changed the way the environment is passed? Cheers Detlev -- We have a live-manual. It's called emacs-de...@gnu.org. You can stick to just reading it, but you can skip to a specific chapter by simply sending an email asking for it ;-) -- Stefan Monnier -- 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 add rgb555 for at91
Hi Giulio, RGB555 is a wiring with blue and red swapped, nothing more. Maybe I've made too much confusion before. And in the at91 eks there's nothing to change, because they're wired as BGR555. Ok, in this case, postpone your patch until a board is in mainline which needs this support ;) Cheers Detlev -- Man sei weder unzufrieden mit sich selbst - denn das waere Kleinmut - noch selbstzufrieden - denn das waere Dummheit. --- Baltasar Gracian -- 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] Problem with uboot booting Linux image
Hi All, I am trying to boot Linux from uboot. I have cross compiled Linux and ramdisk for my board. After cross compilation i did a tftp to download the image(Linux + Filesystem) to RAM(0x8080) . From there i copied it to flash(0xad04). Now on a reset u boot comes up and then when trying to bring LINUX it throws an error saying Verifying Checksum...Bad data CRC. Then uboot prompt appears. This is what happened. U-Boot 1.1.2 (Jun 10 2008 - 18:55:13) Board: MIPS CPU Speed 200 MHz DRAM: 16 MB sflash.c:266:DF_F_DataflashProbe: Entered sflash.c:269:DF_F_DataflashProbe: flash type is 0x1 sflash.c:270:DF_F_DataflashProbe: num pages 32768 DataFlash:Nb pages: 32768 Page Size:256 Size= 8388608 bytes Logical address: 0xAD00 Nb Erase Blocks:128 Erase Block Size: 65536 Area 0: AD00 to AD003FFF Area 1: AD004000 to AD03 Area 2: AD04 to AD30BFFF Area 3: AD30C000 to AD7F crc matched In:serial Out: serial Err: serial Net:Eth. Type run flash_nfs to mount root filesystem over NFS Hit any key to stop autoboot: 0 ### JFFS2 loading '/boot/uImage' to 0x8080 Scanning JFFS2 FS: done. ### JFFS2 load complete: 3249008 bytes loaded to 0x8080 ## Booting image at 8080 ... Image Name: Linux Kernel Image with ramdisk. Created: 2009-06-22 4:37:12 UTC Image Type: MIPS Linux Kernel Image (gzip compressed) Data Size:3248944 Bytes = 3.1 MB Load Address: 8010 Entry Point: 80578000 Verifying Checksum ... Bad Data CRC UBOOT UBOOT # printenv bootargs=console=ttyS0,38400 nofpu mem=14M root=/dev/ram0 rw bootcmd=fsload 0x8080 /boot/uImage; bootm 0x8080 bootdelay=5 baudrate=38400 ethaddr=00:06:0D:00:00:00 preboot=echo;echo Type run flash_nfs to mount root filesystem over NFS;echo nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpath) btargs=setenv bootargs console=ttyS0,$(baudrate) nofpu mem=30M root=/dev/ram0 rw addip=setenv bootargs $(bootargs) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmas k):$(hostname):$(netdev):off addmisc=setenv bootargs $(bootargs) console=ttyS0,$(baudrate) ethaddr=$(ethaddr) panic=1 flash_nfs=run nfsargs addip addmisc;bootm $(kernel_addr) flash_self=run ramargs addip addmisc;bootm $(kernel_addr) $(ramdisk_addr) net_nfs=tftp 8050 $(bootfile);run nfsargs addip addmisc;bootm netbootfile=uImage jffsfile=jffs.1.1 progjffs=tftp 0x8080 $(jffsfile); erase 0xad04 0xad3b; cp.b 0x808000 00 0xad04 $(filesize) imget=tftp 0x8080 refmta.bin;erase 0xad00 0xad3e;cp.b 0x8080 0xa d00 $(filesize) localbootfile=/boot/uImage bootnet=tftp 0x8080 $(netbootfile); bootm 0x8080 kernel_addr=AD04 u-bootfile=u-boot.ctlm.bin load-ub=tftp 80504000 $(u-bootfile) update-ub=protect off 1:0-4;cp.b AD00 8050 4000;cp.b AD03F000 8053F000 1 000;erase 0xAD00 0xAD03;cp.b 8050 AD00 0x4 btlinux=fsload 0x8080 $(localbootfile); bootm 0x8080 ethact=Eth. netmask=255.255.0.0 serverip=10.47.3.54 ipaddr=10.47.252.254 stdin=serial stdout=serial stderr=serial filesize=319370 Environment size: 1554/4092 bytes Please throw some light on this. Thanks Rahanesh The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91sam9260/9263: add back up fot the rst(reset controller).
On the boards at91sam9260ek, at91sam9263ek and afed9260, the rstc register was
set to 0 after being set to 500 ms for the PHY reset.
Now if back up is enable it will be set to the saved value.
Signed-off-by: Sedji Gaouaou sedji.gaou...@atmel.com
---
board/afeb9260/afeb9260.c |6 +-
board/atmel/at91sam9260ek/at91sam9260ek.c |6 +-
board/atmel/at91sam9263ek/at91sam9263ek.c |6 +-
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/board/afeb9260/afeb9260.c b/board/afeb9260/afeb9260.c
index a247663..1af02e2 100644
--- a/board/afeb9260/afeb9260.c
+++ b/board/afeb9260/afeb9260.c
@@ -81,6 +81,8 @@ static void afeb9260_nand_hw_init(void)
#ifdef CONFIG_MACB
static void afeb9260_macb_hw_init(void)
{
+ unsigned long rstc;
+
/* Enable clock */
at91_sys_write(AT91_PMC_PCER, 1 AT91SAM9260_ID_EMAC);
@@ -103,6 +105,8 @@ static void afeb9260_macb_hw_init(void)
pin_to_mask(AT91_PIN_PA28),
pin_to_controller(AT91_PIN_PA0) + PIO_PUDR);
+ rstc = at91_sys_read(AT91_RSTC_MR);
+
/* Need to reset PHY - 500ms reset */
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
AT91_RSTC_ERSTL | (0x0D 8) |
@@ -115,7 +119,7 @@ static void afeb9260_macb_hw_init(void)
/* Restore NRST value */
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
-AT91_RSTC_ERSTL | (0x0 8) |
+(rstc) |
AT91_RSTC_URSTEN);
/* Re-enable pull-up */
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index 6bd3b44..93bc021 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -86,6 +86,8 @@ static void at91sam9260ek_nand_hw_init(void)
#ifdef CONFIG_MACB
static void at91sam9260ek_macb_hw_init(void)
{
+ unsigned long rstc;
+
/* Enable clock */
at91_sys_write(AT91_PMC_PCER, 1 AT91SAM9260_ID_EMAC);
@@ -108,6 +110,8 @@ static void at91sam9260ek_macb_hw_init(void)
pin_to_mask(AT91_PIN_PA28),
pin_to_controller(AT91_PIN_PA0) + PIO_PUDR);
+ rstc = at91_sys_read(AT91_RSTC_MR);
+
/* Need to reset PHY - 500ms reset */
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
(AT91_RSTC_ERSTL (0x0D 8)) |
@@ -120,7 +124,7 @@ static void at91sam9260ek_macb_hw_init(void)
/* Restore NRST value */
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
-(AT91_RSTC_ERSTL (0x0 8)) |
+(rstc) |
AT91_RSTC_URSTEN);
/* Re-enable pull-up */
diff --git a/board/atmel/at91sam9263ek/at91sam9263ek.c
b/board/atmel/at91sam9263ek/at91sam9263ek.c
index 57d5c95..e41b7fa 100644
--- a/board/atmel/at91sam9263ek/at91sam9263ek.c
+++ b/board/atmel/at91sam9263ek/at91sam9263ek.c
@@ -91,6 +91,8 @@ static void at91sam9263ek_nand_hw_init(void)
#ifdef CONFIG_MACB
static void at91sam9263ek_macb_hw_init(void)
{
+ unsigned long rstc;
+
/* Enable clock */
at91_sys_write(AT91_PMC_PCER, 1 AT91SAM9263_ID_EMAC);
@@ -108,6 +110,8 @@ static void at91sam9263ek_macb_hw_init(void)
pin_to_mask(AT91_PIN_PE26),
pin_to_controller(AT91_PIN_PE0) + PIO_PUDR);
+ rstc = at91_sys_read(AT91_RSTC_MR);
+
/* Need to reset PHY - 500ms reset */
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
(AT91_RSTC_ERSTL (0x0D 8)) |
@@ -120,7 +124,7 @@ static void at91sam9263ek_macb_hw_init(void)
/* Restore NRST value */
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
-(AT91_RSTC_ERSTL (0x0 8)) |
+(rstc) |
AT91_RSTC_URSTEN);
/* Re-enable pull-up */
--
1.5.3.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mips, U-Boot and ramdisk
Hi Robert. I set the bootargs variable to: root=\dev\ram (I used: set bootargs root=/dev/ram) But when I'm trying to start the Linux with the bootm 8100 81C0 the Linux can't find the ramdisk. It write out: Initrd not found or empty - disabling initrd Do you see U-Boot detecting and loading the ram disk image once you invoke your bootm command above? eg: ## Loading RAMDisk Image at 0050 ... Image Name: uboot ext2 ramdisk rootfs Created: 2009-06-15 14:39:13 UTC Image Type: M68K Linux RAMDisk Image (gzip compressed) Data Size:5219290 Bytes = 5 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 4fa79000, end 4ff733da ... OK I believe that for U-Boot to pass the ram disk image information to the kernel, it needs to be able to detect the ram disk image in the first place. You can use U-Boot's mkimage utility to add a header onto your ram disk image. But when I set its address into the bootargs (so the bootargs: root=/dev/ram rd_start=0x8200 rd_size=0x191160), it works well; it successfully find the image, and can mount it. This is because you're explicitly telling the kernel where to find the ram disk image in memory. Take a look at drivers/block/brd.c in the kernel src. How does the U-Boot pass the ramdisk information? It sets some kind of environment variables in the bootm.c. But it doesn't work for me. Why? (I could use the bootargs solution in this case, but I'm afraid, it can't pass other arguments too, like ethernet address, etc.) This is arch specific in U-Boot but I'd also check that your MIPS kernel has support for a) correctly parsing the U-Boot environment provided to it and b) providing the required data to other parts of the kernel for utilisation of the ram disk, eg initrd_start / initrd_end as an example. If you're struggling to pass other args to the kernel then it sounds like there is more of a fundamental issue somewhere, though. Maybe just double check Documentation/kernel-parameters.txt to make sure you're passing syntax in a form that the kernel will recognise? Hope that helps. Cheers, -- Matt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mips, U-Boot and ramdisk
Hi Detlev, Thanks for the answer! Hi Robert, root=/dev/ram is definitely correct. It was MS-DOS a while ago, which switched the '/'s to '\'s on stealing the hierarchical file system concept from Unix ;) Sorry! Yes I used '/'. I just missed it. This is highly specific to the architecture. Looking into MIPS code, it an environment like datastructure is built and passes that to the kernel (lib_mips/bootm.c). I thought... But I didn't find any description about this. I can't help you here, the best thing would be to debug this. Maybe the MIPS kernel changed the way the environment is passed? Cheers Detlev I'm trying, but it's not so easy to debug the Au1200 with the BDI3000. If I want to single step the code, I should set the Enable single step mode flag in the processor's debug CP0 register, and clear when I'm using breakpoints, and other goodies... :) Best regards, Robert Hodaszi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91: Add esd gmbh MEESC board support
This patch adds support for esd gmbh MEESC board. The MEESC is based on an Atmel AT91SAM9263 SoC. Signed-off-by: Daniel Gorsulowski daniel.gorsulow...@esd.eu --- Jean-Christophe: This patch requires an up-to-date mach-types.h, please sync it. MAINTAINERS |4 + MAKEALL |1 + Makefile|3 + board/esd/meesc/Makefile| 55 +++ board/esd/meesc/config.mk |1 + board/esd/meesc/meesc.c | 211 +++ board/esd/meesc/partition.c | 37 include/configs/meesc.h | 185 + 8 files changed, 497 insertions(+), 0 deletions(-) create mode 100644 board/esd/meesc/Makefile create mode 100644 board/esd/meesc/config.mk create mode 100644 board/esd/meesc/meesc.c create mode 100644 board/esd/meesc/partition.c create mode 100644 include/configs/meesc.h diff --git a/MAINTAINERS b/MAINTAINERS index 9379c7e..449443a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -532,6 +532,10 @@ Peter Figuli pep...@etc.sk wepep250xscale +Daniel Gorsulowski daniel.gorsulow...@esd.eu + + meesc ARM926EJS (AT91SAM9263 SoC) + Marius Gröger m...@sysgo.de impa7 ARM720T (EP7211) diff --git a/MAKEALL b/MAKEALL index f4599d6..eb7b0d7 100755 --- a/MAKEALL +++ b/MAKEALL @@ -587,6 +587,7 @@ LIST_at91= \ cmc_pu2 \ csb637 \ kb9202 \ + meesc \ mp2usb \ m501sk \ pm9263 \ diff --git a/Makefile b/Makefile index 46871d0..a5db70d 100644 --- a/Makefile +++ b/Makefile @@ -2787,6 +2787,9 @@ at91sam9rlek_config : unconfig fi; @$(MKCONFIG) -a at91sam9rlek arm arm926ejs at91sam9rlek atmel at91 +meesc_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs meesc esd at91 + pm9263_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs pm9263 ronetix at91 diff --git a/board/esd/meesc/Makefile b/board/esd/meesc/Makefile new file mode 100644 index 000..2dd6b25 --- /dev/null +++ b/board/esd/meesc/Makefile @@ -0,0 +1,55 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Stelian Pop stelian@leadtechdesign.com +# Lead Tech Design www.leadtechdesign.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS-y+= $(BOARD).o +COBJS-$(CONFIG_HAS_DATAFLASH) += partition.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/esd/meesc/config.mk b/board/esd/meesc/config.mk new file mode 100644 index 000..9ce161e --- /dev/null +++ b/board/esd/meesc/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0x21f0 diff --git a/board/esd/meesc/meesc.c b/board/esd/meesc/meesc.c new file mode 100644 index 000..557a51c --- /dev/null +++ b/board/esd/meesc/meesc.c @@ -0,0 +1,211 @@ +/* + * (C) Copyright 2007-2008 + * Stelian Pop stelian@leadtechdesign.com + * Lead Tech Design www.leadtechdesign.com + * + * (C) Copyright 2009 + * Daniel Gorsulowski daniel.gorsulow...@esd.eu + * esd electronic system design gmbh www.esd.eu + * + * 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
Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
-Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Tuesday, June 23, 2009 2:18 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Scott Wood; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver Am Dienstag 23 Juni 2009 10:35:31 schrieb Jean-Christophe PLAGNIOL-VILLARD: I2C lowest priority (as per need) Can I do something to push I2C priority? Any way this driver will be arround TWSI controller interface by h/w Again if you are using different pins then may not be helpful for you If the I/O is shared with gpio you can use bitbanging with few hours I think this would be the best to start - due to the fact that I need bitbanging for FPGA flashing, too. This is a good Idea, start your development with accessing GPIO registers directly Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mips, U-Boot and ramdisk
Hi Matthew, Hi Robert. Do you see U-Boot detecting and loading the ram disk image once you invoke your bootm command above? eg: ## Loading RAMDisk Image at 0050 ... Image Name: uboot ext2 ramdisk rootfs Created: 2009-06-15 14:39:13 UTC Image Type: M68K Linux RAMDisk Image (gzip compressed) Data Size:5219290 Bytes = 5 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 4fa79000, end 4ff733da ... OK I believe that for U-Boot to pass the ram disk image information to the kernel, it needs to be able to detect the ram disk image in the first place. You can use U-Boot's mkimage utility to add a header onto your ram disk image. I used the mkimage, the U-Boot successfully recognized the ramdisk image, and it set the ramdisk_start and ramdisk_end variables (I turned on the debug feature). See the followings: * kernel: cmdline image address = 0x8100 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux-2.6.30-dirty Created: 2009-06-23 10:11:33 UTC Image Type: MIPS Linux Kernel Image (gzip compressed) Data Size:1589415 Bytes = 1.5 MB Load Address: 8010 Entry Point: 80104530 Verifying Checksum ... OK kernel data at 0x8140, len = 0x001840a7 (1589415) * ramdisk: cmdline image address = 0x81c0 ## Loading init Ramdisk from Legacy Image at 81c0 ... Image Name: Simple Embedded Linux Framework Created: 2007-01-21 18:52:48 UTC Image Type: MIPS Linux RAMDisk Image (gzip compressed) Data Size:1642848 Bytes = 1.6 MB Load Address: Entry Point: Verifying Checksum ... OK ramdisk start = 0x8200, ramdisk end = 0x82191160 Uncompressing Kernel Image ... OK kernel loaded at 0x8010, end = 0x8044a200 ## Transferring control to Linux (at address 80104530) ... ## Giving linux memsize in bytes, 134217728 This is because you're explicitly telling the kernel where to find the ram disk image in memory. Take a look at drivers/block/brd.c in the kernel src. As I saw, the arch/mips/kernel/setup.c (rd_start_early and rd_size_early) set these informations. This is arch specific in U-Boot but I'd also check that your MIPS kernel has support for a) correctly parsing the U-Boot environment provided to it and b) providing the required data to other parts of the kernel for utilisation of the ram disk, eg initrd_start / initrd_end as an example. If you're struggling to pass other args to the kernel then it sounds like there is more of a fundamental issue somewhere, though. Maybe just double check Documentation/kernel-parameters.txt to make sure you're passing syntax in a form that the kernel will recognise? Hope that helps. Cheers, -- Matt I don't know yet, if it can or can't pass other arguments. I check only that one so far. But the command line parameters work well, I tried the kgdb, the ramdisk, etc. It's only a problem with this environment variable. But I'm just debugging... Best regards, Robert Hodaszi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] udelay
Dear all, Looking at the several udelay implementations for several different architectures (an example is cpu/arm926ejs/davinci/timer.c), it seemed to me that udelay implementations ( and other timer functions ) does not handle timestamp overflow. This might cause unexpected timer problems. By the way, do we have API documentation for such u-boot methods? Regards, Cem ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
Am Dienstag 23 Juni 2009 12:38:05 schrieb Prafulla Wadaskar: -Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Tuesday, June 23, 2009 2:18 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Scott Wood; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver Am Dienstag 23 Juni 2009 10:35:31 schrieb Jean-Christophe PLAGNIOL-VILLARD: I2C lowest priority (as per need) Can I do something to push I2C priority? Any way this driver will be arround TWSI controller interface by h/w Again if you are using different pins then may not be helpful for you I2C by hardware is ok because the pins are not multiplexed with other important functions as its the case for SPI. And also I2C isn't _so_ important to bring up the first board revision :) If the I/O is shared with gpio you can use bitbanging with few hours I think this would be the best to start - due to the fact that I need bitbanging for FPGA flashing, too. This is a good Idea, start your development with accessing GPIO registers directly I start working on gpio stuff now and sending my patches to you. Maybe it is helpful for others, too, Dieter Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
-Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Tuesday, June 23, 2009 4:53 PM To: Prafulla Wadaskar Cc: Jean-Christophe PLAGNIOL-VILLARD; u-boot@lists.denx.de; Scott Wood; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver Am Dienstag 23 Juni 2009 12:38:05 schrieb Prafulla Wadaskar: -Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Tuesday, June 23, 2009 2:18 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Scott Wood; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver Am Dienstag 23 Juni 2009 10:35:31 schrieb Jean-Christophe PLAGNIOL-VILLARD: I2C lowest priority (as per need) Can I do something to push I2C priority? Any way this driver will be arround TWSI controller interface by h/w Again if you are using different pins then may not be helpful for you I2C by hardware is ok because the pins are not multiplexed with other important functions as its the case for SPI. And also I2C isn't _so_ important to bring up the first board revision :) If the I/O is shared with gpio you can use bitbanging with few hours I think this would be the best to start - due to the fact that I need bitbanging for FPGA flashing, too. This is a good Idea, start your development with accessing GPIO registers directly I start working on gpio stuff now and sending my patches to you. Maybe it is helpful for others, too, You are most welcomed as one of kirkwood developer for u-boot community Post your patches to mailing list so that everyone can review and provide you feedback, follow u-boot development guidelines, go through u-boot development documentation.. Best of luck :-) Regards.. Prafulla . . Dieter Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] bootelf and vxWorks
Dear all, I see that do_bootelf method is located at cmd_elf.c and this file also includes do_bootvx method. Why is bootelf command is associated with vxWorks? Regards, Cem ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
On Tuesday 23 June 2009 13:23:18 Dieter Kiermaier wrote: I think this would be the best to start - due to the fact that I need bitbanging for FPGA flashing, too. This is a good Idea, start your development with accessing GPIO registers directly I start working on gpio stuff now and sending my patches to you. Maybe it is helpful for others, too, Please send your patches not only to Prafulla but to the list as well. Thanks. Best regards, 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] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
Am Dienstag 23 Juni 2009 14:06:46 schrieb Prafulla Wadaskar: -Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Tuesday, June 23, 2009 4:53 PM To: Prafulla Wadaskar Cc: Jean-Christophe PLAGNIOL-VILLARD; u-boot@lists.denx.de; Scott Wood; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver Am Dienstag 23 Juni 2009 12:38:05 schrieb Prafulla Wadaskar: -Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Tuesday, June 23, 2009 2:18 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Scott Wood; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver Am Dienstag 23 Juni 2009 10:35:31 schrieb Jean-Christophe PLAGNIOL-VILLARD: I2C lowest priority (as per need) Can I do something to push I2C priority? Any way this driver will be arround TWSI controller interface by h/w Again if you are using different pins then may not be helpful for you I2C by hardware is ok because the pins are not multiplexed with other important functions as its the case for SPI. And also I2C isn't _so_ important to bring up the first board revision :) If the I/O is shared with gpio you can use bitbanging with few hours I think this would be the best to start - due to the fact that I need bitbanging for FPGA flashing, too. This is a good Idea, start your development with accessing GPIO registers directly I start working on gpio stuff now and sending my patches to you. Maybe it is helpful for others, too, You are most welcomed as one of kirkwood developer for u-boot community Post your patches to mailing list so that everyone can review and provide you feedback, follow u-boot development guidelines, go through u-boot development documentation.. Best of luck :-) Thanks to all - it's time to give something back to the community :) And sure - I will send the patches as well to the list! Dieter Regards.. Prafulla . . Dieter Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] api_examples/Makefile: Split up variable declarations
On 2009-06-23, at 01:01, Peter Tyser wrote: This cleans up the Makefile a bit and simplifies future changes Signed-off-by: Peter Tyser pty...@xes-inc.com --- These are some similar changes to the ones I made to the tools directory recently. It gets rid of symlinking source files which has the side benefit of resolving the out of tree build error for the API code. Hi Peter, Thanks a lot for taking care of this. All 4 patches look fine, so Acked-by from me. Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Patch to boot over USB cable on OMAP3EVM
I have created a patch for the OMAP3EVM u-boot to create an image for download into OMAP internal RAM (64k). This allows a complete boot to Linux over USB only, without any RS-232 serial cables. The difference between this and Nishanth Menon's procedures (found here: http://nishanthmenon.blogspot.com/2008/12/towards-creating-beagleboard-n and.html) is simply that the RS232 serial port is not required. If anybody has any input into this, or finds this useful, please share... Here's an executive summary of the boot process: - Setup OMAP3EVM to boot via USB - Start Martin Mueller's omap3_usbload to download the u-boot.bin image - Run a kermit script to talk to the board over /dev/ttyACM0, and download uImage/ramdisk images. - bootm - Linux boots to the command line. Also note: this builds off of a u-boot USB dev branch, not mainline u-boot. The details: - Images: - omap3_usbload: - Download and build omap3_usbload (Nishanth Menon's pusb should work as well): http://groups.google.com/group/beagleboard/browse_thread/thread/2b9e9988 6bb7a747 - Note: requires the libusb package. - u-boot - Get Steve's Sakoman's u-boot usb dev branch: - See http://elinux.org/U-boot_musb_gadget_support - In short (from gitorious): git clone git://gitorious.org/u-boot-omap3/mainline.git cd mainline git checkout --track -b omap3-dev-usb origin/omap3-dev-usb - Current latest commit is commit 6c4dabfd6e32eed49624f773fc39140c4b1322b1 - Apply the attached patch (Note: I'm new to git, and I've just attached a diff -urN patch. With a little help, I'd be happy to upload a proper git patch). For example: - cd mainline - patch -p1 ../u-boot-omap3evm-usb-boot.patch - Build u-boot: make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- omap3_evm_config make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- - You now have a downloadable u-boot.bin. Copy it to u-boot2.bin to avoid confusion. I'll use that name in the script later. - Kermit - Download CKermit with your favorite package manager. - Also you'll need the attached kermrc script. It was created from: http://www.denx.de/wiki/DULG/SystemSetup, section 4.3, with the notable exception about send/recv buffers (see notes at end of this email). - uImage - You'll need the default OMAP3EVM Linux image, but you'll have to rebuild it and make one change: - Remove defines for the ethernet driver. If you include it, the driver will crash on boot because this u-boot does not initialize the Ethernet core. The applicable configs are: # CONFIG_MII is not set # CONFIG_SMSC911X_OMAP3EVM is not set - ramdisk: - For my example below, I convert the ramdisk to uboot format. To do this: mkimage -n 'uboot ext2 ramdisk rootfs' -A arm -O linux -T ramdisk -C gzip -d \ ~/OMAP35x_SDK_1.0.2/ramdisk-min.gz ramdisk.ext2.gz.uboot - OMAP3EVM Board setup: - The jumpers need to be set for USB boot. For my board, I've set it to boot USB boot first, MMC boot second, which is: SW4 (1-8): ON OFF OFF ON ON OFF OFF OFF - Connect the USB cable to your Linux host - Connect a serial cable to see the Linux console (not required, but recommened for first time at least). - On the host: - Given the attached scripts and the above built binaries, run: ./usbload - usbload/kermrc scripts currently have the image names embedded in them. They should all be in the current dir. - Output you should see on host: b...@bri-desktop:~/tmp/Beagle/omap3_usb/host$ ./usbload TI OMAP3 USB boot ROM tool, version 0.1 (c) 2008 Martin Mueller marti...@pfump.org ... found device! download ok Loading Linux image... Done Loading Linux image. Loading RamDisk image... Done Loading RamDisk image. Booting Linux... Check serial console for more messages. In addition, you will see the kermit download manager in the terminal in full screen. - Notes: - The memory map on the target is: 0x4020Internal RAM start. Max top of stack 0x40201000Top of stack, start of code/data/bss 0x4020F000Reserved for ROM boot code. - The u-boot image created is VERY tight in memory. We have 60k to use, and the image is within 256 bytes of the max. Be aware of this if/when porting to the beagle board. Most of the changes in the patch were to reduce the code size. - kermit download over /dev/ttyACM0 will not work if the send/receive buffers are greater than 128 or so. They have been set to 128 in kermrc. - omap3_usbload must be run as root, as libusb seems to require it. The usbload script uses sudo to do
Re: [U-Boot] [PATCH] at91sam9260/9263: add back up fot the rst(reset controller).
On 12:46 Tue 23 Jun , Sedji Gaouaou wrote: On the boards at91sam9260ek, at91sam9263ek and afed9260, the rstc register was set to 0 after being set to 500 ms for the PHY reset. Now if back up is enable it will be set to the saved value. Signed-off-by: Sedji Gaouaou sedji.gaou...@atmel.com --- board/afeb9260/afeb9260.c |6 +- board/atmel/at91sam9260ek/at91sam9260ek.c |6 +- board/atmel/at91sam9263ek/at91sam9263ek.c |6 +- 3 files changed, 15 insertions(+), 3 deletions(-) Look fine for me, Stelian Sergey for you? Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mips, U-Boot and ramdisk
This is arch specific in U-Boot but I'd also check that your MIPS kernel has support for a) correctly parsing the U-Boot environment provided to it and b) providing the required data to other parts of the kernel for utilisation of the ram disk, eg initrd_start / initrd_end as an example. If you're struggling to pass other args to the kernel then it sounds like there is more of a fundamental issue somewhere, though. Maybe just double check Documentation/kernel-parameters.txt to make sure you're passing syntax in a form that the kernel will recognise? Hope that helps. Cheers, -- Matt I don't know yet, if it can or can't pass other arguments. I check only that one so far. But the command line parameters work well, I tried the kgdb, the ramdisk, etc. It's only a problem with this environment variable. But I'm just debugging... I checked, and it seems, that the kernel doesn't check anywhere nor the initrd_start and initrd_size, nor the flash_start and flash_size environment parameters, but checks the memsize and ethaddr parameters. At least I couldn't find it. Is it true, or I'm blind? Did anybody use this U-Boot feature? Best regards, Robert Hodaszi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] A320: Add support for Faraday A320 evaluation board
This patch adds support for A320 development board from Faraday. This board uses FA526 processor by default and has 512kB and 32MB NOR flash, 64M RAM. FA526 is an ARMv4 processor and uses the ARM920T source in this patch. Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com --- Index: Makefile === RCS file: /usr/local/cvsroot/ctd/u-boot-2009.06/Makefile,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 Makefile --- Makefile15 Jun 2009 06:47:34 - 1.1.1.1 +++ Makefile23 Jun 2009 06:45:36 - @@ -2940,6 +2940,13 @@ @$(MKCONFIG) $(@:_config=) arm s3c44b0 B2 dave # +## Faraday A320 Systems +# + +a320_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm920t a320 faraday + +# ## ARM720T Systems # Index: board/faraday/a320/Makefile === RCS file: board/faraday/a320/Makefile diff -N board/faraday/a320/Makefile --- /dev/null 1 Jan 1970 00:00:00 - +++ board/faraday/a320/Makefile 16 Jun 2009 13:45:54 - 1.1 @@ -0,0 +1,51 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := board.o timer.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# Index: board/faraday/a320/board.c === RCS file: board/faraday/a320/board.c diff -N board/faraday/a320/board.c --- /dev/null 1 Jan 1970 00:00:00 - +++ board/faraday/a320/board.c 23 Jun 2009 06:06:34 - 1.3 @@ -0,0 +1,120 @@ +/* + * (C) Copyright 2009 Faraday Technology + * Po-Yu Chuang ratb...@faraday-tech.com + * + * 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 common.h +#include netdev.h +#include rtc.h + +#include ftsmc.h + +DECLARE_GLOBAL_DATA_PTR; + +#define FLASH_BANK0_CONFIG (FTSMC_BANK_ENABLE |\ +FTSMC_BANK_BASE(PHYS_FLASH_1) |\ +FTSMC_BANK_SIZE_1M | \ +FTSMC_BANK_MBW_8) + +#define FLASH_BANK0_TIMING (FTSMC_TPR_RBE |\ +FTSMC_TPR_AST(3) | \ +FTSMC_TPR_CTW(3) | \ +FTSMC_TPR_ATI(0xf) | \ +FTSMC_TPR_AT2(3) | \ +FTSMC_TPR_WTC(3) | \ +FTSMC_TPR_AHT(3) | \ +FTSMC_TPR_TRNA(0xf)) + +#define FLASH_BANK1_CONFIG (FTSMC_BANK_ENABLE |
[U-Boot] [PATCH 2/3] A320: driver for FTRTC010 real time clock
This patch adds an FTRTC010 driver for Faraday A320 evaluation board.
Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com
---
Index: drivers/rtc/Makefile
===
RCS file: /usr/local/cvsroot/ctd/u-boot-2009.06/drivers/rtc/Makefile,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- drivers/rtc/Makefile15 Jun 2009 06:47:53 - 1.1.1.1
+++ drivers/rtc/Makefile16 Jun 2009 13:45:55 - 1.2
@@ -40,6 +40,7 @@
COBJS-$(CONFIG_RTC_DS164x) += ds164x.o
COBJS-$(CONFIG_RTC_DS174x) += ds174x.o
COBJS-$(CONFIG_RTC_DS3231) += ds3231.o
+COBJS-$(CONFIG_RTC_FTRTC) += ftrtc010.o
COBJS-$(CONFIG_RTC_ISL1208) += isl1208.o
COBJS-$(CONFIG_RTC_M41T11) += m41t11.o
COBJS-$(CONFIG_RTC_M41T60) += m41t60.o
Index: drivers/rtc/ftrtc010.c
===
RCS file: drivers/rtc/ftrtc010.c
diff -N drivers/rtc/ftrtc010.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ drivers/rtc/ftrtc010.c 23 Jun 2009 06:12:15 - 1.5
@@ -0,0 +1,125 @@
+/*
+ * Faraday FTRTC Real Time Clock
+ *
+ * (C) Copyright 2009 Faraday Technology
+ * Po-Yu Chuang ratb...@faraday-tech.com
+ *
+ * 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.
+ */
+
+#undef DEBUG
+
+#include config.h
+#include common.h
+#include rtc.h
+
+struct ftrtc010 {
+ unsigned int sec; /* 0x00 */
+ unsigned int min; /* 0x04 */
+ unsigned int hour; /* 0x08 */
+ unsigned int day; /* 0x0c */
+ unsigned int alarm_sec; /* 0x10 */
+ unsigned int alarm_min; /* 0x14 */
+ unsigned int alarm_hour;/* 0x18 */
+ unsigned int record;/* 0x1c */
+ unsigned int cr;/* 0x20 */
+};
+
+/*
+ * RTC Control Register
+ */
+#define FTRTC010_CR_ENABLE (1 0)
+#define FTRTC010_CR_INTERRUPT_SEC (1 1)/* per second irq */
+#define FTRTC010_CR_INTERRUPT_MIN (1 2)/* per minute irq */
+#define FTRTC010_CR_INTERRUPT_HR (1 3)/* per hour irq */
+#define FTRTC010_CR_INTERRUPT_DAY (1 4)/* per dayirq */
+
+static volatile struct ftrtc010 *rtc = (struct ftrtc010 *)CONFIG_SYS_RTC_BASE;
+
+static void ftrtc_enable (void)
+{
+ rtc-cr = cpu_to_le32 (FTRTC010_CR_ENABLE);
+}
+
+/*
+ * return current time in seconds
+ */
+static unsigned long ftrtc_time (void)
+{
+ unsigned long day;
+ unsigned long hour;
+ unsigned long minute;
+ unsigned long second;
+ unsigned long second2;
+
+ do {
+ second = le32_to_cpu (rtc-sec);
+ day = le32_to_cpu (rtc-day);
+ hour= le32_to_cpu (rtc-hour);
+ minute = le32_to_cpu (rtc-min);
+ second2 = le32_to_cpu (rtc-sec);
+ } while (second != second2);
+
+ return day * 24 * 60 * 60 + hour * 60 * 60 + minute * 60 + second;
+}
+
+/*
+ * Get the current time from the RTC
+ */
+
+int rtc_get (struct rtc_time *tmp)
+{
+ unsigned long now;
+
+ debug (%s(): record register: %x\n,
+ __func__, le32_to_cpu (rtc-record));
+
+ now = ftrtc_time () + le32_to_cpu (rtc-record);
+
+ to_tm (now, tmp);
+
+ return 0;
+}
+
+/*
+ * Set the RTC
+ */
+int rtc_set (struct rtc_time *tmp)
+{
+ unsigned long new;
+ unsigned long now;
+
+ debug (%s(): DATE: %4d-%02d-%02d (wday=%d) TIME: %2d:%02d:%02d\n,
+ __func__,
+ tmp-tm_year, tmp-tm_mon, tmp-tm_mday, tmp-tm_wday,
+ tmp-tm_hour, tmp-tm_min, tmp-tm_sec);
+
+ new = mktime (tmp-tm_year, tmp-tm_mon, tmp-tm_mday, tmp-tm_hour,
+ tmp-tm_min, tmp-tm_sec);
+
+ now = ftrtc_time ();
+
+ debug (%s(): write %lx to record register\n, __func__, new - now);
+
+ rtc-record = cpu_to_le32 (new - now);
+
+ return 0;
+}
+
+void rtc_reset (void)
+{
+ debug (%s()\n, __func__);
+ ftrtc_enable ();
+}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] A320: driver for FTMAC100 ethernet controller
This patch adds an FTMAC100 ethernet driver for Faraday A320 evaluation board.
Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com
---
Index: drivers/net/Makefile
===
RCS file: /usr/local/cvsroot/ctd/u-boot-2009.06/drivers/net/Makefile,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- drivers/net/Makefile15 Jun 2009 06:47:50 - 1.1.1.1
+++ drivers/net/Makefile16 Jun 2009 13:45:55 - 1.2
@@ -38,6 +38,7 @@
COBJS-$(CONFIG_EEPRO100) += eepro100.o
COBJS-$(CONFIG_ENC28J60) += enc28j60.o
COBJS-$(CONFIG_FSLDMAFEC) += fsl_mcdmafec.o mcfmii.o
+COBJS-$(CONFIG_DRIVER_FTMAC100) += ftmac100.o
COBJS-$(CONFIG_GRETH) += greth.o
COBJS-$(CONFIG_INCA_IP_SWITCH) += inca-ip_sw.o
COBJS-$(CONFIG_DRIVER_KS8695ETH) += ks8695eth.o
Index: drivers/net/ftmac100.c
===
RCS file: drivers/net/ftmac100.c
diff -N drivers/net/ftmac100.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ drivers/net/ftmac100.c 23 Jun 2009 06:11:38 - 1.4
@@ -0,0 +1,266 @@
+/*
+ * Faraday FTMAC100 Ethernet
+ *
+ * (C) Copyright 2009 Faraday Technology
+ * Po-Yu Chuang ratb...@faraday-tech.com
+ *
+ * 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.
+ */
+
+#undef DEBUG
+
+#include config.h
+#include common.h
+#include malloc.h
+#include net.h
+#include ftmac100.h
+
+struct ftmac100_data {
+ volatile struct ftmac100_txdes txdes[1];
+ volatile struct ftmac100_rxdes rxdes[PKTBUFSRX];
+ int rx_index;
+};
+
+/*
+ * Reset MAC
+ */
+static void ftmac100_reset (struct eth_device *dev)
+{
+ volatile struct ftmac100 *ftmac100 = (struct ftmac100 *)dev-iobase;
+
+ debug (%s()\n, __func__);
+
+ ftmac100-maccr = cpu_to_le32 (FTMAC100_MACCR_SW_RST);
+
+ while (le32_to_cpu (ftmac100-maccr) FTMAC100_MACCR_SW_RST) ;
+}
+
+/*
+ * Set MAC address
+ */
+static void ftmac100_set_mac (struct eth_device *dev, const unsigned char *mac)
+{
+ volatile struct ftmac100 *ftmac100 = (struct ftmac100 *)dev-iobase;
+ unsigned int maddr = mac[0] 8 | mac[1];
+ unsigned int laddr = mac[2] 24 | mac[3] 16 | mac[4] 8 | mac[5];
+
+ debug (%s(%x %x)\n, __func__, maddr, laddr);
+
+ ftmac100-mac_madr = cpu_to_le32 (maddr);
+ ftmac100-mac_ladr = cpu_to_le32 (laddr);
+}
+
+/*
+ * disable transmitter, receiver
+ */
+static void ftmac100_halt (struct eth_device *dev)
+{
+ volatile struct ftmac100 *ftmac100 = (struct ftmac100 *)dev-iobase;
+
+ debug (%s()\n, __func__);
+
+ ftmac100-maccr = cpu_to_le32 (0);
+}
+
+static int ftmac100_init (struct eth_device *dev, bd_t * bd)
+{
+ volatile struct ftmac100 *ftmac100 = (struct ftmac100 *)dev-iobase;
+ struct ftmac100_data *priv = dev-priv;
+ volatile struct ftmac100_txdes *txdes = priv-txdes;
+ volatile struct ftmac100_rxdes *rxdes = priv-rxdes;
+ unsigned int maccr;
+ int i;
+
+ debug (%s()\n, __func__);
+
+ ftmac100_reset (dev);
+
+ /* set the ethernet address */
+
+ ftmac100_set_mac (dev, dev-enetaddr);
+
+ /* disable all interrupts */
+
+ ftmac100-imr = cpu_to_le32 (0);
+
+ /* initialize descriptors */
+
+ priv-rx_index = 0;
+
+ txdes[0].txdes1 = FTMAC100_TXDES1_EDOTR;
+ rxdes[PKTBUFSRX - 1].rxdes1 = FTMAC100_RXDES1_EDORR;
+
+ for (i = 0; i PKTBUFSRX; i++) {
+ /* RXBUF_BADR */
+ rxdes[i].rxdes2 = (unsigned int)NetRxPackets[i];
+ rxdes[i].rxdes1 |= FTMAC100_RXDES1_RXBUF_SIZE (PKTSIZE_ALIGN);
+ rxdes[i].rxdes0 = FTMAC100_RXDES0_RXDMA_OWN;
+ }
+
+ /* transmit ring */
+
+ ftmac100-txr_badr = cpu_to_le32 (txdes);
+
+ /* receive ring */
+
+ ftmac100-rxr_badr = cpu_to_le32 (rxdes);
+
+ /* poll receive descriptor automatically */
+
+ ftmac100-aptc = cpu_to_le32 (FTMAC100_APTC_RXPOLL_CNT (1));
+
+ /* enable transmitter, receiver */
+
+ maccr = FTMAC100_MACCR_XMT_EN |
+ FTMAC100_MACCR_RCV_EN |
+ FTMAC100_MACCR_XDMA_EN |
+ FTMAC100_MACCR_RDMA_EN |
+ FTMAC100_MACCR_CRC_APD |
+ FTMAC100_MACCR_ENRX_IN_HALFTX |
+
[U-Boot] [PATCH 2/2] usb: add Kirkwood ehci driver support
Features supported:
1. usb-phy init support (tested on sheevaplug)
This support is required to bring up USB interface
at kernel level on Kirkwood platforms
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
drivers/usb/host/Makefile|1 +
drivers/usb/host/ehci-kirkwood.c | 102 ++
2 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/host/ehci-kirkwood.c
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index ec1d689..4fe7cb3 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -37,6 +37,7 @@ COBJS-$(CONFIG_USB_SL811HS) += sl811-hcd.o
COBJS-$(CONFIG_USB_EHCI) += ehci-hcd.o
COBJS-$(CONFIG_USB_EHCI_FSL) += ehci-fsl.o
COBJS-$(CONFIG_USB_EHCI_IXP4XX) += ehci-ixp.o
+COBJS-$(CONFIG_USB_EHCI_KIRKWOOD) += ehci-kirkwood.o
COBJS-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
COBJS-$(CONFIG_USB_EHCI_VCT) += ehci-vct.o
diff --git a/drivers/usb/host/ehci-kirkwood.c b/drivers/usb/host/ehci-kirkwood.c
new file mode 100644
index 000..8e0aa83
--- /dev/null
+++ b/drivers/usb/host/ehci-kirkwood.c
@@ -0,0 +1,102 @@
+/*
+ * original file from linux: drivers/usb/host/ehci-orion.c
+ *
+ * Tzachi Perelstein tza...@marvell.com
+ *
+ * Updated-by: Prafulla Wadaskar prafu...@marvell.com
+ * Purpose: to reuse usb_phy_v1_setup function
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include common.h
+#include asm/arch/kirkwood.h
+
+#define rdl(off) readl(KW_USB20_BASE + (off))
+#define wrl(off, val) writel((val), KW_USB20_BASE + (off))
+
+#define USB_CMD0x140
+#define USB_MODE 0x1a8
+#define USB_CAUSE 0x310
+#define USB_MASK 0x314
+#define USB_WINDOW_CTRL(i) (0x320 + ((i) 4))
+#define USB_WINDOW_BASE(i) (0x324 + ((i) 4))
+#define USB_IPG0x360
+#define USB_PHY_PWR_CTRL 0x400
+#define USB_PHY_TX_CTRL0x420
+#define USB_PHY_RX_CTRL0x430
+#define USB_PHY_IVREF_CTRL 0x440
+#define USB_PHY_TST_GRP_CTRL 0x450
+
+/*
+ * Implement Orion USB controller specification guidelines
+ */
+void orion_usb_phy_v1_setup(void)
+{
+ /* The below GLs are according to the Orion Errata document */
+ /*
+* Clear interrupt cause and mask
+*/
+ wrl(USB_CAUSE, 0);
+ wrl(USB_MASK, 0);
+
+ /*
+* Reset controller
+*/
+ wrl(USB_CMD, rdl(USB_CMD) | 0x2);
+ while (rdl(USB_CMD) 0x2);
+
+ /*
+* GL# USB-10: Set IPG for non start of frame packets
+* Bits[14:8]=0xc
+*/
+ wrl(USB_IPG, (rdl(USB_IPG) ~0x7f00) | 0xc00);
+
+ /*
+* GL# USB-9: USB 2.0 Power Control
+* BG_VSEL[7:6]=0x1
+*/
+ wrl(USB_PHY_PWR_CTRL, (rdl(USB_PHY_PWR_CTRL) ~0xc0)| 0x40);
+
+ /*
+* GL# USB-1: USB PHY Tx Control - force calibration to '8'
+* TXDATA_BLOCK_EN[21]=0x1, EXT_RCAL_EN[13]=0x1, IMP_CAL[6:3]=0x8
+*/
+ wrl(USB_PHY_TX_CTRL, (rdl(USB_PHY_TX_CTRL) ~0x78) | 0x202040);
+
+ /*
+* GL# USB-3 GL# USB-9: USB PHY Rx Control
+* RXDATA_BLOCK_LENGHT[31:30]=0x3, EDGE_DET_SEL[27:26]=0,
+* CDR_FASTLOCK_EN[21]=0, DISCON_THRESHOLD[9:8]=0, SQ_THRESH[7:4]=0x1
+*/
+ wrl(USB_PHY_RX_CTRL, (rdl(USB_PHY_RX_CTRL) ~0xc2003f0) | 0xc010);
+
+ /*
+* GL# USB-3 GL# USB-9: USB PHY IVREF Control
+* PLLVDD12[1:0]=0x2, RXVDD[5:4]=0x3, Reserved[19]=0
+*/
+ wrl(USB_PHY_IVREF_CTRL, (rdl(USB_PHY_IVREF_CTRL) ~0x80003 ) | 0x32);
+
+ /*
+* GL# USB-3 GL# USB-9: USB PHY Test Group Control
+* REG_FIFO_SQ_RST[15]=0
+*/
+ wrl(USB_PHY_TST_GRP_CTRL, rdl(USB_PHY_TST_GRP_CTRL) ~0x8000);
+
+ /*
+* Stop and reset controller
+*/
+ wrl(USB_CMD, rdl(USB_CMD) ~0x1);
+ wrl(USB_CMD, rdl(USB_CMD) | 0x2);
+ while (rdl(USB_CMD) 0x2);
+
+ /*
+* GL# USB-5 Streaming disable REG_USB_MODE[4]=1
+* TBD: This need to be done after each reset!
+* GL# USB-4 Setup USB Host mode
+*/
+ wrl(USB_MODE, 0x13);
+}
+
--
1.5.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] fix: missing autoconfig.mk from general Makefile
Hi Jean, or someone who understands U-Boot's build system well, Jean-Christophe PLAGNIOL-VILLARD wrote: at the first run of make we generate the autoconf.mk and autoconf.mk.dep if not already the case and we currently include only to .dep in order to use these autogenerated value we need to include it also evenif it's include in config.mk but it's done before there generation Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com --- Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 81a5cd0..7f3776e 100644 --- a/Makefile +++ b/Makefile @@ -475,6 +475,7 @@ $(obj)include/autoconf.mk: $(obj)include/config.h mv $...@.tmp $@ sinclude $(obj)include/autoconf.mk.dep +sinclude $(obj)include/autoconf.mk # else # !config.mk I'm still thinking how to fix this issue. The problem here is, deferred expansion on PLATFORM_LDFLAGS doesn't work expectedly. In this case, | autoconf.mk | --- | CONFIG_CPU_LITTLE_ENDIAN=y | | mips_config.mk | -- | | ifneq (,$(CONFIG_CPU_LITTLE_ENDIAN)) | PLATFORM_CPPFLAGS += $(shell $(CC) -dumpmachine |... | PLATFORM_LDFLAGS += -EL | else | PLATFORM_CPPFLAGS += $(shell $(CC) -dumpmachine |... | PLATFORM_LDFLAGS += -EB | endif doesn't work, but simply doing ... | ifneq (,$(CONFIG_CPU_LITTLE_ENDIAN)) | PLATFORM_CPPFLAGS += $(shell $(CC) -dumpmachine |... | else | PLATFORM_CPPFLAGS += $(shell $(CC) -dumpmachine |... | endif | | PLATFORM_LDFLAGS += -EL does work. Then, what needs to be fixed finally? Can't we have PLATFORM_LDFLAGS conditionally configured? or is this a U-Boot's build system issue? Shinya ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] R: USB EHCI driver
Hi all, I'm successful in provide a preliminary support to EHCI USB Freescale controller integrated on ADS5121 platform. I'm preparing a patch to submit to u-boot mailing list. Regards, Francesco. -Messaggio originale- Da: Michael Trimarchi [mailto:trimar...@gandalf.sssup.it] Inviato: gio 4/9/2009 7:50 A: Gupta Maneesh-B18878 Cc: Rendine Francesco; u-boot@lists.denx.de Oggetto: Re: [U-Boot] USB EHCI driver Hi, Gupta Maneesh-B18878 wrote: Hi Francesco, Could you make any progress? Regards Maneesh -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Michael Trimarchi Sent: Monday, March 23, 2009 2:46 PM To: Rendine Francesco Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] USB EHCI driver Hi, Rendine Francesco wrote: Hi, I've already tried that define, but nothing is changed... What can I see in the USB driver to resolve issue? Thanks. -Original Message- From: Michael Trimarchi [mailto:trimar...@gandalf.sssup.it] Sent: Fri 3/20/2009 9:36 AM To: Rendine Francesco Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] USB EHCI driver Hi, FrancescoVT wrote: usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 dev=1ffebb08, pipe=8883, buffer=1f9a671a, length=64, req=1ffea214 req=6 (0x6), type=128 (0x80), value=256 (0x100), index=0 EHCI fail timeout STD_ASS reset usb_new_device: usb_get_descriptor() failed #define CONFIG_LEGACY_USB_INIT_SEQ Michael Sorry I can't help you without the board :( and now I don't have another board to test to verify it. I'm working on android, and some migor issue. Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot I don't ask anymore because I'm busy, BTW good question Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] fix: missing autoconfig.mk from general Makefile
I'm still thinking how to fix this issue. The problem here is, deferred expansion on PLATFORM_LDFLAGS doesn't work expectedly. In this case, | autoconf.mk | --- | CONFIG_CPU_LITTLE_ENDIAN=y | | mips_config.mk | -- | | ifneq (,$(CONFIG_CPU_LITTLE_ENDIAN)) | PLATFORM_CPPFLAGS += $(shell $(CC) -dumpmachine |... | PLATFORM_LDFLAGS+= -EL | else | PLATFORM_CPPFLAGS += $(shell $(CC) -dumpmachine |... | PLATFORM_LDFLAGS+= -EB | endif doesn't work, but simply doing ... | ifneq (,$(CONFIG_CPU_LITTLE_ENDIAN)) | PLATFORM_CPPFLAGS += $(shell $(CC) -dumpmachine |... | else | PLATFORM_CPPFLAGS += $(shell $(CC) -dumpmachine |... | endif | | PLATFORM_LDFLAGS+= -EL does work. ??? you compile it as big endian to link it as little ??? Then, what needs to be fixed finally? Can't we have PLATFORM_LDFLAGS conditionally configured? or is this a U-Boot's build system issue? it a u-boot build system issues we need to include the autoconf.mk after generate it to use it in the GENERAL Makefile which is the case here for final link Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] OMAP3 I2C Fix the sampling clock.
Jean-Christophe PLAGNIOL-VILLARD wrote: Hi, I'll add a mandatory condition this code MUST be test on omap2 too I have made a mistake on MAKEALL testing. I will have to resubmit this patchset when the issues are resolved. I will arrange to have this tested on an omap2 Tom I think the TI's dev could help on this Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] pxa: fix CKEN_B register bits
The current defition for CKEN_B register bits is nonsense. Adding 32 to the shifted value is equal to '| (1 5)', and this bit is marked 'reserved' in the PXA docs. Signed-off-by: Daniel Mack dan...@caiaq.de --- include/asm-arm/arch-pxa/pxa-regs.h | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/asm-arm/arch-pxa/pxa-regs.h b/include/asm-arm/arch-pxa/pxa-regs.h index 1f81e11..2a723dc 100644 --- a/include/asm-arm/arch-pxa/pxa-regs.h +++ b/include/asm-arm/arch-pxa/pxa-regs.h @@ -1953,12 +1953,12 @@ typedef void(*ExcpHndlr) (void) ; #define CKENA_1_LCD(1 1)/* LCD Unit Clock Enable */ #define CKENB_9_SYSBUS2(1 9)/* System bus 2 */ -#define CKENB_8_1WIRE ((1 8) + 32) /* One Wire Interface Unit Clock Enable */ -#define CKENB_7_GPIO ((1 7) + 32) /* GPIO Clock Enable */ -#define CKENB_6_IRQ((1 6) + 32) /* Interrupt Controller Clock Enable */ -#define CKENB_4_I2C((1 4) + 32) /* I2C Unit Clock Enable */ -#define CKENB_1_PWM1 ((1 1) + 32) /* PWM2 PWM3 Clock Enable */ -#define CKENB_0_PWM0 ((1 0) + 32) /* PWM0 PWM1 Clock Enable */ +#define CKENB_8_1WIRE (1 8)/* One Wire Interface Unit Clock Enable */ +#define CKENB_7_GPIO (1 7)/* GPIO Clock Enable */ +#define CKENB_6_IRQ(1 6)/* Interrupt Controller Clock Enable */ +#define CKENB_4_I2C(1 4)/* I2C Unit Clock Enable */ +#define CKENB_1_PWM1 (1 1)/* PWM2 PWM3 Clock Enable */ +#define CKENB_0_PWM0 (1 0)/* PWM0 PWM1 Clock Enable */ #else /* if defined CONFIG_CPU_MONAHANS */ -- 1.6.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] pxa: add clock for system bus 2 arbiter
This clock is needed for systems using the USB2 device unit or the 2d graphics accelerator. Signed-off-by: Daniel Mack dan...@caiaq.de --- include/asm-arm/arch-pxa/pxa-regs.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-pxa/pxa-regs.h b/include/asm-arm/arch-pxa/pxa-regs.h index 5a0885a..1f81e11 100644 --- a/include/asm-arm/arch-pxa/pxa-regs.h +++ b/include/asm-arm/arch-pxa/pxa-regs.h @@ -1952,6 +1952,7 @@ typedef void (*ExcpHndlr) (void) ; #define CKENA_2_USBHOST(1 2)/* USB Host Unit Clock Enable */ #define CKENA_1_LCD(1 1)/* LCD Unit Clock Enable */ +#define CKENB_9_SYSBUS2(1 9)/* System bus 2 */ #define CKENB_8_1WIRE ((1 8) + 32) /* One Wire Interface Unit Clock Enable */ #define CKENB_7_GPIO ((1 7) + 32) /* GPIO Clock Enable */ #define CKENB_6_IRQ((1 6) + 32) /* Interrupt Controller Clock Enable */ -- 1.6.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] fix: missing autoconfig.mk from general Makefile
Jean-Christophe PLAGNIOL-VILLARD wrote: | ifneq (,$(CONFIG_CPU_LITTLE_ENDIAN)) | PLATFORM_CPPFLAGS += $(shell $(CC) -dumpmachine |... | else | PLATFORM_CPPFLAGS += $(shell $(CC) -dumpmachine |... | endif | | PLATFORM_LDFLAGS += -EL does work. ??? you compile it as big endian to link it as little ??? Ah, above was just a sample only intended for LE build. Then, what needs to be fixed finally? Can't we have PLATFORM_LDFLAGS conditionally configured? or is this a U-Boot's build system issue? it a u-boot build system issues we need to include the autoconf.mk after generate it to use it in the GENERAL Makefile which is the case here for final link I know that, but $(obj)include/autoconf.mk will be included by $(TOPDIR)/config.mk. Then what a rationale for including it redundantly by $(TOPDIR/Makefile? I assume that Wolfgang is probably requesting the explanation for that. Autoconf.mk is expected to be generated *before* $(TOPDIR)/config.mk is included, right? If so, do you think your patch is a reasonable enough? Or do we need to consider another approach? Shinya - not a GNU make expert :-( ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM 1/2] Add support for the Embest SBC2440-II Board
kevin.morf...@fearnside-systems.co.uk wrote: These type names (and the 'const') are in the existing s3c24x0 code so I just made my new code follow the same style and Lindent and checkpatch didn't complain. The u-boot coding style guidelines say we should use the Linux coding style and this says that 'mixed case names are frowned upon' and 'It's a _mistake_ to use typedef for structures' I love it when someone justifies their opinion by asserting that the alternative is a _mistake_. :-) so it doesn't meet the coding style, at least for the use of typedef if not for the upper case names. Upper case names are for macros in the Linux/u-boot code style. I ported this from the Linux s3c2410 NAND driver (which covers s3c2440 as well as s3c2410). It worked when I tested it (after I enabled hardware ECC and fixed the problem below), but I don't know enough about how mtd hardware ecc works to understand why it was done this way in the Linux kernel. A comment in the kernel code says that nand_ecclayout is 'Exported to userspace for diagnosis and to allow creation of raw images' so it's likely I haven't tested this bit as all I did was check that NAND read/write worked. I'll have a look at it in more detail. It's relevant for things like JFFS2, which use the free area for their own markers. It looks like 8 bytes is enough for that, though -- and being in sync with Linux is the most important. It may also be useful to reserve some bytes for alterate ECC schemes. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
Hello Richard, There's only one thing about U-Boot that doesn't seem so good: U-Boot is GPLv2 (sometimes or later). To have some parts which are GPLv2 only is unfortunate. This is due to us many times (re-)using Linux drivers inside U-Boot. Also this is one of the objections worded on the mailing list, namely that such a cooperation will be impossible in the future if U-Boot moves to GPLv3. As a base for reasonable discussion, I think we need to evaluate those claims and back them up by actual figures. Only then the real effort needed to move and the potential loss of code immigration can be estimated. Is there any chance of convincing those authors to change that? Apart from the the above reasons, currently most people who voiced their opinion (not too many right now) oppose the move. The reasoning seems to be that companies using U-Boot inside a commercial product consider it to be a neccessary precondition to only accept blessed firmware upgrades (my wording). What motivates this argument is not completely clear to me. Maybe it is fear of being liable as a product vendor to faulty sw upgrades. A common theme in the embedded community is the fear of getting copied by cheap labor countries - which should not be the case here, but I cannot say for sure. I believe that without discussing this question seriously with all its implications we will not get enough momentum to even start defining the work for a switch. We should also start to actively inform the regularly appearing people on this mailing list complaining that they cannot get the source code to U-Boot of device xyz that with a GPLv2 U-Boot this may become a theoretical question in the future when they cannot install the changed binary anymore. Cheers Detlev -- Die meisten schaetzen nicht, was sie verstehen; aber was sie nicht fassen koennen, verehren sie. Um geschaetzt zu werden, muessen die Sachen Muehe kosten; daher wird geruehmt, wer nicht verstanden wird. --- Baltasar Gracian -- 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] config.mk: Remove unused HPATH
Hi Shinya, This variable is not unused anywhere. Makes my brain twist and after carefully applying boolean equivalence operations contradicts the title ;) Cheers Detlev -- I have always observed that the pretensions of all people are in exact inverse ratio to their merits; this is one of the axioms of morals.-- Joseph Lagrange -- 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 7/7] imx27lite: add support for imx27lite board from LogicPD
Hi Jean-Christophe, On 04:12 Mon 08 Jun , Ilya Yanok wrote: This patch adds support for i.MX27-LITEKIT development board from LogicPD. This board uses i.MX27 SoC and has 2MB NOR flash, 64MB NAND flash, FEC ethernet controller integrated into i.MX27. Signed-off-by: Ilya Yanok ya...@emcraft.com --- MAINTAINERS |1 + MAKEALL |1 + Makefile|3 + board/logicpd/imx27lite/Makefile| 51 +++ board/logicpd/imx27lite/config.mk |1 + board/logicpd/imx27lite/imx27lite.c | 97 + board/logicpd/imx27lite/lowlevel_init.S | 223 +++ board/logicpd/imx27lite/u-boot.lds | 56 include/configs/imx27lite.h | 195 +++ 9 files changed, 628 insertions(+), 0 deletions(-) create mode 100644 board/logicpd/imx27lite/Makefile create mode 100644 board/logicpd/imx27lite/config.mk create mode 100644 board/logicpd/imx27lite/imx27lite.c create mode 100644 board/logicpd/imx27lite/lowlevel_init.S create mode 100644 board/logicpd/imx27lite/u-boot.lds create mode 100644 include/configs/imx27lite.h diff --git a/MAINTAINERS b/MAINTAINERS index 3d50668..98efd69 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -519,6 +519,7 @@ George G. Davis gda...@mvista.com gcplus SA1100 Wolfgang Denk w...@denx.de +imx27lite i.MX27 Wolfgang could you ack it? I ack that on behalf of Wolfgang. Cheers Detlev -- Markov does it in chains. -- 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 1/3] fix: missing autoconfig.mk from general Makefile
On Saturday 23 May 2009 15:42:36 Jean-Christophe PLAGNIOL-VILLARD wrote: at the first run of make we generate the autoconf.mk and autoconf.mk.dep if not already the case and we currently include only to .dep in order to use these autogenerated value we need to include it also evenif it's include in config.mk but it's done before there generation Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com --- Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 81a5cd0..7f3776e 100644 --- a/Makefile +++ b/Makefile @@ -475,6 +475,7 @@ $(obj)include/autoconf.mk: $(obj)include/config.h mv $...@.tmp $@ sinclude $(obj)include/autoconf.mk.dep +sinclude $(obj)include/autoconf.mk # else # !config.mk while i dont really understand your changelog, i think you're attempting to fix a problem i too have hit with Blackfin systems. but i just hacked around it in my tree (i posted this patch before but Wolfgang opposed it on the basis that no other arch had the problems Blackfin did, but apparently that is no longer true): http://git.denx.de/?p=u-boot/u-boot- blackfin.git;a=commitdiff;h=12ce98a697dde38aefe7131ce9a1b2e0e01640ad -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] MPC8360ERDK U-Boot - Broadcom Gigabit Ethernet removal
Hi, I'm trying to completely remove the 2 gigabit ethernets from my U-Boot (as they are depopulated on my target). I want to use the other 2 ethernet ports as FSL UEC0 and FSL UEC1. I've removed the UCC1 and UCC2 entries from the qe_iop_conf_tab in mpc8360erdk.c and updated the corresponding macros in MPC8360ERDK.h. The transmits seem to work. I'm able to communicate from the target to a TFTP server on a PC. However, the RX to the target is not working. I get FSL UEC: Rx error messages. Any ideas/suggestions as to what I need to do to get the RX to work? Also, do I need to define CFG_CMD_MII and/or CFG_MII, so that miiphy_register() is called in uec.c Here are my new macro definitions in MPC8360ERDK.h: #define CONFIG_UEC_ETH1 /* GETH1 */ #ifdef CONFIG_UEC_ETH1 #define CONFIG_SYS_UEC1_UCC_NUM 6 /* UCC7 */ #define CONFIG_SYS_UEC1_RX_CLK QE_CLK19 #define CONFIG_SYS_UEC1_TX_CLK QE_CLK20 #define CONIFG_SYS_UEC1_ETH_TYPEFAST_ETH #define CONFIG_SYS_UEC1_PHY_ADDR1 #define CONFIG_SYS_UEC1_INTERFACE_MODE ENET_100_MII #endif #define CONFIG_UEC_ETH2 /* GETH2 */ #ifdef CONFIG_UEC_ETH2 #define CONFIG_SYS_UEC2_UCC_NUM 3 /* UCC4 */ #define CONFIG_SYS_UEC2_RX_CLK QE_CLK7 #define CONFIG_SYS_UEC2_TX_CLK QE_CLK8 #define CONIFG_SYS_UEC2_ETH_TYPEFAST_ETH #define CONFIG_SYS_UEC2_PHY_ADDR3 #define CONFIG_SYS_UEC2_INTERFACE_MODE ENET_100_MII #endif Thanks Christopher M. Fairfax Sr. Software Engineer Rockwell Collins +1 540-428-3344 +1 540-428-3301 cmfai...@rockwellcollins.com This message contains PRIVILEGED AND PROPRIETARY INFORMATION intended solely for the use of the addressee(s) named above. Any disclosure, distribution, copying or use of the information by others is strictly prohibited. If you have received this message in error, please advise the sender by immediate reply and delete the original message. Thank you. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] fix: missing autoconfig.mk from general Makefile
On 13:07 Tue 23 Jun , Mike Frysinger wrote: On Saturday 23 May 2009 15:42:36 Jean-Christophe PLAGNIOL-VILLARD wrote: at the first run of make we generate the autoconf.mk and autoconf.mk.dep if not already the case and we currently include only to .dep in order to use these autogenerated value we need to include it also evenif it's include in config.mk but it's done before there generation Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com --- Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 81a5cd0..7f3776e 100644 --- a/Makefile +++ b/Makefile @@ -475,6 +475,7 @@ $(obj)include/autoconf.mk: $(obj)include/config.h mv $...@.tmp $@ sinclude $(obj)include/autoconf.mk.dep +sinclude $(obj)include/autoconf.mk # else # !config.mk while i dont really understand your changelog, i think you're attempting to fix a problem i too have hit with Blackfin systems. but i just hacked around it in my tree (i posted this patch before but Wolfgang opposed it on the basis that no other arch had the problems Blackfin did, but apparently that is no longer true): http://git.denx.de/?p=u-boot/u-boot- blackfin.git;a=commitdiff;h=12ce98a697dde38aefe7131ce9a1b2e0e01640ad yes it's the same problem I guess and the solution I propose will for all boards normally Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] fec_imx27: driver for FEC Ethernet controller on i.MX27
-Original Message- From: Eric Lammerts [mailto:u-b...@lists.lammerts.org] Sent: Monday, June 15, 2009 3:59 PM To: Johan Cc: u-boot@lists.denx.de; Ilya Yanok Subject: Re: [U-Boot] [PATCH 3/7] fec_imx27: driver for FEC ethernet controller on i.MX27 On 06/15/09 10:01, Johan wrote: I have trouble using your patch together with our LogicPD iMX27 Litekit. Seems like the FEC driver does not work well. Here is some output from when I try to load files with tftp snip Loading: #T #T #T T# #T ##T T #T T # Retry count exceeded; starting again snip I have downloaded the imx27lite head from the u-boot testing branch. I have also tried to patch the u-boot-2009.06-rc3 branch with your patches, but it does not seem to be any different. Do you have any ideas what might be wrong? Did you have working ethernet before (with a different bootloader or in Linux)? Do you have the breakout board installed? I have the same board (but maybe an older revision; about a year old) and with the breakout board mounted my ethernet would behave the same way as yours. They routed the MII signals all the way to the headers on the breakout board, and that causes signal integrity problems. It could be that they fixed it on later revisions though (not sure). I'm using u-boot-v2, so I don't know anything about the u-boot fec driver. Eric I'm trying to debug ethernet problems on a custom iMX27 board with same LAN chip as the logicPD liteKit. I don't claim to be an expert, but it seems that in the fec driver posted by Ilya, the phy address for MII access is hard coded to a 0, whereas on the board it defaults to 0x1f. When I turned on DEBUG in fec_imx27.c, the MII reads always return all 1's. The phy works, but maybe by good fortune, not intent. Bill Cook c...@isgchips.com Imaging Solutions Group Inc; http://www.isgcameras.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] link error in MPC8313ERDB_NAND_33_config or MPC8313ERDB_NAND_66_config
On Tue, Jun 23, 2009 at 01:56:26PM +0800, wanjiutuan wrote: In LTIB， first I executed such command “make MPC8313ERDB_NAND_33_config； make”， There are some link errors in nand_spl, such as “undefined reference restgprXXX”, but for u-boot ,there is no problems. This list is for upstream u-boot -- we have no idea what u-boot is in your LTIB. Try head-of-git (or most recent upstream release, if you want something stable) and let us know if that doesn't work for you (and which specific version you tried, and which compiler and linker versions). Head-of-git builds for me, other than a warning to use 64-bit printf. Or, ask whoever gave you the LTIB. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Tue, Jun 23, 2009 at 06:33:53PM +0200, Detlev Zundel wrote: Also this is one of the objections worded on the mailing list, namely that such a cooperation will be impossible in the future if U-Boot moves to GPLv3. As a base for reasonable discussion, I think we need to evaluate those claims and back them up by actual figures. Only then the real effort needed to move and the potential loss of code immigration can be estimated. The NAND subsystem is from Linux and is GPL v2 only, as is the u-boot-specific NAND code in drivers/mtd/nand. nand_ecc.c is an exception, which not only has the or later language but also has an exception that makes it non-viral. env_nand.c is v2-or-later. cmd_nand.c has no explicit license. In summary: If you switch to v3, you lose much of NAND. Unless RMS volunteers to rewrite it. :-) Is there any chance of convincing those authors to change that? Apart from the the above reasons, currently most people who voiced their opinion (not too many right now) oppose the move. The reasoning seems to be that companies using U-Boot inside a commercial product consider it to be a neccessary precondition to only accept blessed firmware upgrades (my wording). What motivates this argument is not completely clear to me. Maybe it is fear of being liable as a product vendor to faulty sw upgrades. Regardless of what motivates it, people who sell hardware to such customers (and who also contribute to u-boot) may not want to risk losing that business by pushing GPLv3 on them. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Tuesday 23 June 2009 15:26:35 Scott Wood wrote: On Tue, Jun 23, 2009 at 06:33:53PM +0200, Detlev Zundel wrote: Apart from the the above reasons, currently most people who voiced their opinion (not too many right now) oppose the move. The reasoning seems to be that companies using U-Boot inside a commercial product consider it to be a neccessary precondition to only accept blessed firmware upgrades (my wording). What motivates this argument is not completely clear to me. Maybe it is fear of being liable as a product vendor to faulty sw upgrades. Regardless of what motivates it, people who sell hardware to such customers (and who also contribute to u-boot) may not want to risk losing that business by pushing GPLv3 on them. indeed. expecting businesses to push other peoples' agenda isnt realistic, especially when the conversation is pretty much a net customer loss for said businesses. customers arent going to appear because your business is now pushing GPLv3 instead of GPLv2, but they will certainly disappear. -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 v4 6/6] MX31: Add NAND SPL boot support to i.MX31 PDK board.
Hi 2009/6/22 Ulrich Gerster gerst...@dhbw-loerrach.de: Hello, I'm trying to boot from my board with a i.MX31 and small page (512Byte) NAND Flash. I applied the patches in v4 which introduce the CONFIG_PRELOADER macro. The only example I found where this macro is used is in part 6/6 of the patch. There a separate folder structure in nand_spl for the PDK Board is created. Could you describe the mode of operation of the CONFIG_PRELOADER macro and in particular NAND SPL? I'm not sure how to use this functionality in my case. The whole NAND booting procedure is described i http://lists.denx.de/pipermail/u-boot/2009-April/051826.html . That description is still valid with the addition that CONFIG_PRELOADER is now defined when compiling the NAND SPL (in step 2). Also nand_boot_mx31.c has been renamed to nand_boot_fsl_nfc.c. Regards, Magnus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add WATCHDOG_REFRESH() inside nand write and read
On Wed, Jun 17, 2009 at 08:13:38PM +0200, Giulio Benetti wrote: Add WATCHDOG_REFRESH() inside nand write and read Please send patches inline, not as attachments. Attachments are harder to feed into git, and in some e-mail clients are harder to quote in replies. Also, this should probably go in the inner loops of the NAND drivers, rather than just at the beginning of a command that could be long-running. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM] Bug-fix in drivers mtd nand Makefile
On Thu, Jun 18, 2009 at 06:41:03PM +0100, kevin.morf...@fearnside-systems.co.uk wrote: The S3C2410 NAND driver source file is included in the makefile instead of the object file. Signed-off-by: Kevin Morfitt kevin.morf...@fearnside-systems.co.uk --- drivers/mtd/nand/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 71dd5b9..7dfbeb5 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -42,7 +42,7 @@ COBJS-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_nand.o COBJS-$(CONFIG_NAND_FSL_UPM) += fsl_upm.o COBJS-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o COBJS-$(CONFIG_NAND_NOMADIK) += nomadik.o -COBJS-$(CONFIG_NAND_S3C2410) += s3c2410_nand.c +COBJS-$(CONFIG_NAND_S3C2410) += s3c2410_nand.o COBJS-$(CONFIG_NAND_S3C64XX) += s3c64xx.o COBJS-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o endif Applied to u-boot-nand-flash. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] mxc_nand: add nand driver for MX2/MX3
Hi
2009/6/23 Scott Wood scottw...@freescale.com:
On Mon, Jun 08, 2009 at 04:12:48AM +0400, Ilya Yanok wrote:
Driver for NFC NAND controller found on Freescale's MX2 and MX3
processors. Ported from Linux. Tested only with i.MX27 but should
works with other MX2 and MX3 processors too.
Signed-off-by: Ilya Yanok ya...@emcraft.com
+static u_char mxc_nand_read_byte(struct mtd_info *mtd)
+{
+ struct nand_chip *nand_chip = mtd-priv;
+ struct mxc_nand_host *host = nand_chip-priv;
+ uint8_t ret = 0;
+ uint16_t col, rd_word;
+ uint16_t __iomem *main_buf =
+ (uint16_t __iomem *)host-regs-main_area0;
+ uint16_t __iomem *spare_buf =
+ (uint16_t __iomem *)host-regs-spare_area0;
According to Magnus Lilja, the nand flash controller can only handle 32
bit read/write operations, any other size will cause an abort (or
something like that). But now we're accessing it as 16-bit?
I'm not sure if the controller allows 16 bit accesses or not, don't
remember if I've tried that. 8 bit accesses don't work. Also, I don't
know if it's the controller itself that can't cope with 8 bit accesses
or if it's the bus interface to the NFC block in i.MX31.
Regards, Magnus
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91sam9260/9263: add back up fot the rst(reset controller).
On Tue, Jun 23, 2009 at 12:46:50PM +0200, Sedji Gaouaou wrote: On the boards at91sam9260ek, at91sam9263ek and afed9260, the rstc register was set to 0 after being set to 500 ms for the PHY reset. Now if back up is enable it will be set to the saved value. The changelog message is not very clear. What means if backup is enabled ? I don't see anything in the patch which can be enabled or disabled... I think you meant something like: Do backup the old reset length and restore it after the MACB initialisation. + rstc = at91_sys_read(AT91_RSTC_MR); [...] /* Restore NRST value */ at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY | - AT91_RSTC_ERSTL | (0x0 8) | + (rstc) | AT91_RSTC_URSTEN); Also, I don't like this: you backup in 'rstc' the _whole_ contents of the MR register (including for example the URSTEN bit), but on restore you still construct a bit mask... In order to be consistent, I would do either: rstc = at91_sys_read(AT91_RSTC_MR); ... at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY | rstc); or rstc = at91_sys_read(AT91_RSTC_MR) AT91_RSTC_ERSTL; ... at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY | rstc | AT91_RSTC_URSTEN); Not sure what version would be best though... Stelian. -- Stelian Pop stel...@popies.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8360ERDK U-Boot - Broadcom Gigabit Ethernet removal
PS The RX errors generated by switching from the Broadcom Ethernet chips to the National Ethernet chips are specifically RxBD_CRCERR and RxBD_NO (defined in uec.h). These errors are frame CRC error and Non-octet align errors respectively. Thanks. Christopher M. Fairfax Sr. Software Engineer Rockwell Collins +1 540-428-3344 +1 540-428-3301 cmfai...@rockwellcollins.com This message contains PRIVILEGED AND PROPRIETARY INFORMATION intended solely for the use of the addressee(s) named above. Any disclosure, distribution, copying or use of the information by others is strictly prohibited. If you have received this message in error, please advise the sender by immediate reply and delete the original message. Thank you. Christopher M Fairfax/USA/RockwellCollins 06/23/2009 01:35 PM To u-boot@lists.denx.de cc avoront...@ru.mvista.com Subject MPC8360ERDK U-Boot - Broadcom Gigabit Ethernet removal Hi, I'm trying to completely remove the 2 gigabit ethernets from my U-Boot (as they are depopulated on my target). I want to use the other 2 ethernet ports as FSL UEC0 and FSL UEC1. I've removed the UCC1 and UCC2 entries from the qe_iop_conf_tab in mpc8360erdk.c and updated the corresponding macros in MPC8360ERDK.h. The transmits seem to work. I'm able to communicate from the target to a TFTP server on a PC. However, the RX to the target is not working. I get FSL UEC: Rx error messages. Any ideas/suggestions as to what I need to do to get the RX to work? Also, do I need to define CFG_CMD_MII and/or CFG_MII, so that miiphy_register() is called in uec.c Here are my new macro definitions in MPC8360ERDK.h: #define CONFIG_UEC_ETH1 /* GETH1 */ #ifdef CONFIG_UEC_ETH1 #define CONFIG_SYS_UEC1_UCC_NUM 6 /* UCC7 */ #define CONFIG_SYS_UEC1_RX_CLK QE_CLK19 #define CONFIG_SYS_UEC1_TX_CLK QE_CLK20 #define CONIFG_SYS_UEC1_ETH_TYPEFAST_ETH #define CONFIG_SYS_UEC1_PHY_ADDR1 #define CONFIG_SYS_UEC1_INTERFACE_MODE ENET_100_MII #endif #define CONFIG_UEC_ETH2 /* GETH2 */ #ifdef CONFIG_UEC_ETH2 #define CONFIG_SYS_UEC2_UCC_NUM 3 /* UCC4 */ #define CONFIG_SYS_UEC2_RX_CLK QE_CLK7 #define CONFIG_SYS_UEC2_TX_CLK QE_CLK8 #define CONIFG_SYS_UEC2_ETH_TYPEFAST_ETH #define CONFIG_SYS_UEC2_PHY_ADDR3 #define CONFIG_SYS_UEC2_INTERFACE_MODE ENET_100_MII #endif Thanks Christopher M. Fairfax Sr. Software Engineer Rockwell Collins +1 540-428-3344 +1 540-428-3301 cmfai...@rockwellcollins.com This message contains PRIVILEGED AND PROPRIETARY INFORMATION intended solely for the use of the addressee(s) named above. Any disclosure, distribution, copying or use of the information by others is strictly prohibited. If you have received this message in error, please advise the sender by immediate reply and delete the original message. Thank you. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Device tree on ppc board
Hi, I work on a custom board, MPC8248 based (my reference BSP was MPC8260ADS), with uboot 1.1.4 and linux 2.6.11, and works perfectly. We have to pass to linux 2.6.27, and it is just the version from which ppc and powerpc has been merged, and device tree the unique way to pass 'bdinfo'. The uboot version can't be more than 1.1.6, the linux must be 2.6.27, and I can't find the information if it's compatible. Can anybody affirm me if it's possible, and how to do it in linux 1.1.4 ? How do we change the bdinfo structure header to device tree, is there any board which uses this feature ? Thank you ! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Device tree on ppc board
Olivier DAVID wrote: I work on a custom board, MPC8248 based (my reference BSP was MPC8260ADS), with uboot 1.1.4 and linux 2.6.11, and works perfectly. We have to pass to linux 2.6.27, and it is just the version from which ppc and powerpc has been merged, It was merged quite a bit earlier, that's just when the old fork was finally discarded. and device tree the unique way to pass 'bdinfo'. The uboot version can't be more than 1.1.6, Why not? the linux must be 2.6.27, Why 2.6.27 and not, say, 2.6.30? You may have problems with PCI DMA in 2.6.27, for example. In general, it's best to go with the latest unless you have a specific reason otherwise. and I can't find the information if it's compatible. You can boot using cuImage if you must stay with an old u-boot. Add cuImage entries for your board in arch/powerpc/boot/Makefile and arch/powerpc/boot/wrapper, then make zImage. Can anybody affirm me if it's possible, and how to do it in linux 1.1.4 ? How do we change the bdinfo structure header to device tree, is there any board which uses this feature ? mpc8272ads is probably the closest board to yours; you could use its device tree as an example. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v4] KB9202: Add NAND support
On Thu, Jun 11, 2009 at 08:46:54PM +0200, Matthias Kaehlcke wrote:
Add NAND support for the KwikByte KB9202
Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net
--
The git separator is three dashes, not two.
Changes:
- moved driver to drivers/mtd/nand/
- use i/o accessors
- don't check for ATL custom board
- removed unnecessary cast
- don't use magic numbers
drivers/mtd/nand/Makefile|1 +
drivers/mtd/nand/kb9202_nand.c | 151
++
include/asm-arm/arch-at91rm9200/AT91RM9200.h |2 +
include/configs/kb9202.h | 11 ++-
I get conflicts in kb9202.h. Is this against an arch tree, or does it
need to be respun?
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 471cd6b..d2f3e61 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -44,6 +44,7 @@ COBJS-$(CONFIG_NAND_NOMADIK) += nomadik.o
COBJS-$(CONFIG_NAND_S3C2410) += s3c2410_nand.c
COBJS-$(CONFIG_NAND_S3C64XX) += s3c64xx.o
COBJS-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
+COBJS-$(CONFIG_NAND_KB9202) += kb9202_nand.o
Wolfgang likes these things kept in alphabetical order.
+int board_nand_init(struct nand_chip *nand)
+{
+ unsigned int value;
+
+ nand-ecc.mode = NAND_ECC_SOFT;
+ nand-options = ~NAND_BUSWIDTH_16;
Why would you need to clear this? It's the board driver that sets it in
the first place (if applicable).
+ /* setup nand flash access (allow ample margin) */
+ /* 4 wait states, 1 setup, 1 hold, 1 float for 8-bit device */
+ writel(AT91C_SMC2_WSEN | KB9202_SMC2_NWS | KB9202_SMC2_TDF |
+ AT91C_SMC2_DBW_8 | KB9202_SMC2_RWSETUP |
KB9202_SMC2_RWHOLD,
+ AT91C_SMC_CSR3);
+
Line length. Did you perhaps use a tab size other than 8?
Otherwise, ACK.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On 15:41 Tue 23 Jun , Mike Frysinger wrote: On Tuesday 23 June 2009 15:26:35 Scott Wood wrote: On Tue, Jun 23, 2009 at 06:33:53PM +0200, Detlev Zundel wrote: Apart from the the above reasons, currently most people who voiced their opinion (not too many right now) oppose the move. The reasoning seems to be that companies using U-Boot inside a commercial product consider it to be a neccessary precondition to only accept blessed firmware upgrades (my wording). What motivates this argument is not completely clear to me. Maybe it is fear of being liable as a product vendor to faulty sw upgrades. Regardless of what motivates it, people who sell hardware to such customers (and who also contribute to u-boot) may not want to risk losing that business by pushing GPLv3 on them. indeed. expecting businesses to push other peoples' agenda isnt realistic, especially when the conversation is pretty much a net customer loss for said businesses. customers arent going to appear because your business is now pushing GPLv3 instead of GPLv2, but they will certainly disappear. 200% agree I can assure you that today If we switch the V2 to the v3 we will lose a lot of customers and soc that use secure boot as example which is not a progression but a problematic regression And force to give the private key which use to sign the code is not reallist it's a security flaw so U-Boot will close itself to a lots of business and customers Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] fix: missing autoconfig.mk from general Makefile
On 00:40 Wed 24 Jun , Shinya Kuribayashi wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: | ifneq (,$(CONFIG_CPU_LITTLE_ENDIAN)) | PLATFORM_CPPFLAGS+= $(shell $(CC) -dumpmachine |... | else | PLATFORM_CPPFLAGS+= $(shell $(CC) -dumpmachine |... | endif | | PLATFORM_LDFLAGS += -EL does work. ??? you compile it as big endian to link it as little ??? Ah, above was just a sample only intended for LE build. Then, what needs to be fixed finally? Can't we have PLATFORM_LDFLAGS conditionally configured? or is this a U-Boot's build system issue? it a u-boot build system issues we need to include the autoconf.mk after generate it to use it in the GENERAL Makefile which is the case here for final link I know that, but $(obj)include/autoconf.mk will be included by $(TOPDIR)/config.mk. Then what a rationale for including it redundantly by $(TOPDIR/Makefile? I assume that Wolfgang is probably requesting the explanation for that. for sub Makefile yes as you re-include it via including config.mk for the first Makefile no as you generate it in you need to include it just after to be able to use it as you include the config.mk before generate it Autoconf.mk is expected to be generated *before* $(TOPDIR)/config.mk is included, right? no not in the general Makefile Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot timer example crashes on EP88xC
Hello, I am using ELDK 4.2 and U-Boot 2009.03 on an EP88xC rev1.1 board (MPC885 cpu) and am trying to get the example apps working (the ones that come with U-Boot) following instructions on http://www.denx.de/wiki/view/DULG/UBootStandalone#Section_5.12.2.;. examples/hello_world.bin worked fine: = tftp 4 ep88x_helloworld Trying FEC ETHERNET Using FEC ETHERNET device TFTP from server 10.0.54.129; our IP address is 10.0.54.150 Filename 'ep88x_helloworld'. Load address: 0x4 Loading: ## done Bytes transferred = 262980 (40344 hex) = go 40004 ## Starting application at 0x00040004 ... Example expects ABI version 4 Actual U-Boot ABI version 4 Hello World argc = 1 argv[0] = 40004 argv[1] = NULL Hit any key to exit ... ## Application terminated, rc = 0x0 = But things didn't go too smoothly with the examples/timer.bin app: = tftp 4 ep88x_timerdemo Trying FEC ETHERNET Using FEC ETHERNET device TFTP from server 10.0.54.129; our IP address is 10.0.54.150 Filename 'ep88x_timerdemo'. Load address: 0x4 Loading: ## done Bytes transferred = 263740 (4063c hex) = go 40004 ## Starting application at 0x00040004 ... .Bus Fault @ 0x00040038, fixup 0x Machine check in kernel mode. Caused by (from msr): regs 03f70cd8 Unknown values in msr NIP: 00040038 XER: A000B700 LR: 00040030 REGS: 03f70cd8 TRAP: 0200 DAR: C4B38E78 MSR: 9002 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00 GPR00: 0003 03F70DC8 03F70F8C 03F70C84 03F70C78 03F70C00 GPR08: 0041 C4B38E78 03FE2EBC 0030 0001 03FFF000 GPR16: 03FF58BC 03FF82C8 GPR24: 03FB11C8 03FB127C 0001 00088608 0002 Call backtrace: machine check ### ERROR ### Please RESET the board ### Does anybody have any suggestions for what may be wrong here? Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] mxc-mmc: sdhc host driver for MX2 and MX3 proccessor
Hi Ilya, This is a port of Linux driver for SDHC host controller hardware found on Freescale's MX2 and MX3 processors. Uses new generic MMC framework (CONFIG_GENERIC_MMC) and it looks like there are some problems with a framework (at least on LE cpus). Some of these problems are addressed in the following patches. Have you tested this driver interfaces to load a kernel image(uImage) from the SD card? Does it work for you? Thanks, Alfred. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] minor fixes for mvBL-M7 and use of common code
On Mon, 22 Jun 2009 15:50:29 +0200 André Schwarz andre.schw...@matrix-vision.de wrote: Hello André, X-Mailer: Evolution 2.26.1 ... [0001-rebased-mvBLM7-with-minor-fixes.patch text/x-patch (8.2KB)] please use Insert-Text File... (Alt-n x) to insert the patch. -#define _IO_BASE 0x - the above is the reason for the below: Applying: minor fixes for mvBL-M7 and use of common code error: patch failed: include/configs/MVBLM7.h:193 error: include/configs/MVBLM7.h: patch does not apply Patch failed at 0001 minor fixes for mvBL-M7 and use of common code ...and because I have the remove _IO_BASE and KSEG1ADDR from board configuration files patch already applied, and probably justifiably so, since it arrived earlier to the list than your patch. btw, I also get this at build time: Configuring for MVBLM7 board... mv_common.c: In function 'mv_load_fpga': mv_common.c:93: warning: implicit declaration of function 'fpga_load' So did you want 1-3/3 of these to bypass u-boot-mpc83xx and go straight to WD? I'm asking because there's overlap with the mpc5xxx maintainer (WD himself apparently) in this patchseries. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] 88e61xx driver in u-boot
Hi, I am in the midst of bringing up a board using the 88E6161 chip
and was looking at your u-boot driver as an example of how to set it
up (still writing simple tests loaded via JTAG, not the full u-boot).
Our board uses the indirect method of writing to the MII bus
registers, and I think there may be a bug in the indirect version of
mv88e61xx_rd_phy(). In the function, the command written into the SMI
indirect command register is:
86miiphy_write(name, mii_dev_addr, 0x0,
87 reg_ofs | (phy_adr 5) | (1 10) | (1
12) | (1
88
15));
The part that looks wrong is the 1 10 (the SMIOp field).
According to the datasheet table 35, for a read to be performed inside
the chip it should be 2 10. Probably cut and pasted from the
mv88e61xx_wr_phy() above.
I also wondered about this snippet of code:
55 static void mv88e61xx_wr_phy(char *name, u32 phy_adr, u32
reg_ofs, u16 data)
56 {
57 u16 reg;
58 u32 mii_dev_addr;
59
60 /* command to read PHY dev address */
61 if (!miiphy_read(name, 0xEE, 0xEE, mii_dev_addr)) {
62 printf(Error..could not read PHY dev address\n);
63return;
64 }
I don't see anything in the 88E6161 switch itself that would respond
at those 0xEE addresses (IIRC the MII bus only provides for 5 bits of
register and phy address). Is this something specific to the
board/SoC you were running the switch with and/or it's miiphy_read
implementation?
As far as I can tell, what is needed is to set mii_dev_addr to the
address set by the ADDR[4:0] chip config pins, which would see to be a
board specific item, and shouldn't be in the generic driver. This
would seem like a good candidate for something that is passed in via
the mv88e61xx_config structure.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM 1/2] Add support for the Embest SBC2440-II Board
On 14:04 Mon 22 Jun , Scott Wood wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: no as you add the nand in this patch the nand need to be add in a seperate patch, this one need to only add the s3c2440 support and the nand will be handle by Scott the nand Maintainer If a NAND patch is sandwiched in the middle of other patches that need to go via an arch tree, and depends on some of those patches, I'd rather ack the NAND bits to go through the arch tree rather than try to merge everything separately while still maintaining dependencies. In that case, keeping the NAND bits in a separate patch is nice, but not mandatory IMHO. To simplify bisect and merge I prefer to have the nand adding in an other patch Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] A320: driver for FTRTC010 real time clock
+
+static volatile struct ftrtc010 *rtc = (struct ftrtc010
*)CONFIG_SYS_RTC_BASE;
+
+static void ftrtc_enable (void)
you use it at one please only the reset
+{
+ rtc-cr = cpu_to_le32 (FTRTC010_CR_ENABLE);
so please move this code there
+}
+
+/*
+ * return current time in seconds
+ */
+static unsigned long ftrtc_time (void)
+{
+ unsigned long day;
+ unsigned long hour;
+ unsigned long minute;
+ unsigned long second;
+ unsigned long second2;
+
+ do {
+ second = le32_to_cpu (rtc-sec);
please use proper accessor
readl/writel
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] A320: Add support for Faraday A320 evaluation board
On 21:35 Tue 23 Jun , Po-Yu Chuang wrote:
This patch adds support for A320 development board from Faraday. This board
uses FA526 processor by default and has 512kB and 32MB NOR flash, 64M RAM.
FA526 is an ARMv4 processor and uses the ARM920T source in this patch.
Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com
---
please use git
please add a MAKEALL and MAINTAINER entry
Index: Makefile
===
RCS file: /usr/local/cvsroot/ctd/u-boot-2009.06/Makefile,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile
--- Makefile 15 Jun 2009 06:47:34 - 1.1.1.1
+++ Makefile 23 Jun 2009 06:45:36 -
@@ -2940,6 +2940,13 @@
@$(MKCONFIG) $(@:_config=) arm s3c44b0 B2 dave
#
+## Faraday A320 Systems
+#
+
+a320_config : unconfig
+ @$(MKCONFIG) $(@:_config=) arm arm920t a320 faraday
920T but you write 926ejs in the config.mk?
+
+#
## ARM720T Systems
#
snip
Index: board/faraday/a320/board.c
===
RCS file: board/faraday/a320/board.c
diff -N board/faraday/a320/board.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ board/faraday/a320/board.c23 Jun 2009 06:06:34 - 1.3
@@ -0,0 +1,120 @@
+/*
+ * (C) Copyright 2009 Faraday Technology
+ * Po-Yu Chuang ratb...@faraday-tech.com
+ *
+ * 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 common.h
+#include netdev.h
+#include rtc.h
+
+#include ftsmc.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define FLASH_BANK0_CONFIG (FTSMC_BANK_ENABLE |\
+ FTSMC_BANK_BASE(PHYS_FLASH_1) |\
+ FTSMC_BANK_SIZE_1M | \
+ FTSMC_BANK_MBW_8)
+
+#define FLASH_BANK0_TIMING (FTSMC_TPR_RBE |\
+ FTSMC_TPR_AST(3) | \
+ FTSMC_TPR_CTW(3) | \
+ FTSMC_TPR_ATI(0xf) | \
+ FTSMC_TPR_AT2(3) | \
+ FTSMC_TPR_WTC(3) | \
+ FTSMC_TPR_AHT(3) | \
+ FTSMC_TPR_TRNA(0xf))
+
+#define FLASH_BANK1_CONFIG (FTSMC_BANK_ENABLE |\
+ FTSMC_BANK_BASE(PHYS_FLASH_2) |\
+ FTSMC_BANK_SIZE_32M | \
+ FTSMC_BANK_MBW_32 )
+
+#define FLASH_BANK1_TIMING (FTSMC_TPR_AST(3) | \
+ FTSMC_TPR_CTW(3) | \
+ FTSMC_TPR_ATI(0xf) | \
+ FTSMC_TPR_AT2(3) | \
+ FTSMC_TPR_WTC(3) | \
+ FTSMC_TPR_AHT(3) | \
+ FTSMC_TPR_TRNA(0xf))
please move this to config header
+
+extern int timer_init (void);
no-need please remove
+
+/*
+ * Miscellaneous platform dependent initialisations
+ */
+
+static void
+ftsmc_setup_bank (int bank, unsigned int config, unsigned int timing)
is this board or soc specific?
+{
+ volatile struct ftsmc *smc = (struct ftsmc *)CONFIG_SYS_SMC_BASE;
+
+ if (bank 0 || bank 3) {
+ printf (bank # %d invalid\n, bank);
+ return;
+ }
+
+ smc-bank[bank].cr = cpu_to_le32 (config);
+ smc-bank[bank].tpr = cpu_to_le32 (timing);
please use proper accessor everywhere
+}
+
+/* initialize Flash */
+static void ftsmc_init (void)
+{
+ ftsmc_setup_bank (0, FLASH_BANK0_CONFIG, FLASH_BANK0_TIMING);
+ ftsmc_setup_bank (1, FLASH_BANK1_CONFIG, FLASH_BANK1_TIMING);
+}
+
+int board_init (void)
+{
+ gd-bd-bi_arch_number = MACH_TYPE_FARADAY;
+
+ ftsmc_init ();
+ rtc_reset ();
do you really need this so early the rtc and enable everytime?
+ timer_init ();
no-need pelase remove
+ return 0;
+}
[U-Boot] [PATCH] ppc4xx: Fixed PPC4xx debug compilation error in uic.c
This patch fixes a debug compilation error for PPC4xx platforms, all other architectures are not affected by this change. The 'handler' pointer was undefined. The fix is exercised and has effect only if DEBUG is defined. Signed-off-by: Alessio Centazzo acpa...@yahoo.com --- cpu/ppc4xx/uic.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cpu/ppc4xx/uic.c b/cpu/ppc4xx/uic.c index a95d1cb..0ce7a93 100644 --- a/cpu/ppc4xx/uic.c +++ b/cpu/ppc4xx/uic.c @@ -164,7 +164,7 @@ void pic_irq_enable(unsigned int vec) else if (vec = 96) mtdcr(uic3er, mfdcr(uic3er) | UIC_MASK(vec)); -debug(Install interrupt for vector %d == %p\n, vec, handler); +debug(Enable interrupt for vector %d\n, vec); } void pic_irq_disable(unsigned int vec) -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4cc: Fixed compilation warning in 4xx_enet.c
This patch fixes a compilation warning for some Ethernet PHY-less PPC4xx platforms (440SPE based ones) and a potential compilation error for 440SP platforms (use of undefined 'ethgroup' variable). In the original code and in case of 440SPE platforms, 'ethgroup' is initialized to -1 and never modified. Later in the function, within an #ifdef statement, an 'if statement' executes code only if 'ethgroup' is set to 4, therefore it is harmless to avoid executing the 'if statement' by removing the CONFIG_440SPE from the affected #ifdefs. In case of 440SP platforms with on-board Ethernet PHY, 'ethgroup' is undefined but used (there are not such platforms in the repository yet). All other architectures are not affected by this change. This is the current warning message with a Ethernet PHY-less 440SPE platform build (there is not such platform in the repository yet): 4xx_enet.c: In function 'ppc_4xx_eth_init': 4xx_enet.c:880: warning: unused variable 'ethgroup' Signed-off-by: Alessio Centazzo acpa...@yahoo.com --- drivers/net/4xx_enet.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/net/4xx_enet.c b/drivers/net/4xx_enet.c index 587605d..b49121c 100644 --- a/drivers/net/4xx_enet.c +++ b/drivers/net/4xx_enet.c @@ -870,7 +870,7 @@ static int ppc_4xx_eth_init (struct eth_device *dev, bd_t * bis) defined(CONFIG_405EX) u32 opbfreq; sys_info_t sysinfo; -#if defined(CONFIG_440GX) || defined(CONFIG_440SPE) || \ +#if defined(CONFIG_440GX) \ defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \ defined(CONFIG_460EX) || defined(CONFIG_460GT) || \ defined(CONFIG_405EX) @@ -1119,7 +1119,6 @@ static int ppc_4xx_eth_init (struct eth_device *dev, bd_t * bis) #if defined(CONFIG_440GX) || \ defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \ -defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \ defined(CONFIG_460EX) || defined(CONFIG_460GT) || \ defined(CONFIG_405EX) -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc83xx: USB: fix: access of ehci struct elements
It fixes the access to the 'ehci' struct elements for mpc83xx which
should have been taken care of in 4ef01010aa4799c759d75e67007fdd3a38c88c8a
Sorry about that.
Signed-off-by: Vivek Mahajan vivek.maha...@freescale.com
---
cpu/mpc83xx/cpu_init.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpu/mpc83xx/cpu_init.c b/cpu/mpc83xx/cpu_init.c
index 414565c..03b6c86 100644
--- a/cpu/mpc83xx/cpu_init.c
+++ b/cpu/mpc83xx/cpu_init.c
@@ -303,11 +303,11 @@ void cpu_init_f (volatile immap_t * im)
struct usb_ehci *ehci = (struct usb_ehci *)CONFIG_SYS_MPC8xxx_USB_ADDR;
/* Configure interface. */
- setbits_be32((void *)ehci-control, REFSEL_16MHZ | UTMI_PHY_EN);
+ setbits_be32(ehci-control, REFSEL_16MHZ | UTMI_PHY_EN);
/* Wait for clock to stabilize */
do {
- temp = in_be32((void *)ehci-control);
+ temp = in_be32(ehci-control);
udelay(1000);
} while (!(temp PHY_CLK_VALID));
#endif
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] A320: driver for FTRTC010 real time clock
Dear Jean-Christophe PLAGNIOL-VILLARD,
2009/6/24 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com:
+
+static volatile struct ftrtc010 *rtc = (struct ftrtc010
*)CONFIG_SYS_RTC_BASE;
+
+static void ftrtc_enable (void)
you use it at one please only the reset
Sorry, I don't understand what do you mean
+{
+ rtc-cr = cpu_to_le32 (FTRTC010_CR_ENABLE);
so please move this code there
+}
+
+/*
+ * return current time in seconds
+ */
+static unsigned long ftrtc_time (void)
+{
+ unsigned long day;
+ unsigned long hour;
+ unsigned long minute;
+ unsigned long second;
+ unsigned long second2;
+
+ do {
+ second = le32_to_cpu (rtc-sec);
please use proper accessor
readl/writel
Should I use
second = readl(rtc-sec);
or just
second = rtc-sec;
Best regards,
Po-Yu Chuang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] A320: Add support for Faraday A320 evaluation board
Dear Jean-Christophe PLAGNIOL-VILLARD,
Thank you for your detailed review
2009/6/24 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com:
please use git
I cannot access git in the company, but I will try that at home.
please add a MAKEALL and MAINTAINER entry
ok, I will fix them
RCS file: /usr/local/cvsroot/ctd/u-boot-2009.06/Makefile,v
+a320_config : unconfig
+ @$(MKCONFIG) $(@:_config=) arm arm920t a320 faraday
920T but you write 926ejs in the config.mk?
please see the explanation below
diff -N board/faraday/a320/board.c
+#define FLASH_BANK0_CONFIG (FTSMC_BANK_ENABLE | \
+ FTSMC_BANK_BASE(PHYS_FLASH_1) | \
+ FTSMC_BANK_SIZE_1M | \
+ FTSMC_BANK_MBW_8)
+
+#define FLASH_BANK0_TIMING (FTSMC_TPR_RBE | \
+ FTSMC_TPR_AST(3) | \
+ FTSMC_TPR_CTW(3) | \
+ FTSMC_TPR_ATI(0xf) | \
+ FTSMC_TPR_AT2(3) | \
+ FTSMC_TPR_WTC(3) | \
+ FTSMC_TPR_AHT(3) | \
+ FTSMC_TPR_TRNA(0xf))
+
+#define FLASH_BANK1_CONFIG (FTSMC_BANK_ENABLE | \
+ FTSMC_BANK_BASE(PHYS_FLASH_2) | \
+ FTSMC_BANK_SIZE_32M | \
+ FTSMC_BANK_MBW_32 )
+
+#define FLASH_BANK1_TIMING (FTSMC_TPR_AST(3) | \
+ FTSMC_TPR_CTW(3) | \
+ FTSMC_TPR_ATI(0xf) | \
+ FTSMC_TPR_AT2(3) | \
+ FTSMC_TPR_WTC(3) | \
+ FTSMC_TPR_AHT(3) | \
+ FTSMC_TPR_TRNA(0xf))
please move this to config header
ok, I will fix them
+
+extern int timer_init (void);
no-need please remove
ok
+ smc-bank[bank].cr = cpu_to_le32 (config);
+ smc-bank[bank].tpr = cpu_to_le32 (timing);
please use proper accessor everywhere
Should I use
writel(config, smc-bank[bank].cr);
or
smc-bank[bank].cr = config;
+int board_init (void)
+{
+ gd-bd-bi_arch_number = MACH_TYPE_FARADAY;
+
+ ftsmc_init ();
+ rtc_reset ();
do you really need this so early the rtc and enable everytime?
sorry, I don't understand what do you mean.
+ timer_init ();
no-need pelase remove
ok
+int interrupt_init (void)
+{
+ /* nothing happens here - we don't setup any IRQs */
+ return (0);
+}
no-need please remove
It looks like interrupt_init is an soc function, I will put it to the soc code.
diff -N board/faraday/a320/config.mk
+# Faraday A320 board with FA526/FA626TE/ARM926EJ-S cpus
??
Index: board/faraday/a320/ftahbc.h
Index: board/faraday/a320/ftpmu.h
Index: board/faraday/a320/ftsdmc.h
Index: board/faraday/a320/ftsmc.h
Index: board/faraday/a320/fttmr.h
If I undersand correctly all those header are soc specific not board specific
as the timer code
so please move the header to
include/asm-arm/arch-faraday or your soc familiy name
and the code to
cpu/armxxx/faraday/
We have an SOC called a320 (so does the evaluation board) which has an
armv4 cpu called fa526.
We can overdrive (with daughter board) it with a different cpu such as
arm926ej-s.
At first, I created cpu/fa526 and copy the cpu stuff from arm920t.
Then I found that it is not a good
idea to duplicate code, so I reused cpu/arm920t.
If I should create an SOC directory, where should I place it?
cpu/fa526/a320 ? but this duplicates cpu code
cpu/arm920t/a320 ? but it is not arm920t in fact
cpu/arm926ejs/a320? but it is not arm926ejs by default
diff -N board/faraday/a320/lowlevel_init.S
+/*
+ * Memory Mapping
+ */
+#define CONFIG_SYS_ROM_DEFAULT 0x
+#define CONFIG_SYS_SDRAM_DEFAULT 0x1000
+#define CONFIG_SYS_SDRAM_REMAPPED PHYS_SDRAM_1 /* remap location */
I guess this board specific too
yes
+/*
+ * numeric 7 segment display
+ */
+.macro led, num, rtmp1, rtmp2
+ mov \rtmp1, #\num
+ ldr \rtmp2, =CONFIG_SYS_DEBUG_LED
+ str \rtmp1, [\rtmp2]
+.endm
please use write32
ok, I will fix this
+ /*
+ * copy U-Boot to RAM
+ */
+copy_code:
+ ldr r0, =CONFIG_SYS_ROM_DEFAULT /* r0 - source address */
+ ldr r1, =CONFIG_SYS_SDRAM_DEFAULT /* r1 - target address */
+
+ ldr r2, .LC5
+ ldr r3, .LC6
+ sub r2, r3, r2 /* r2 - size of armboot */
+ add r2, r0, r2 /* r2 - source end address */
+
+copy_loop:
+ ldmia r0!, {r3-r10} /* copy from source address [r0] */
+ stmia r1!, {r3-r10} /* copy to target address [r1] */
+ cmp r0, r2 /*
