Re: [U-Boot-Users] [PATCH] (Resubmit) ADD ARM AMBA PL031 RTCSupport
Hi j,
Could you please reply so that i can submit a reformatted patch if
required.
First your patch is line wrapped by your mailler.
That's why i had also attached the respective patch file. that i
generated using git-diff command.
Secondly please be care ful of the 80 chars limits and the
whitespace.
Regarding the white space, i am little confused abt this as i couldn't
find it in my patch.
can u please let me know where it exists.
Are you going to add a board which will use it?
Right now i am using it on arm Versatile board. Should i send a patch to
that also
Also,
I used below command to generate the diff.
It says that 31 files have changed in this directory whereas only 1
files is changed and 1 file is added.
Kindly help me to correct the same. Right now i have manually changed it
in the patch file.
$ git-diff -p --summary --stat u-boot-1.3.3/drivers/rtc/
uboot/drivers/rtc/
Regards
Gururaja
Signed off by: Gururaja Hebbar [EMAIL PROTECTED]
- Add support to the ARM AMBA PL031 RTC Chip.
- remove the call to rtc_init from lib_arm/board.c boot sequence as per
wd advice.
- check for pl031 rtc initialization. Initialize if it hasnt yet.
{u-boot-1.3.3 = uboot}/drivers/rtc/Makefile |1 +
/dev/null = uboot/drivers/rtc/rtc_pl031.c| 121
+
2 files changed, 122 insertions(+), 0 deletions(-)
create mode 100644 uboot/drivers/rtc/rtc_pl031.c
diff --git a/u-boot-1.3.3/drivers/rtc/Makefile
b/uboot/drivers/rtc/Makefile
index 2e0c118..f888a31 100644
--- a/u-boot-1.3.3/drivers/rtc/Makefile
+++ b/uboot/drivers/rtc/Makefile
@@ -56,6 +56,7 @@ COBJS-y += rs5c372.o
COBJS-y += rx8025.o
COBJS-y += s3c24x0_rtc.o
COBJS-y += x1205.o
+COBJS-y += rtc_pl031.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/dev/null b/uboot/drivers/rtc/rtc_pl031.c
new file mode 100644
index 000..77b550b
--- /dev/null
+++ b/uboot/drivers/rtc/rtc_pl031.c
@@ -0,0 +1,121 @@
+/*
+ * (C) Copyright 2008
+ * Gururaja Hebbar [EMAIL PROTECTED]
+ *
+ * reference linux-2.6.20.6/drivers/rtc/rtc-pl031.c
+ *
+ * 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 common.h
+#include command.h
+#include rtc.h
+
+#if defined(CONFIG_RTC_PL031) defined(CONFIG_CMD_DATE)
+
+#ifndef CFG_RTC_PL031_BASE
+#error CFG_RTC_PL031_BASE is not defined!
+#endif
+
+/*
+ * Register definitions
+ */
+#defineRTC_DR 0x00/* Data read register */
+#defineRTC_MR 0x04/* Match register */
+#defineRTC_LR 0x08/* Data load register */
+#defineRTC_CR 0x0c/* Control register */
+#defineRTC_IMSC0x10/* Interrupt mask and set
register */
+#defineRTC_RIS 0x14/* Raw interrupt status register
*/
+#defineRTC_MIS 0x18/* Masked interrupt status
register */
+#defineRTC_ICR 0x1c/* Interrupt clear register */
+
+#define RTC_CR_MIE (1 0)
+
+#defineRTC_WRITE_REG(addr, val)(*(volatile unsigned int
*)(CFG_RTC_PL031_BASE + (addr)) = (val))
+#defineRTC_READ_REG(addr) (*(volatile unsigned int
*)(CFG_RTC_PL031_BASE + (addr)))
+
+static int pl031_initted = 0;
+
+/* Enable RTC Start in Control register*/
+void rtc_init(void)
+{
+ RTC_WRITE_REG(RTC_CR,RTC_CR_MIE);
+
+ pl031_initted = 1;
+}
+
+/*
+ * Reset the RTC. We set the date back to 1970-01-01.
+ */
+void rtc_reset(void)
+{
+ RTC_WRITE_REG(RTC_LR,0x00);
+ if(!pl031_initted)
+ rtc_init();
+}
+
+/*
+ * Set the RTC
+*/
+void rtc_set(struct rtc_time *tmp)
+{
+ unsigned long tim;
+
+ if(!pl031_initted)
+ rtc_init();
+
+ if (tmp == NULL) {
+ puts(Error setting the date/time\n);
+ return;
+ }
+
+ /* Calculate number of seconds this incoming time represents */
+ tim = mktime(tmp-tm_year, tmp-tm_mon, tmp-tm_mday,
+ tmp-tm_hour, tmp-tm_min, tmp-tm_sec);
+
+ RTC_WRITE_REG(RTC_LR,tim);
+}
+
+/*
+ * Get the current time from the RTC
+ */
+int rtc_get(struct rtc_time *tmp)
+{
+ ulong tim;
+
+ if(!pl031_initted)
+
[U-Boot-Users] Linux not booting and jffs2 FS not mounting
Hello All, I have mpc8313erdb evaluation board ... now I am trying to boot it from NAND Flash (32MB Flash) ... I am able to get u-boot prompt ... but the linux kernel is not booting and so filesystem is not mounting ... It says : No filesystem could mount root, Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Rebooting in 180 seconds what is going wrong ? ? ? Please acknowledge ... thank you ... Kind Regards, Vijay Nikam - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] (Resubmit) ADD ARM AMBA PL031 RTCSupport
Hi, Are you going to add a board which will use it? Right now i am using it on arm Versatile board. Should i send a patch to that also If you do I can test it Regards Peter Please find attached my changes to arm versatile config board file to enable rtc module This is for test only. If you find it acceptable then i will send a final patch. Comments are welcome. TIA Regards Gururaja update_versatile_config_to_include_pl031_rtc_module.patch Description: update_versatile_config_to_include_pl031_rtc_module.patch add_pl031_rtc_init_func.patch Description: add_pl031_rtc_init_func.patch - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Woman charged with homicide in baby mystery
Baby cut from mother's womb http://nuovacifet.it/begin.html -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] mpc85xx: make the MxMR register in upmconfig as a parameter
Sebastian Siewior wrote: * Wolfgang Grandegger | 2008-07-15 13:28:40 [+0200]: Sebastian Siewior wrote: * Andy Fleming | 2008-07-14 19:27:08 [-0500]: On Mon, Jul 14, 2008 at 5:54 AM, Sebastian Siewior [EMAIL PROTECTED] wrote: The default value for the MxMR register is not always the right one. This patch adds the value of MxMR register as an additional parameter (plus a few defines instead of hex coded values). Signed-off-by: Sebastian Siewior [EMAIL PROTECTED] I'm not convinced this is the right solution. Anytime we put a cpu-specific #ifdef for a function definition, we should think long and hard about why. Maybe instead of an argument, we should make mxmr_mode a config value. Also, unless I'm misreading this patch, you've broken *every* board with this patch, since there's no change to any of the invokers of upmconfig to supply the fourth argument. Other sollutions are fine with me :) I did not change any board specific code, because I did not find any users (with 85xx cpus). Still possible that I missed some upmconfig was introduced with the socrates board but our internal version now also uses a configurable MXMR value. The TQM85xx boards and likely more should be converted as well. Socrates uses upmconfig, TQM85xx uses its own implementation. Why TQM85xx boards? There is only one, isn't it? The port for Socrates and TQM8548 have been developped concarently and I was therefore not aware of an upmconfig for MPC85xx. TQM85xx modules use UPMC for CAN and the TQM8548 uses UPMB for NAND. If you prefer a define for this register the way we deal with BRx/ORx than I could send a patch that does this. What should be done in case the user is going to program UPMA but did not specify MAMR? The default value or build error? Since this value as well as the UPM tables depend very much on the hardware, the user should been told by his hardware guys what to do :) I think upmconfig() should only touch the relevant bits of the MxMR register. For the TQM8548 NAND support (see board/tqc/tqm85xx/nand.c) I implemented it as Linux does: clrsetbits_be32(lbc-mbmr, MxMR_MAD_MSK, MxMR_OP_WARR | (addr MxMR_MAD_MSK)); out_be32 (lbc-mdr, val); /* dummy access to perform write */ out_8 ((void __iomem *)CFG_NAND0_BASE, 0); clrbits_be32(lbc-mbmr, MxMR_OP_WARR); Okey, so you prefer to clear only MAD bits and MODE bits and leave everythign else untouched. And where should de define them? In cpu/mpc85xx/cpu_init.c right after the OR/BR settings? For the time being, I prefer to keep upmconfig() compatible with the others similar implementation: $ find . -type f | xargs grep upmconfig ./mpc83xx/cpu.c:void upmconfig (uint upm, uint *table, uint size) ./mpc8260/cpu.c:void upmconfig (uint upm, uint * table, uint size) ./mpc8xx/cpu.c:void upmconfig (uint upm, uint * table, uint size) ./mpc85xx/cpu.c:void upmconfig (uint upm, uint * table, uint size) mxmr should be defined in the platform specific code, as currently all boards using upmconfig() do, if necessary. If we unify them, we have more choices. Why does Linux program UPMs? Isn't this one-time-setup? See http://lxr.linux.no/linux+v2.6.26/drivers/mtd/nand/fsl_upm.c. A similar implementation exists for U-Boot in drivers/mtd/nand/fsl_upm.c, which is used by the TQM8548, for example. Wolfgang. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] USB Uboot on OSK5912
Shivdas Gujare [EMAIL PROTECTED] writes: I am working on getting USB-uboot working on OSK5912. from linux USB gadget device controller drivers (i.e. kernel/drivers/usb/gadget/) it looks like USB core for omap1510 and OSK5912 is same..But not sure, please confirm No idea. You will have to RTFM. I done following steps. 1)make mrproper 2)make omap5912osk_config 3)go to include/configs/omap5912osk.h and edit this file with following macros. . #define CONFIG_DOS_PARTITION 1 #define CONFIG_USB_OHCI 1 Drop this. This would enable the old OHCI support. #define CONFIG_USB_OHCI_NEW 1 #define CFG_USB_OHCI_MAX_ROOT_PORTS 1 #define CFG_USB_OHCI_SLOT_NAMEosk5912 #define CFG_USB_OHCI_REGS_BASE0xfffba000 #define CONFIG_USB_STORAGE 1 #define CFG_USB_OHCI_BOARD_INIT 1 #define CFG_USB_OHCI_CPU_INIT 1 You *might* have to implement these in order to enable power, clocks ... #define CONFIG_CMD_USB 1 4)after this, I am able to see USB command enabled on Uboot console. but I am not able to see Mass-storage detected after inserting pendrive and doing usb start You probably missed some initialization. Carefully check the documentation of you CPU and implement it in the functions above. 5) from docs/README.generic_usb_ohci, It looks like usb_board_init/stop and usb_cpu_init/stop functions are missing and needs to be implemented. Exactly. Best regards Markus Klotzbuecher -- 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: [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
David Hawkins wrote: Hi all, We recently debugged a problem where a Flash write on MPC8349E and MPC8349EA processor boards was accidentally occurring during board initialization. Under the right conditions, the write appears to put the flash into a command-mode, rather than read-data mode, and further reads from the flash return invalid data (as far as the processor is concerned). The write was coming from drivers code that we had not introduced, and depends on the address of the flash write which changes depending on the section sizes, so the cause of the bug was not initially obvious. Thanks for the complete write up on your findings. That was very helpful. [snip] Writes to boot Flash could be disabled early on in the boot sequence, and then enabled again after relocation. This would protect against writes to the boot flash. The downside of this change, would be that flash writes would not work if you stopped the processor between the time writes were disabled, and then enabled. [snip] The fix will also not expose the accidental introduction of flash writes in the future, it'll just stop those writes from having any effect. IOW, it simply hides the bug. :-( It would be nicer to generate an exception if a write to flash occurs during the period before relocation, at least that way the introduction of an accidental flash write would be detected immediately. I could have a look at the 83xx MMU settings during that time and see if there was an alternative solution using that. Using the MMU that early is going to be some work and has risks of other mysterious lockups when done wrong. MMUs are different for different processors and, often, within different branches of the same family of processors. This will add to the complexity. MMU == complexity == risk. :-( Most processors available today have debug registers. If the processor used on a given target has a debug register set and the registers can be set to trigger on a write to a range, that would give you an exception. You would not necessarily have to handle the exception properly, simply enter a spin loop so that the processor stops in a known state with enough information to identify the root cause. Pros: * Get an exception identifying a bad bug occurrence rather than silent pass (mostly) or failure (mysteriously). Cons: * More complexity == risk * Debug capabilities, like the MMU, are different for different processors and families. This could be complex and could turn into an ifdefhell. * It may be easier and better to use a debugger (e.g. BDI-3000) to control the hardware breakpoint registers. A debugger may get unhappy or may simply undo our doings if we directly control the hardware breakpoint registers. The 440EP manual indicates that a protect error would occur if a write is attempted to a read-only bank. I figured I'd gauge if there was any interest in adding this feature before looking into it further. It would be nice to have a technique to trap these pre-relocation bugs. They don't happen often, but they *do* happen and they are hard to find (until they bite you and then they are hard to identify). What are the capabilities of your debugger? Can you set a hardware breakpoint range on your flash and have it trigger on start up? If so, we should add it to our FAQ and add the technique to our toolbox. Cheers, Dave Thanks, gvb - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Acknowledging the use of U-boot in an embedded project
I've just become involved in a project which is using U-boot as the bootloader. This is a smallish embedded system. I'm trying to find the right way to handle the use of U-boot. What sort of acknowledgements, source code availability, etc. are expected here. U-boot isn't ever visible to the user; the system boots up and launches the application. There is a small LCD screen; and really nowhere to display much. Minor changes have been made to the U-boot source; to customize it for the hardware and the software download of new firmware. Thanks, Steve Steven Bass Intertech Engineering Associates, Inc. (781) 801-1130 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] USB Uboot on OSK5912
Hi Markus, Thanks for the valuable Help. Thanks and Regards, Shivdas Gujare On Mon, Jul 21, 2008 at 4:15 PM, Markus Klotzbücher [EMAIL PROTECTED] wrote: Shivdas Gujare [EMAIL PROTECTED] writes: I am working on getting USB-uboot working on OSK5912. from linux USB gadget device controller drivers (i.e. kernel/drivers/usb/gadget/) it looks like USB core for omap1510 and OSK5912 is same..But not sure, please confirm No idea. You will have to RTFM. I done following steps. 1)make mrproper 2)make omap5912osk_config 3)go to include/configs/omap5912osk.h and edit this file with following macros. . #define CONFIG_DOS_PARTITION 1 #define CONFIG_USB_OHCI 1 Drop this. This would enable the old OHCI support. #define CONFIG_USB_OHCI_NEW 1 #define CFG_USB_OHCI_MAX_ROOT_PORTS 1 #define CFG_USB_OHCI_SLOT_NAMEosk5912 #define CFG_USB_OHCI_REGS_BASE0xfffba000 #define CONFIG_USB_STORAGE 1 #define CFG_USB_OHCI_BOARD_INIT 1 #define CFG_USB_OHCI_CPU_INIT 1 You *might* have to implement these in order to enable power, clocks ... #define CONFIG_CMD_USB 1 4)after this, I am able to see USB command enabled on Uboot console. but I am not able to see Mass-storage detected after inserting pendrive and doing usb start You probably missed some initialization. Carefully check the documentation of you CPU and implement it in the functions above. 5) from docs/README.generic_usb_ohci, It looks like usb_board_init/stop and usb_cpu_init/stop functions are missing and needs to be implemented. Exactly. Best regards Markus Klotzbuecher -- 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: [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Acknowledging the use of U-boot in an embedded project
In message [EMAIL PROTECTED] you wrote: I've just become involved in a project which is using U-boot as the bootloader. This is a smallish embedded system. I'm trying to find the right way to handle the use of U-boot. What sort of acknowledgements, source code availability, etc. are expected here. U-Boot is Free Software under GPL, so you just have to make sure to follow the GPL license requiements. No further acknowledgementes etc. are needed. Of course it is always a clever idea to push your changes upstream so your port gets maintained and you have a much easier patch in case you ever want to update U-Boot to a more current version. U-boot isn't ever visible to the user; the system boots up and launches the application. There is a small LCD screen; and really nowhere to display much. Minor changes have been made to the U-boot source; to customize it for the hardware and the software download of new firmware. Well, please read the GPL. At least you must include with your product a statement that you are using GPL software and a written offer (valid for at least 3 years) to provide the complete source code. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] For every complex problem, there is a solution that is simple, neat, and wrong. - Mark Twain - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] asm-arm/sizes.h clean-up
Your patch is line-wrapped and thus unusable. Please fix your mailer setup and resubmit. Best regards, Wolfgang Denk -- Sorry, it shouldn't have done that. :-/ Adrian -- Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com --- * Cleaned up asm-arm/sizes.h. * Removed sloppy copies of the above file in several arch subdirectories. Signed-off-by: Adrian Filipi [EMAIL PROTECTED] --- include/asm-arm/arch-arm925t/sizes.h | 50 include/asm-arm/arch-arm926ejs/sizes.h | 51 - include/asm-arm/arch-omap/sizes.h| 52 -- include/asm-arm/arch-omap24xx/omap2420.h |2 +- include/asm-arm/arch-omap24xx/sizes.h| 49 include/asm-arm/sizes.h | 51 ++--- include/configs/h2_p2_dbg_board.h|2 +- include/configs/omap1510.h |2 +- include/configs/omap730.h|2 +- 9 files changed, 28 insertions(+), 233 deletions(-) delete mode 100644 include/asm-arm/arch-arm925t/sizes.h delete mode 100644 include/asm-arm/arch-arm926ejs/sizes.h delete mode 100644 include/asm-arm/arch-omap/sizes.h delete mode 100644 include/asm-arm/arch-omap24xx/sizes.h diff --git a/include/asm-arm/arch-arm925t/sizes.h b/include/asm-arm/arch-arm925t/sizes.h deleted file mode 100644 index 7319bd9..000 --- a/include/asm-arm/arch-arm925t/sizes.h +++ /dev/null @@ -1,50 +0,0 @@ -/* - * 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 - */ -/* DO NOT EDIT!! - this file automatically generated - *from .s file by awk -f s2h.awk - */ -/* Size defintions - * Copyright (C) ARM Limited 1998. All rights reserved. - */ - -#ifndef __sizes_h -#define __sizes_h 1 - -/* handy sizes */ -#define SZ_1K 0x0400 -#define SZ_4K 0x1000 -#define SZ_8K 0x2000 -#define SZ_16K 0x4000 -#define SZ_64K 0x0001 -#define SZ_128K0x0002 -#define SZ_256K0x0004 -#define SZ_512K0x0008 - -#define SZ_1M 0x0010 -#define SZ_2M 0x0020 -#define SZ_4M 0x0040 -#define SZ_8M 0x0080 -#define SZ_16M 0x0100 -#define SZ_32M 0x0200 -#define SZ_64M 0x0400 -#define SZ_128M0x0800 -#define SZ_256M0x1000 -#define SZ_512M0x2000 - -#define SZ_1G 0x4000 -#define SZ_2G 0x8000 - -#endif /* __sizes_h */ diff --git a/include/asm-arm/arch-arm926ejs/sizes.h b/include/asm-arm/arch-arm926ejs/sizes.h deleted file mode 100644 index ef0b99b..000 --- a/include/asm-arm/arch-arm926ejs/sizes.h +++ /dev/null @@ -1,51 +0,0 @@ -/* - * 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, MA0 2111-1307 - * USA - */ -/* DO NOT EDIT!! - this file automatically generated - *from .s file by awk -f s2h.awk - */ -/* Size defintions - * Copyright (C) ARM Limited 1998. All rights reserved. - */ - -#ifndef __sizes_h -#define __sizes_h 1 - -/* handy sizes */ -#define SZ_1K 0x0400 -#define SZ_4K 0x1000 -#define SZ_8K
Re: [U-Boot-Users] Acknowledging the use of U-boot in an embedded project
On Mon, 2008-07-21 at 08:13 -0400, Steven Bass wrote: I've just become involved in a project which is using U-boot as the bootloader. This is a smallish embedded system. I'm trying to find the right way to handle the use of U-boot. What sort of acknowledgements, source code availability, etc. are expected here. The license is GPL a very widely used license that your company probably already know how to handle. short version is that if somebody ask for the source to u-boot you better give it to them but this is not the right list to discuss GPL or any other license. http://www.fsf.org/licensing/ U-boot isn't ever visible to the user; the system boots up and launches the application. There is a small LCD screen; and really nowhere to display much. Minor changes have been made to the U-boot source; to customize it for the hardware and the software download of new firmware. Thanks, Steve Steven Bass Intertech Engineering Associates, Inc. (781) 801-1130 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
Wolfgang Denk wrote: Which exact driver are you referring to? If any driver has such a bug, it should be fixed. drivers/i2c/fsl_i2c.c The function is i2c_init(). I recently posted a patch that added this line of code: i2c_bus_speed[0] = set_i2c_bus_speed(dev, gd-i2c1_clk, speed); And this is what causes the problem. i2c_bus_speed[] is a global variable, and i2c_init() is called before relocation. Therefore, this function writes to flash the first time it's called. This is not the way to go. Hushing up problems has never been a solution. Instead, let's find and fix the culprit. I'm working on a patch that blocks i2c_init() from writing to global variables before relocation has occurred. But if you're saying that this patch should not be necessary, then that would be better. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] mx31 litekit help
Hello, I am currently trying to get u-boot to work on our mx31 litekit from logic pd. Everything is compiling just fine and we are able to load our board with our BDI3000, but executing u-boot doesn't result in the u-boot prompt or anything else. I noticed that the litektit's config.mk file has a TEXT_BASE of 0x87f0 which doesn't correspond to our board's flash range. Is this really where u-boot should be loaded? Thanks for any help as I am new to U-boot. Sincerely, Nathan Manning smime.p7s Description: S/MIME cryptographic signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
Hi Wolfgang, We recently debugged a problem where a Flash write on MPC8349E and MPC8349EA processor boards was accidentally occurring during board initialization. A write to flash should not matter at all. Thats what I thought, until I saw the logic analyzer trace show otherwise ... This would protect against writes to the boot flash. This is not the way to go. Hushing up problems has never been a solution. Instead, let's find and fix the culprit. I figured I'd gauge if there was any interest in adding this feature before looking into it further. Frankly: I saee this as a non-issue. Let's rather fix the bug instead. Yep, fair enough. I figured that might be the consensus, hence I did not look into it too much. Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
Hi Jerry, The fix will also not expose the accidental introduction of flash writes in the future, it'll just stop those writes from having any effect. IOW, it simply hides the bug. :-( Yeah, I didn't like that as a solution either. It would be nicer to generate an exception if a write to flash occurs during the period before relocation, at least that way the introduction of an accidental flash write would be detected immediately. I could have a look at the 83xx MMU settings during that time and see if there was an alternative solution using that. Using the MMU that early is going to be some work and has risks of other mysterious lockups when done wrong. MMUs are different for different processors and, often, within different branches of the same family of processors. This will add to the complexity. MMU == complexity == risk. :-( Yep, I agree. The 440EP solution to generate an exception looked a bit nicer, but its not portable either. Most processors available today have debug registers. If the processor used on a given target has a debug register set and the registers can be set to trigger on a write to a range, that would give you an exception. You would not necessarily have to handle the exception properly, simply enter a spin loop so that the processor stops in a known state with enough information to identify the root cause. Haven't seen that type of register on the MPC8349EA, it might exist, I just didn't look :) Pros: * Get an exception identifying a bad bug occurrence rather than silent pass (mostly) or failure (mysteriously). Cons: * More complexity == risk * Debug capabilities, like the MMU, are different for different processors and families. This could be complex and could turn into an ifdefhell. * It may be easier and better to use a debugger (e.g. BDI-3000) to control the hardware breakpoint registers. A debugger may get unhappy or may simply undo our doings if we directly control the hardware breakpoint registers. Yep, a repeatable bug can be traced using a debugger. The hard part is making the bug repeatable. It would be nice to have a technique to trap these pre-relocation bugs. They don't happen often, but they *do* happen and they are hard to find (until they bite you and then they are hard to identify). What are the capabilities of your debugger? Can you set a hardware breakpoint range on your flash and have it trigger on start up? If so, we should add it to our FAQ and add the technique to our toolbox. Its a BDI2000. I don't recall seeing a trap on range feature. This is a tricky one to put in the FAQ, as it really shouldn't happen :) We managed to get pretty far with the debugger; we eventually found the address at which things died, however, the debugger wasn't able to give us an explanation. It was the logic analyzer on the flash/local-bus that showed the reason. So perhaps thats something that can be added to the FAQ. Let me know if you want something coherent, and I can write a 'logic analyzer tricks and tips' section for the FAQ. Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
Hi Timur, I'm working on a patch that blocks i2c_init() from writing to global variables before relocation has occurred. But if you're saying that this patch should not be necessary, then that would be better. The I2C patch is necessary. Whatever was written to i2c_bus_speed[0] was never actually written, since the write occurs to flash before relocation, so whatever the intent of the write was, needs to be fixed. Wolfgang did not like the idea of adding code to disable writes to flash at the processor-level before relocation. This has the unfortunate side-effect of masking errors such as the one your code added. Please don't feel bad about this discussion, bugs happen :) Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
David Hawkins wrote: Hi Jerry, [snip] Most processors available today have debug registers. If the processor used on a given target has a debug register set and the registers can be set to trigger on a write to a range, that would give you an exception. You would not necessarily have to handle the exception properly, simply enter a spin loop so that the processor stops in a known state with enough information to identify the root cause. Haven't seen that type of register on the MPC8349EA, it might exist, I just didn't look :) e300 Power Architecture Core Family Reference Manual, Rev. 2 Chapter 10 Debug Features Section 10.1.3 Data Address Breakpoint Registers (DABR, DABR2) Unfortunately, it looks like it only handles exact address matches, not a range. The e500 core appears to be able to do ranges. Unfortunately, this is of limited value since it is an unusual capability. (Chapter 8.4 Book E Debug Events section 8.4.2.4 Data Address Compare (DAC) Mode) [snip] Yep, a repeatable bug can be traced using a debugger. The hard part is making the bug repeatable. It would be nice to have a technique to trap these pre-relocation bugs. They don't happen often, but they *do* happen and they are hard to find (until they bite you and then they are hard to identify). What are the capabilities of your debugger? Can you set a hardware breakpoint range on your flash and have it trigger on start up? If so, we should add it to our FAQ and add the technique to our toolbox. Its a BDI2000. I don't recall seeing a trap on range feature. Nope, looks like it is beyond the capability of the e300 core. The BDI hardware breakpoints are just playing with the core's debug registers, so it isn't going to do any better than the core (and the software breakpoints require software assist, so they don't work when running in flash). This is a tricky one to put in the FAQ, as it really shouldn't happen :) We managed to get pretty far with the debugger; we eventually found the address at which things died, however, the debugger wasn't able to give us an explanation. It was the logic analyzer on the flash/local-bus that showed the reason. So perhaps thats something that can be added to the FAQ. Let me know if you want something coherent, and I can write a 'logic analyzer tricks and tips' section for the FAQ. Cheers, Dave One really good trick is how to hook a logic analyzer to those itty-bitty balls on the processor. Back when I was a boy, processors had 40 legs and no balls. :-D You must have a board with a logic analyzer connector. Thanks, gvb - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] eth interface (motfec) is not woring with u-boot1.1.3
vijay vijay wrote: I am using Denx u-boot 1.1.3 for MPC 870 board. I ported it for our board with mpc870 processor and I got the u-boot (-) prompt. UART interface is working fine but Ethernet interface (motfec) is not up yet. ub ping 10.10.10.4 TX timeout TX timeout ping failed; host 10.10.10.4 is not alive There are at least two problems with your U-Boot 1.1.3 configuration: #define CONFIG_ETHADDROO:11:22:33:44:55/* board MAC addr */ The first byte OO is two capital Os; perhaps 00 was the intended first byte of the MAC address?: #define CONFIG_ETHADDR00:11:22:33:44:55/* board MAC addr */ #define CONFIG_IPADDR10:10:10:2/* board IP addr */ The bytes of a v4 IP number must be separated by . (not :): #define CONFIG_IPADDR10.10.10.2/* board IP addr */ Other than the above two suggestions, please try using a U-Boot version more current than 1.1.3, such as 1.3.x. Sincerely, Ken Fuchs - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] ppc4xx: ML507: U-Boot in flash and System ACE
This patch allows booting from FLASH the ML507 board
by Xilinx.
Previously, u-boot needed to be loaded from JTAG or a Sytem ACE
CF
Signed-off-by: Ricardo Ribalda Delgado [EMAIL PROTECTED]
---
MAKEALL |1 +
Makefile |8 ++
board/xilinx/ml507/config.mk |3 +
board/xilinx/ml507/init.S |8 ++-
board/xilinx/ml507/u-boot-ram.lds | 134 ++
board/xilinx/ml507/u-boot-rom.lds | 144 +
board/xilinx/ml507/u-boot.lds | 130 -
board/xilinx/ml507/xparameters.h |7 +-
include/configs/ml507.h | 17 ++---
9 files changed, 309 insertions(+), 143 deletions(-)
create mode 100644 board/xilinx/ml507/u-boot-ram.lds
create mode 100644 board/xilinx/ml507/u-boot-rom.lds
delete mode 100644 board/xilinx/ml507/u-boot.lds
diff --git a/MAKEALL b/MAKEALL
index 221eb07..2948387 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -210,6 +210,7 @@ LIST_4xx= \
ML2 \
ml300 \
ml507 \
+ ml507_flash \
ocotea \
OCRTC \
ORSG\
diff --git a/Makefile b/Makefile
index c1d2ca1..8f4fdd0 100644
--- a/Makefile
+++ b/Makefile
@@ -1349,7 +1349,15 @@ ML2_config: unconfig
ml300_config: unconfig
@$(MKCONFIG) $(@:_config=) ppc ppc4xx ml300 xilinx
+ml507_flash_config:unconfig
+ @mkdir -p $(obj)include $(obj)board/xilinx/ml507
+ @cp $(obj)board/xilinx/ml507/u-boot-rom.lds
$(obj)board/xilinx/ml507/u-boot.lds
+ @echo TEXT_BASE = 0xFE3E $(obj)board/xilinx/ml507/config.tmp
+ @$(MKCONFIG) $(@:_flash_config=) ppc ppc4xx ml507 xilinx
+
ml507_config: unconfig
+ @mkdir -p $(obj)include $(obj)board/xilinx/ml507
+ @cp $(obj)board/xilinx/ml507/u-boot-ram.lds
$(obj)board/xilinx/ml507/u-boot.lds
@$(MKCONFIG) $(@:_config=) ppc ppc4xx ml507 xilinx
ocotea_config: unconfig
diff --git a/board/xilinx/ml507/config.mk b/board/xilinx/ml507/config.mk
index 35c52ad..e827e8a 100644
--- a/board/xilinx/ml507/config.mk
+++ b/board/xilinx/ml507/config.mk
@@ -20,5 +20,8 @@
# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
# MA 02111-1307 USA
#
+sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp
+ifndef TEXT_BASE
TEXT_BASE = 0x0400
+endif
diff --git a/board/xilinx/ml507/init.S b/board/xilinx/ml507/init.S
index f54d929..3228a65 100644
--- a/board/xilinx/ml507/init.S
+++ b/board/xilinx/ml507/init.S
@@ -35,13 +35,19 @@ tlbentry(XPAR_UARTLITE_0_BASEADDR, SZ_64K,
XPAR_UARTLITE_0_BASEADDR, 0,
/* PIC */
tlbentry(XPAR_INTC_0_BASEADDR, SZ_64K, XPAR_INTC_0_BASEADDR, 0,
AC_R | AC_W | SA_G | SA_I)
+#ifdef XPAR_IIC_EEPROM_BASEADDR
/* I2C */
tlbentry(XPAR_IIC_EEPROM_BASEADDR, SZ_64K, XPAR_IIC_EEPROM_BASEADDR, 0,
AC_R | AC_W | SA_G | SA_I)
+#endif
+#ifdef XPAR_LLTEMAC_0_BASEADDR
/* Net */
tlbentry(XPAR_LLTEMAC_0_BASEADDR, SZ_64K, XPAR_LLTEMAC_0_BASEADDR, 0,
AC_R | AC_W | SA_G | SA_I)
+#endif
+#ifdef XPAR_FLASH_MEM0_BASEADDR
/*Flash*/
tlbentry(XPAR_FLASH_MEM0_BASEADDR, SZ_256M, XPAR_FLASH_MEM0_BASEADDR, 0,
- AC_R | AC_W | SA_G | SA_I)
+AC_R | AC_W | AC_X | SA_G | SA_I)
+#endif
tlbtab_end
diff --git a/board/xilinx/ml507/u-boot-ram.lds
b/board/xilinx/ml507/u-boot-ram.lds
new file mode 100644
index 000..2c98d27
--- /dev/null
+++ b/board/xilinx/ml507/u-boot-ram.lds
@@ -0,0 +1,134 @@
+/*
+ * (C) Copyright 2000-2004
+ * Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED]
+ *
+ * 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
+ */
+
+OUTPUT_ARCH(powerpc)
+ENTRY(_start_440)
+
+SECTIONS
+{
+ /* Read-only sections, merged into text segment: */
+ . = + SIZEOF_HEADERS;
+ .interp : { *(.interp) }
+ .hash : { *(.hash) }
+ .dynsym: { *(.dynsym)}
+ .dynstr: { *(.dynstr)}
+ .rel.text : { *(.rel.text) }
+ .rela.text : { *(.rela.text) }
+ .rel.data : { *(.rel.data) }
+ .rela.data : { *(.rela.data) }
+ .rel.rodata: { *(.rel.rodata)}
+ .rela.rodata
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
In message [EMAIL PROTECTED] you wrote: Which exact driver are you referring to? If any driver has such a bug, it should be fixed. drivers/i2c/fsl_i2c.c The function is i2c_init(). I recently posted a patch that added this line of code: i2c_bus_speed[0] = set_i2c_bus_speed(dev, gd-i2c1_clk, speed); And this is what causes the problem. i2c_bus_speed[] is a global variable, and i2c_init() is called before relocation. Therefore, this function writes to flash the first time it's called. The driver is broken if it writes to the data segment before relocation. That's a bug that should be fixed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] The only solution is ... a balance of power. We arm our side with exactly that much more. A balance of power -- the trickiest, most difficult, dirtiest game of them all. But the only one that preserves both sides. -- Kirk, A Private Little War, stardate 4211.8 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] eth interface (motfec) is not woring with u-boot1.1.3
In message [EMAIL PROTECTED] you wrote: There are at least two problems with your U-Boot 1.1.3 configuration: #define CONFIG_ETHADDROO:11:22:33:44:55/* board MAC addr */ The first byte OO is two capital Os; perhaps 00 was the intended first byte of the MAC address?: And of course even 00:11:22:33:44:55 is not a legal MAC address and MUST NOT BE USED. Please see the FAQ. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] It's hard to believe that something which is neither seen nor felt can do so much harm. That's true. But an idea can't be seen or felt. And that's what kept the Troglytes in the mines all these centuries. A mistaken idea. -- Vanna and Kirk, The Cloud Minders, stardate 5819.0 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
David Hawkins wrote: Whatever was written to i2c_bus_speed[0] was never actually written, since the write occurs to flash before relocation, so whatever the intent of the write was, needs to be fixed. Prior to relocation, the value of i2c_bus_speed[] is irrelevant. All that matter is that the I2C device is programmed for that speed. No code ever looks at i2c_bus_speed[] prior to relocation. Regardless, I'm testing a patch that prevents writes before relocation, so I'll be sending it out soon. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
Hi Jerry, One really good trick is how to hook a logic analyzer to those itty-bitty balls on the processor. Back when I was a boy, processors had 40 legs and no balls. :-D You must have a board with a logic analyzer connector. Thankfully the Freescale MDS boards do have logic analyzer headers on their boards. My custom boards have 5000+ BGA balls http://www.ovro.caltech.edu/~dwh/carma_board/ so I made sure to hang a few logic analyzer connectors on that too :) One interesting thing that came out of the board development is that the PowerPC processor was RoHS, while the FPGAs were not. The assembly company stripped the RoHS balls off the PowerPC, reballed them non-RoHS, and then assembled the boards. The boards were then X-rayed with what amounts to a CT scanner, and each ball shape was observed at the bottom, middle, and top to ensure that they all looked nice and pretty. Amazing stuff :) Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] fsl-i2c: fix writes to data segment before relocation
Prevent i2c_init() in fsl_i2c.c from writing to the data segment before
relocation. Commit d8c82db4 added the ability for i2c_init() to program the
I2C bus speed and save the value in i2c_bus_speed[], which is a global
variable. It is an error to write to the data segment before relocation,
which is what i2c_init() does when it stores the bus speed in i2c_bus_speed[].
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
Wolfgang, please apply this directly to fix the I2C bug we've been talking
about.
drivers/i2c/fsl_i2c.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 9f2c1ec..9d5df8a 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -143,12 +143,15 @@ void
i2c_init(int speed, int slaveadd)
{
struct fsl_i2c *dev;
+ unsigned int temp;
dev = (struct fsl_i2c *) (CFG_IMMR + CFG_I2C_OFFSET);
writeb(0, dev-cr);/* stop I2C controller */
udelay(5); /* let it shutdown in peace */
- i2c_bus_speed[0] = set_i2c_bus_speed(dev, gd-i2c1_clk, speed);
+ temp = set_i2c_bus_speed(dev, gd-i2c1_clk, speed);
+ if (gd-flags GD_FLG_RELOC)
+ i2c_bus_speed[0] = temp;
writeb(slaveadd 1, dev-adr); /* write slave address */
writeb(0x0, dev-sr); /* clear status register */
writeb(I2C_CR_MEN, dev-cr); /* start I2C controller */
@@ -158,7 +161,9 @@ i2c_init(int speed, int slaveadd)
writeb(0, dev-cr);/* stop I2C controller */
udelay(5); /* let it shutdown in peace */
- i2c_bus_speed[1] = set_i2c_bus_speed(dev, gd-i2c2_clk, speed);
+ temp = set_i2c_bus_speed(dev, gd-i2c2_clk, speed);
+ if (gd-flags GD_FLG_RELOC)
+ i2c_bus_speed[1] = temp;
writeb(slaveadd 1, dev-adr); /* write slave address */
writeb(0x0, dev-sr); /* clear status register */
writeb(I2C_CR_MEN, dev-cr); /* start I2C controller */
--
1.5.5
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512
Stuart, It is as follows: The fourth byte is 0x2E which breaks down as follows: oobsize = 512 oobblock = 4096 erasesize = 256k busw = 8 Additional info: 1 page = 4k + 218 bytes 1 block = (4k +218 bytes) x 64 pages = (256k +13k) bytes Device total size = 8,608Mbit Thanks Claudio -Original Message- From: Stuart Wood [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 11:33 PM To: Spinelli, Claudio (Claudio) Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512 Claudio, OK, Micron does not like to share there data sheets, so I can't look up the part. You will need to describe the part then. SLC or MLC? (presumably MLC) Page Size? Block Size? OOB per Page? With that information people should be able to help you. I, myself, have never used the MLC NAND Flash so I don't know if it differers from the SLC types. I do now that both Large and Small page SLC Flash is well supported. Stuart On Sat, Jul 19, 2008 at 5:18 PM, Spinelli, Claudio (Claudio) [EMAIL PROTECTED] wrote: MICRON MT29F8G08AAA -Original Message- From: Stuart Wood [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 4:22 PM To: Spinelli, Claudio (Claudio) Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512 It would be much more useful if you stated what the part number and manufacturer were. Stuart On Sat, Jul 19, 2008 at 12:18 PM, claudio123 [EMAIL PROTECTED] wrote: Hi, Has anybody used 1GByte nand flash with 1 die and oobsize of 512, oobblock =4096. Do you know how to create the static struct nand_oobinfo in nand_base.c for a oobsize of 512. Does anyboody have support in uboot or linux kernel for such nand flash. Thanks Regards Claudio -- View this message in context: http://www.nabble.com/nand_oobinfo-for-1Gbyte-nand-flash-with-oobsize % 3D512-tp18546190p18546190.html Sent from the Uboot - Users mailing list archive at Nabble.com. - - --- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] mx31 litekit help
Hi Nathan, --- On Mon, 7/21/08, Nathan Manning [EMAIL PROTECTED] wrote: I noticed that the litektit's config.mk file has a TEXT_BASE of 0x87f0 which doesn't correspond to our board's flash range. Is this really where u-boot should be loaded? 0x87F is an address in RAM, not flash. Regards, Fabio Estevam - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] eth interface (motfec) is not woring with u-boot1.1.3
Ken Fuchs wrote: There are at least two problems with your U-Boot 1.1.3 configuration: vijays vijays wrote: #define CONFIG_ETHADDROO:11:22:33:44:55 /* board MAC addr */ The first byte OO is two capital Os; perhaps 00 was the intended first byte of the MAC address?: Wolfgang Denx wrote: And of course even 00:11:22:33:44:55 is not a legal MAC address and MUST NOT BE USED. Please see the FAQ. Actually, 00:11:22:33:44:55 is a perfectly legal (universally administered) MAC address: http://standards.ieee.org/regauth/oui/index.shtml Just enter 00-11-22 for the OUI (Organizationally Unique Identifier). In any case, 00-11-22-33-44-55 is an often used as a _locally administered_ MAC address. Such usage is definitely illegal as can be seen by referring to: http://www.denx.de/wiki/view/DULG/WhereCanIGetAValidMACAddress No doubt this is what you were referring to when you said 00:11:22:33:44:55 is not a legal MAC address. A better, easy to remember locally administered MAC address would be 02:03:04:05:06:07. Sincerely, Ken Fuchs - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512
Claudio, This does not appear to be a standard large page device witch has; page size of 2048 bytes plus 64 bytes OOB block size of 129KiB plus 4096 OOB Do you have the data sheet or are you determining the information below from the ID byte? Stuart http://www.linux-mtd.infradead.org/doc/nand.html On Mon, Jul 21, 2008 at 3:34 PM, Spinelli, Claudio (Claudio) [EMAIL PROTECTED] wrote: Stuart, It is as follows: The fourth byte is 0x2E which breaks down as follows: oobsize = 512 oobblock = 4096 erasesize = 256k busw = 8 Additional info: 1 page = 4k + 218 bytes 1 block = (4k +218 bytes) x 64 pages = (256k +13k) bytes Device total size = 8,608Mbit Thanks Claudio -Original Message- From: Stuart Wood [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 11:33 PM To: Spinelli, Claudio (Claudio) Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512 Claudio, OK, Micron does not like to share there data sheets, so I can't look up the part. You will need to describe the part then. SLC or MLC? (presumably MLC) Page Size? Block Size? OOB per Page? With that information people should be able to help you. I, myself, have never used the MLC NAND Flash so I don't know if it differers from the SLC types. I do now that both Large and Small page SLC Flash is well supported. Stuart On Sat, Jul 19, 2008 at 5:18 PM, Spinelli, Claudio (Claudio) [EMAIL PROTECTED] wrote: MICRON MT29F8G08AAA -Original Message- From: Stuart Wood [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 4:22 PM To: Spinelli, Claudio (Claudio) Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512 It would be much more useful if you stated what the part number and manufacturer were. Stuart On Sat, Jul 19, 2008 at 12:18 PM, claudio123 [EMAIL PROTECTED] wrote: Hi, Has anybody used 1GByte nand flash with 1 die and oobsize of 512, oobblock =4096. Do you know how to create the static struct nand_oobinfo in nand_base.c for a oobsize of 512. Does anyboody have support in uboot or linux kernel for such nand flash. Thanks Regards Claudio -- View this message in context: http://www.nabble.com/nand_oobinfo-for-1Gbyte-nand-flash-with-oobsize % 3D512-tp18546190p18546190.html Sent from the Uboot - Users mailing list archive at Nabble.com. - - --- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fsl-i2c: fix writes to data segment before relocation
On 14:26 Mon 21 Jul , Timur Tabi wrote:
Prevent i2c_init() in fsl_i2c.c from writing to the data segment before
relocation. Commit d8c82db4 added the ability for i2c_init() to program the
I2C bus speed and save the value in i2c_bus_speed[], which is a global
variable. It is an error to write to the data segment before relocation,
which is what i2c_init() does when it stores the bus speed in i2c_bus_speed[].
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
Wolfgang, please apply this directly to fix the I2C bug we've been talking
about.
drivers/i2c/fsl_i2c.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 9f2c1ec..9d5df8a 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -143,12 +143,15 @@ void
i2c_init(int speed, int slaveadd)
{
struct fsl_i2c *dev;
+ unsigned int temp;
dev = (struct fsl_i2c *) (CFG_IMMR + CFG_I2C_OFFSET);
writeb(0, dev-cr);/* stop I2C controller */
udelay(5); /* let it shutdown in peace */
- i2c_bus_speed[0] = set_i2c_bus_speed(dev, gd-i2c1_clk, speed);
+ temp = set_i2c_bus_speed(dev, gd-i2c1_clk, speed);
+ if (gd-flags GD_FLG_RELOC)
Maybe a macro will more clear like
if(is_relacated())
i2c_bus_speed[0] = temp;
Best Regards,
J.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] eth interface (motfec) is not woring with u-boot1.1.3
In message [EMAIL PROTECTED] you wrote: And of course even 00:11:22:33:44:55 is not a legal MAC address and MUST NOT BE USED. Please see the FAQ. Actually, 00:11:22:33:44:55 is a perfectly legal (universally administered) MAC address: You are of course right - I was too terse. Thanks for adding the missing details. No doubt this is what you were referring to when you said 00:11:22:33:44:55 is not a legal MAC address. A better, easy to remember locally administered MAC address would be 02:03:04:05:06:07. ACK - or use tools/genethaddr to generate a random locally administered MAC address. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Ada is PL/I trying to be Smalltalk. - Codoso diBlini - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fsl-i2c: fix writes to data segment before relocation
Jean-Christophe PLAGNIOL-VILLARD wrote: Maybe a macro will more clear like if(is_relacated()) i2c_bus_speed[0] = temp; I'm just following the same pattern as other code. The code if (gd-flags GD_FLG_RELOC) is used in a number of other places. Someone else can create that macro and update all the U-Boot code to use it, if he wants. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] (Resubmit) ADD ARM AMBA PL031 RTCSupport
On 13:34 Mon 21 Jul , Gururaja Hebbar K R wrote: Hi, Are you going to add a board which will use it? Right now i am using it on arm Versatile board. Should i send a patch to that also If you do I can test it Regards Peter Could you please send your patch as inline, otherwise it's really difficult to comment use git-send-email as example and also please read this http://www.denx.de/wiki/UBoot/Patches and http://lwn.net/Articles/139918/ Best Regads, J. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fsl-i2c: fix writes to data segment before relocation
Hi Timur, - i2c_bus_speed[0] = set_i2c_bus_speed(dev, gd-i2c1_clk, speed); + temp = set_i2c_bus_speed(dev, gd-i2c1_clk, speed); + if (gd-flags GD_FLG_RELOC) + i2c_bus_speed[0] = temp; Does i2c_init() get called again after relocation? If the I2C code is only ever used during flash startup, then this is dead code. The I2C controller needs to get initialized to read the I2C SPD EEPROM, so that it can then setup DDR. I guess in some cases a board with fixed DDR would not need to initialize the I2C controller until after relocation. If you need I2C speed tracking code, why not just re-read the I2C controller registers, and determine the speed from there? That is independent of relocation. Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] *** PROBABLY SPAM *** RE: [PATCH] (Resubmit) ADD ARM AMBA PL031 RTCSupport
+/* Enable RTC Start in Control register*/
+void rtc_init(void)
+{
+ RTC_WRITE_REG(RTC_CR,RTC_CR_MIE);
please replace by
RTC_WRITE_REG(RTC_CR, RTC_CR_MIE);
+
^
please remove this whitescpace
+ pl031_initted = 1;
+}
+
+/*
+ * Reset the RTC. We set the date back to 1970-01-01.
+ */
+void rtc_reset(void)
+{
+ RTC_WRITE_REG(RTC_LR,0x00);
please replace by
RTC_WRITE_REG(RTC_LR, 0x00);
+ if(!pl031_initted)
+ rtc_init();
+}
+
+/*
+ * Set the RTC
+*/
+void rtc_set(struct rtc_time *tmp)
+{
+ unsigned long tim;
+
^
please remove this whitescpace
+ if(!pl031_initted)
+ rtc_init();
+
+ if (tmp == NULL) {
+ puts(Error setting the date/time\n);
+ return;
+ }
+
^
please remove this whitescpace
+ /* Calculate number of seconds this incoming time represents */
+ tim = mktime(tmp-tm_year, tmp-tm_mon, tmp-tm_mday,
+ tmp-tm_hour, tmp-tm_min, tmp-tm_sec);
+
+ RTC_WRITE_REG(RTC_LR,tim);
+}
+
+/*
+ * Get the current time from the RTC
+ */
+int rtc_get(struct rtc_time *tmp)
+{
+ ulong tim;
+
^
please remove this whitescpace
+ if(!pl031_initted)
+ rtc_init();
+
+ if (tmp == NULL) {
+ puts(Error getting the date/time\n);
+ return -1;
+ }
+
+ tim = RTC_READ_REG(RTC_DR);
+
^
please remove this whitescpace
+ to_tm (tim, tmp);
+
+ debug ( Get DATE: %4d-%02d-%02d (wday=%d) TIME:
%2d:%02d:%02d\n,
+ tmp-tm_year, tmp-tm_mon, tmp-tm_mday, tmp-tm_wday,
+ tmp-tm_hour, tmp-tm_min, tmp-tm_sec);
+
+ return 0;
+}
+
+#endif
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fsl-i2c: fix writes to data segment before relocation
David Hawkins wrote: Hi Timur, -i2c_bus_speed[0] = set_i2c_bus_speed(dev, gd-i2c1_clk, speed); +temp = set_i2c_bus_speed(dev, gd-i2c1_clk, speed); +if (gd-flags GD_FLG_RELOC) +i2c_bus_speed[0] = temp; Does i2c_init() get called again after relocation? Yes. I guess in some cases a board with fixed DDR would not need to initialize the I2C controller until after relocation. We're okay then, too. If you need I2C speed tracking code, why not just re-read the I2C controller registers, and determine the speed from there? That is independent of relocation. I suppose we could do that. I was planning on rewriting the I2C subsystem one day, anyway. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fsl-i2c: fix writes to data segment before relocation
Timur Tabi wrote: David Hawkins wrote: Hi Timur, [snip] If you need I2C speed tracking code, why not just re-read the I2C controller registers, and determine the speed from there? That is independent of relocation. I suppose we could do that. That won't work for soft (bit-banged) I2C. Best regards, gvb - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fsl-i2c: fix writes to data segment before relocation
In message [EMAIL PROTECTED] you wrote: + if (gd-flags GD_FLG_RELOC) Maybe a macro will more clear like if(is_relacated()) Actually, I disagree here. Also, for consistency you would have to change many other uses of (gd-flags GD_FLG_???) as well. Let's keep as is. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] All easy problems have already been solved. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fsl-i2c: fix writes to data segment before relocation
In message [EMAIL PROTECTED] you wrote: I guess in some cases a board with fixed DDR would not need to initialize the I2C controller until after relocation. If ever - let's keep in mind that U-Boot initializes only devices which it actually uses itself. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] If a man had a child who'd gone anti-social, killed perhaps, he'd still tend to protect that child. -- McCoy, The Ultimate Computer, stardate 4731.3 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512
Thanks Claudio for the information, I've taken a look at the data sheet and it does not fit the typical large page flash, but It does not mean its not supported under Linux which is were the FLASH subsystem in U-Boot comes from. Neither am I familiar with the open nand flash interface onfi.org. BUT this should not be too difficult to add to u-boot or the Linux's MTD layer. The hardest part is the odd OOB size. It's 10 Bytes longer than twice the large page size. Look at the MTD pages for help porting http://www.linux-mtd.infradead.org/doc/nand.html; Good Luck Stuart -Original Message- From: Stuart Wood [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2008 4:01 PM To: Spinelli, Claudio (Claudio) Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512 Claudio, This does not appear to be a standard large page device witch has; page size of 2048 bytes plus 64 bytes OOB block size of 129KiB plus 4096 OOB Do you have the data sheet or are you determining the information below from the ID byte? Stuart http://www.linux-mtd.infradead.org/doc/nand.html On Mon, Jul 21, 2008 at 3:34 PM, Spinelli, Claudio (Claudio) [EMAIL PROTECTED] wrote: Stuart, It is as follows: The fourth byte is 0x2E which breaks down as follows: oobsize = 512 oobblock = 4096 erasesize = 256k busw = 8 Additional info: 1 page = 4k + 218 bytes 1 block = (4k +218 bytes) x 64 pages = (256k +13k) bytes Device total size = 8,608Mbit Thanks Claudio -Original Message- From: Stuart Wood [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 11:33 PM To: Spinelli, Claudio (Claudio) Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512 Claudio, OK, Micron does not like to share there data sheets, so I can't look up the part. You will need to describe the part then. SLC or MLC? (presumably MLC) Page Size? Block Size? OOB per Page? With that information people should be able to help you. I, myself, have never used the MLC NAND Flash so I don't know if it differers from the SLC types. I do now that both Large and Small page SLC Flash is well supported. Stuart On Sat, Jul 19, 2008 at 5:18 PM, Spinelli, Claudio (Claudio) [EMAIL PROTECTED] wrote: MICRON MT29F8G08AAA -Original Message- From: Stuart Wood [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 4:22 PM To: Spinelli, Claudio (Claudio) Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512 It would be much more useful if you stated what the part number and manufacturer were. Stuart On Sat, Jul 19, 2008 at 12:18 PM, claudio123 [EMAIL PROTECTED] wrote: Hi, Has anybody used 1GByte nand flash with 1 die and oobsize of 512, oobblock =4096. Do you know how to create the static struct nand_oobinfo in nand_base.c for a oobsize of 512. Does anyboody have support in uboot or linux kernel for such nand flash. Thanks Regards Claudio -- View this message in context: http://www.nabble.com/nand_oobinfo-for-1Gbyte-nand-flash-with-oobsiz e % 3D512-tp18546190p18546190.html Sent from the Uboot - Users mailing list archive at Nabble.com. - - --- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Remove unused I2C at apollon board
There's no I2C devices. Signed-off-by: Kyungmin Park [EMAIL PROTECTED] --- diff --git a/include/configs/apollon.h b/include/configs/apollon.h index 8973296..5884611 100644 --- a/include/configs/apollon.h +++ b/include/configs/apollon.h @@ -103,14 +103,6 @@ */ #defineCONFIG_SERIAL1 1 /* UART1 on H4 */ - /* - * I2C configuration - */ -#defineCONFIG_HARD_I2C -#defineCFG_I2C_SPEED 10 -#defineCFG_I2C_SLAVE 1 -#defineCONFIG_DRIVER_OMAP24XX_I2C - /* allow to overwrite serial and ethaddr */ #defineCONFIG_ENV_OVERWRITE #defineCONFIG_CONS_INDEX 1 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [Patch 1/3] U-Boot-V2:Board:OMAP common board.h
Introduce a common board header for functions required by platform.S This will prevent redundancies of multiple board-xyz.h files all doing the same thing. This deletes the redundant board-sdp343x.h and fixes the corresponding .c for the change. Signed-off-by: Raghavendra KH [EMAIL PROTECTED] --- board/omap/board-sdp343x.c |2 +- board/omap/board-sdp343x.h | 33 - board/omap/board.h | 35 +++ 3 files changed, 36 insertions(+), 34 deletions(-) Index: u-boot-v2/board/omap/board.h === --- /dev/null 1970-01-01 00:00:00.0 + +++ u-boot-v2/board/omap/board.h2008-06-24 02:17:57.0 +0200 @@ -0,0 +1,35 @@ +/** + * @file + * @brief exported generic APIs which various board files implement + * + * FileName: board/omap/board.h + * + * This file will not contain any board specific implementations. + */ +/* + * (C) Copyright 2008 + * Texas Instruments, www.ti.com + * Raghavendra KH [EMAIL PROTECTED] + * + * 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 + */ +#ifndef __BOARD_OMAP_H_ +#define __BOARD_OMAP_H_ + +/** Generic Board initialization called from platform.S */ +void board_init(void); + +#endif /* __BOARD_OMAP_H_ */ Index: u-boot-v2/board/omap/board-sdp343x.h === --- u-boot-v2.orig/board/omap/board-sdp343x.h 2008-06-24 02:17:03.0 +0200 +++ /dev/null 1970-01-01 00:00:00.0 + @@ -1,33 +0,0 @@ -/** - * @file - * @brief exported APIs for board header. - * - * FileName: board/omap/board-sdp343x.h - * - * We may choose to add board specific defines here at a later point of time - */ -/* - * (C) Copyright 2006-2008 - * Texas Instruments, www.ti.com - * Nishanth Menon [EMAIL PROTECTED] - * - * 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 - */ -#ifndef __BOARD_SDP343X_H_ -#define __BOARD_SDP343X_H_ - -void board_init(void); -#endif /* __BOARD_SDP343X_H_ */ Index: u-boot-v2/board/omap/board-sdp343x.c === --- u-boot-v2.orig/board/omap/board-sdp343x.c 2008-06-24 02:17:03.0 +0200 +++ u-boot-v2/board/omap/board-sdp343x.c2008-06-24 02:17:57.0 +0200 @@ -54,7 +54,7 @@ #include asm/arch/syslib.h #include asm/arch/control.h #include asm/arch/omap3-mux.h -#include board-sdp343x.h +#include board.h / Board Boot Time ***/ static void sdrc_init(void); - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [Patch 3/3] U-Boot-V2:Board:OMAP Introduce Beagle
This patch adds support for Beagle Board.
Beagle board from TI is a development platform
based on TI's OMAP3530 silicon.
You can find more about Beagle Board here: www.beagleboard.org
More on OMAP3530 (including documentation can be found here):
http://focus.ti.com/docs/prod/folders/print/omap3530.html
Signed-off-by: Raghavendra KH [EMAIL PROTECTED]
---
arch/arm/configs/omap3530_beagle_per_uart_defconfig | 185 +
arch/arm/mach-omap/arch-omap.dox|1
board/omap/Kconfig |9
board/omap/Makefile |1
board/omap/board-beagle.c | 276
5 files changed, 472 insertions(+)
Index: u-boot-v2/board/omap/board-beagle.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ u-boot-v2/board/omap/board-beagle.c 2008-06-24 02:26:07.0 +0200
@@ -0,0 +1,276 @@
+/**
+ * @file
+ * @brief Beagle Specific Board Initialization routines
+ *
+ * FileName: board/omap/board-beagle.c
+ *
+ * Beagle Board from Texas Instruments as described here:
+ * http://www.beagleboard.org
+ *
+ * This board is based on OMAP3530.
+ * More on OMAP3530 (including documentation can be found here):
+ * http://focus.ti.com/docs/prod/folders/print/omap3530.html
+ *
+ * This file provides initialization in two stages:
+ * @li boot time initialization - do basics required to get SDRAM working.
+ * This is run from SRAM - so no case constructs and global vars can be used.
+ * @li run time initialization - this is for the rest of the initializations
+ * such as flash, uart etc.
+ *
+ * Boot time initialization includes:
+ * @li SDRAM initialization.
+ * @li Pin Muxing relevant for Beagle.
+ *
+ * Run time initialization includes
+ * @li serial @ref serial_ns16550.c driver device definition
+ *
+ * Originally from board/omap/board-sdp343x.c
+ */
+/*
+ * (C) Copyright 2008
+ * Texas Instruments, www.ti.com
+ * Raghavendra KH [EMAIL PROTECTED]
+ *
+ * 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 common.h
+#include console.h
+#include init.h
+#include driver.h
+#include asm/io.h
+#include ns16550.h
+#include asm/arch/silicon.h
+#include asm/arch/sdrc.h
+#include asm/arch/sys_info.h
+#include asm/arch/syslib.h
+#include asm/arch/control.h
+#include asm/arch/omap3-mux.h
+#include board.h
+
+/ Board Boot Time ***/
+
+/**
+ * @brief Do the SDRC initialization for 128Meg Micron DDR for CS0
+ *
+ * @return void
+ */
+static void sdrc_init(void)
+{
+ /* SDRAM software reset */
+ /* No idle ack and RESET enable */
+ __raw_writel(0x1A, SDRC_REG(SYSCONFIG));
+ sdelay(100);
+ /* No idle ack and RESET disable */
+ __raw_writel(0x18, SDRC_REG(SYSCONFIG));
+
+ /* SDRC Sharing register */
+ /* 32-bit SDRAM on data lane [31:0] - CS0 */
+ /* pin tri-stated = 1 */
+ __raw_writel(0x0100, SDRC_REG(SHARING));
+
+ /* - SDRC Registers Configuration - */
+ /* SDRC_MCFG0 register */
+ __raw_writel(0x02584099, SDRC_REG(MCFG_0));
+
+ /* SDRC_RFR_CTRL0 register */
+ __raw_writel(0x54601, SDRC_REG(RFR_CTRL_0));
+
+ /* SDRC_ACTIM_CTRLA0 register */
+ __raw_writel(0xA29DB4C6, SDRC_REG(ACTIM_CTRLA_0));
+
+ /* SDRC_ACTIM_CTRLB0 register */
+ __raw_writel(0x12214, SDRC_REG(ACTIM_CTRLB_0));
+
+ /* Disble Power Down of CKE due to 1 CKE on combo part */
+ __raw_writel(0x0081, SDRC_REG(POWER));
+
+ /* SDRC_MANUAL command register */
+ /* NOP command */
+ __raw_writel(0x, SDRC_REG(MANUAL_0));
+ /* Precharge command */
+ __raw_writel(0x0001, SDRC_REG(MANUAL_0));
+ /* Auto-refresh command */
+ __raw_writel(0x0002, SDRC_REG(MANUAL_0));
+ /* Auto-refresh command */
+ __raw_writel(0x0002, SDRC_REG(MANUAL_0));
+
+ /* SDRC MR0 register Burst length=4 */
+ __raw_writel(0x0032, SDRC_REG(MR_0));
+
+ /* SDRC DLLA control register */
+ __raw_writel(0x000A, SDRC_REG(DLLA_CTRL));
+
+ return;
+}
+
+/**
+ * @brief Do the pin muxing required for Board operation.
+ * We enable ONLY the pins we require to set. OMAP
Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512
Claudio, In the data sheet I can not find a reference to on oobsize of 512, But I do find the 0x2E on page 24 under byte 3 description. It brakes down to; page size = 4K Spare area size (bytes) = 218 Block size = 256KB Organization = x8 Serial access (MIN) = 20ns I did find a reference to this architecture size as being the next generation on large NAND flash devices. you can find it at www.toshiba.com/taec/flashsummit/NANDIntro_FlashMemorySummitv_7_6-21-07.pdf page 14, shows a road map. Also the check out the ONIF 2.0 spec. I also references the larger size. Unfortunately If you need this soon you will have to implement it, but then you name can go down in history. Otherwise since this looks like the tren for newer larger flash chips it, someone eventually will implement it, but probably not on your time table. Good Luck Stuart On Mon, Jul 21, 2008 at 6:07 PM, Spinelli, Claudio (Claudio) [EMAIL PROTECTED] wrote: Stuart, Thanks for your help. I still do not understand something from the datasheet. If the oobsize is 512 bytes, how come the page is 4096 + 218 bytes. I would think it should be 4096 + 512 bytes. What do you think? Claudio -Original Message- From: Stuart Wood [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2008 5:18 PM To: Spinelli, Claudio (Claudio) Cc: uboot Subject: Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512 Thanks Claudio for the information, I've taken a look at the data sheet and it does not fit the typical large page flash, but It does not mean its not supported under Linux which is were the FLASH subsystem in U-Boot comes from. Neither am I familiar with the open nand flash interface onfi.org. BUT this should not be too difficult to add to u-boot or the Linux's MTD layer. The hardest part is the odd OOB size. It's 10 Bytes longer than twice the large page size. Look at the MTD pages for help porting http://www.linux-mtd.infradead.org/doc/nand.html; Good Luck Stuart -Original Message- From: Stuart Wood [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2008 4:01 PM To: Spinelli, Claudio (Claudio) Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512 Claudio, This does not appear to be a standard large page device witch has; page size of 2048 bytes plus 64 bytes OOB block size of 129KiB plus 4096 OOB Do you have the data sheet or are you determining the information below from the ID byte? Stuart http://www.linux-mtd.infradead.org/doc/nand.html On Mon, Jul 21, 2008 at 3:34 PM, Spinelli, Claudio (Claudio) [EMAIL PROTECTED] wrote: Stuart, It is as follows: The fourth byte is 0x2E which breaks down as follows: oobsize = 512 oobblock = 4096 erasesize = 256k busw = 8 Additional info: 1 page = 4k + 218 bytes 1 block = (4k +218 bytes) x 64 pages = (256k +13k) bytes Device total size = 8,608Mbit Thanks Claudio -Original Message- From: Stuart Wood [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 11:33 PM To: Spinelli, Claudio (Claudio) Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512 Claudio, OK, Micron does not like to share there data sheets, so I can't look up the part. You will need to describe the part then. SLC or MLC? (presumably MLC) Page Size? Block Size? OOB per Page? With that information people should be able to help you. I, myself, have never used the MLC NAND Flash so I don't know if it differers from the SLC types. I do now that both Large and Small page SLC Flash is well supported. Stuart On Sat, Jul 19, 2008 at 5:18 PM, Spinelli, Claudio (Claudio) [EMAIL PROTECTED] wrote: MICRON MT29F8G08AAA -Original Message- From: Stuart Wood [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 4:22 PM To: Spinelli, Claudio (Claudio) Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] nand_oobinfo for 1Gbyte nand flash with oobsize=512 It would be much more useful if you stated what the part number and manufacturer were. Stuart On Sat, Jul 19, 2008 at 12:18 PM, claudio123 [EMAIL PROTECTED] wrote: Hi, Has anybody used 1GByte nand flash with 1 die and oobsize of 512, oobblock =4096. Do you know how to create the static struct nand_oobinfo in nand_base.c for a oobsize of 512. Does anyboody have support in uboot or linux kernel for such nand flash. Thanks Regards Claudio -- View this message in context: http://www.nabble.com/nand_oobinfo-for-1Gbyte-nand-flash-with-oobsi z e % 3D512-tp18546190p18546190.html Sent from the Uboot - Users mailing list archive at Nabble.com. --- - - - --- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a
Re: [U-Boot-Users] [PATCH] (Resubmit) ADD ARM AMBA PL031 RTC Support
Hi j, Could you please send your patch as inline, otherwise it's really difficult to comment use git-send-email as example and also please read this http://www.denx.de/wiki/UBoot/Patches and http://lwn.net/Articles/139918/ Sorry for the whitespace mistakes. i have now corrected it. But regarding sending patch inline i am finding it very difficult. I am using MS Off Outlook to send patches to uboot and other mailing lists. I also pasted the same code that i copied from patch files to the mail. Since i think it wraps and creates other issues, i am attaching the patch that i generated using diff -purN . Since our proxy server has some issue, i am not to clone from uboot git server. So here is the thing. I have downloaded uboot-1.3.3.tar.bz2 and extracted to local system. I have copied to the same to a diff directory on which i work. so, u-boot-1.3.3/ --- original unmodified source uboot/ --- modified source I take a diff of these two folders and send it as patch. Now from past few days i am trying to use git to create and send patch to mailing list. Here is what i do, 1. 1st i tried diff -purN u-boot-1.3.3/drivers/rtc uboot/drivers/rtc/ new_pl031_rtc_drvr.patch to create a well known patch creation command 2. then i tried git-diff -p --summary --stat u-boot-1.3.3/drivers/rtc/ uboot/drivers/rtc new_pl031_rtc_drvr_v2.patch to create another patch. Both didnt have match difference except the 2nd give me few more info. I sent 2 mail to uboot mailing list, each time picking patch from each step and also pasting from the patch file 3. Now i tried git-format-patch $ git-format-patch.exe u-boot-1.3.3/drivers/rtc/ uboot/drivers/rtc/ fatal: Not a git repository So kindly know how to solve this. Regards Gururaja - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] (Resubmit) ADD ARM AMBA PL031 RTC Support
Hi,
I think nabble wont truncate or line wrap my mail. So i am giving it a try.
I have added changes required for versatile board to call rtc_init
defines in include/configs/versatile.h to include pl031 rtc definitions
Kindly comment
TIA
Regards
Gururaja
- Add ARM AMBA PL031 RTC Support
- Call rtc_init function to start pl031 rtc if enabled from versatile.c
- Define rtc base address and date command support in versatile.h
Signed-off-by: Gururaja [EMAIL PROTECTED]
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
old mode 100644
new mode 100755
index 2e0c118..f888a31
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -56,6 +56,7 @@ COBJS-y += rs5c372.o
COBJS-y += rx8025.o
COBJS-y += s3c24x0_rtc.o
COBJS-y += x1205.o
+COBJS-y += rtc_pl031.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/rtc/rtc_pl031.c b/drivers/rtc/rtc_pl031.c
new file mode 100755
index 000..7136fed
--- /dev/null
+++ b/drivers/rtc/rtc_pl031.c
@@ -0,0 +1,121 @@
+/*
+ * (C) Copyright 2008
+ * Gururaja Hebbar [EMAIL PROTECTED]
+ *
+ * reference linux-2.6.20.6/drivers/rtc/rtc-pl031.c
+ *
+ * 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 common.h
+#include command.h
+#include rtc.h
+
+#if defined(CONFIG_RTC_PL031) defined(CONFIG_CMD_DATE)
+
+#ifndef CFG_RTC_PL031_BASE
+#error CFG_RTC_PL031_BASE is not defined!
+#endif
+
+/*
+ * Register definitions
+ */
+#defineRTC_DR 0x00/* Data read register */
+#defineRTC_MR 0x04/* Match register */
+#defineRTC_LR 0x08/* Data load register */
+#defineRTC_CR 0x0c/* Control register */
+#defineRTC_IMSC0x10/* Interrupt mask and set register */
+#defineRTC_RIS 0x14/* Raw interrupt status register */
+#defineRTC_MIS 0x18/* Masked interrupt status register */
+#defineRTC_ICR 0x1c/* Interrupt clear register */
+
+#define RTC_CR_START (1 0)
+
+#defineRTC_WRITE_REG(addr, val)(*(volatile unsigned int
*)(CFG_RTC_PL031_BASE + (addr)) = (val))
+#defineRTC_READ_REG(addr) (*(volatile unsigned int
*)(CFG_RTC_PL031_BASE
+ (addr)))
+
+static int pl031_initted = 0;
+
+/* Enable RTC Start in Control register*/
+void rtc_init(void)
+{
+ RTC_WRITE_REG(RTC_CR,RTC_CR_START);
+
+ pl031_initted = 1;
+}
+
+/*
+ * Reset the RTC. We set the date back to 1970-01-01.
+ */
+void rtc_reset(void)
+{
+ RTC_WRITE_REG(RTC_LR,0x00);
+ if(!pl031_initted)
+ rtc_init();
+}
+
+/*
+ * Set the RTC
+*/
+void rtc_set(struct rtc_time *tmp)
+{
+ unsigned long tim;
+
+ if(!pl031_initted)
+ rtc_init();
+
+ if (tmp == NULL) {
+ puts(Error setting the date/time\n);
+ return;
+ }
+
+ /* Calculate number of seconds this incoming time represents */
+ tim = mktime(tmp-tm_year, tmp-tm_mon, tmp-tm_mday,
+ tmp-tm_hour, tmp-tm_min, tmp-tm_sec);
+
+ RTC_WRITE_REG(RTC_LR,tim);
+}
+
+/*
+ * Get the current time from the RTC
+ */
+int rtc_get(struct rtc_time *tmp)
+{
+ ulong tim;
+
+ if(!pl031_initted)
+ rtc_init();
+
+ if (tmp == NULL) {
+ puts(Error getting the date/time\n);
+ return -1;
+ }
+
+ tim = RTC_READ_REG(RTC_DR);
+
+ to_tm (tim, tmp);
+
+ debug ( Get DATE: %4d-%02d-%02d (wday=%d) TIME: %2d:%02d:%02d\n,
+ tmp-tm_year, tmp-tm_mon, tmp-tm_mday, tmp-tm_wday,
+ tmp-tm_hour, tmp-tm_min, tmp-tm_sec);
+
+ return 0;
+}
+
+#endif
--
1.5.5.1
diff --git a/board/versatile/versatile.c b/board/versatile/versatile.c
index 9d1a25e..5bf7e85 100644
--- a/board/versatile/versatile.c
+++ b/board/versatile/versatile.c
@@ -41,6 +41,10 @@ void flash__init (void);
void ether__init (void);
void peripheral_power_enable (void);
+#if defined(CONFIG_RTC_PL031) defined(CONFIG_CMD_DATE)
+extern int rtc_init(void);
+#endif
+
#if defined(CONFIG_SHOW_BOOT_PROGRESS)
void show_boot_progress(int progress)
{
@@ -84,6 +88,11 @@ int board_init (void)
flash__init ();
ether__init ();
+
+#if
Re: [U-Boot-Users] [PATCH] JFFS2 command support on OneNAND
On Fri, Jul 18, 2008 at 11:09 PM, Fathi Boudra [EMAIL PROTECTED] wrote: Hi, I really would rather not duplicate all of this, which looks extremely similar to regular NAND. Is there reason why we don't use the mtd_info function pointer interface? Agreed, It's almost same as NAND code. Now nand code uses two modes, legacy and mtd. Because I don't want to break the NAND code , I used the duplicated code. Basically it should be used the common mtd style code except legacy. So first it added the current code, next time it tries to use the common interface and some code clean up. As it is right now, you can't have jffs2 command support on both NAND and OneNAND. Dunno if you could have this case (both NAND and OneNAND enabled) but it will fail to build: In file included from /u-boot-1.3.3/include/linux/mtd/onenand.h:21, from jffs2_1pass.c:279: /u-boot-1.3.3/include/linux/mtd/bbm.h:49: error: redefinition of 'struct nand_bbt_descr' In file included from jffs2_1pass.c:279: /u-boot-1.3.3/include/linux/mtd/onenand.h:36: error: redeclaration of enumerator 'FL_READY' /u-boot-1.3.3/include/linux/mtd/nand.h:212: error: previous definition of 'FL_READY' was here /u-boot-1.3.3/include/linux/mtd/onenand.h:37: error: redeclaration of enumerator 'FL_READING' /u-boot-1.3.3/include/linux/mtd/nand.h:213: error: previous definition of 'FL_READING' was here /u-boot-1.3.3/include/linux/mtd/onenand.h:38: error: redeclaration of enumerator 'FL_WRITING' /u-boot-1.3.3/include/linux/mtd/nand.h:214: error: previous definition of 'FL_WRITING' was here /u-boot-1.3.3/include/linux/mtd/onenand.h:39: error: redeclaration of enumerator 'FL_ERASING' /u-boot-1.3.3/include/linux/mtd/nand.h:215: error: previous definition of 'FL_ERASING' was here /u-boot-1.3.3/include/linux/mtd/onenand.h:40: error: redeclaration of enumerator 'FL_SYNCING' /u-boot-1.3.3/include/linux/mtd/nand.h:216: error: previous definition of 'FL_SYNCING' was here jffs2_1pass.c: In function 'put_fl_mem': jffs2_1pass.c:466: error: redefinition of 'id' jffs2_1pass.c:459: error: previous definition of 'id' was here make[1]: *** [jffs2_1pass.o] Error 1 Yes, you're right. it's complicit. However it's not related with this patch. It happens always at current source. Next time it will fix it. Thank you, Kyungmin Park - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
