Re: [U-Boot-Users] [AT91] Re: [PATCH] DataFlash AT45DB021 support
On Mon, May 26, 2008 at 02:03:42PM -0400, Matt Gessner wrote: Hi, all! I added code to handle the 011 chip, but I really didn't think anyone would be interested in it. If someone wants it, I can post it. Wolfgang, are these simple patches of any interest to the general community, when they're so trivial to add? Wolfgang, could you please answer this? Thanks a lot, S. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH v2] 85xx: Only use PORPLLSR[DDR_Ratio] on platforms that define it
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Fix warning that the first version introduced.
- k
cpu/mpc85xx/cpu.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index 9873383..58d23f4 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -75,8 +75,12 @@ int checkcpu (void)
uint ver;
uint major, minor;
int i;
- u32 ddr_ratio;
+#ifdef CONFIG_DDR_CLK_FREQ
volatile ccsr_gur_t *gur = (void *)(CFG_MPC85xx_GUTS_ADDR);
+ u32 ddr_ratio = ((gur-porpllsr) 0x3e00) 9;
+#else
+ u32 ddr_ratio = 0;
+#endif
svr = get_svr();
ver = SVR_SOC_VER(svr);
@@ -118,7 +122,7 @@ int checkcpu (void)
puts(Clock Configuration:\n);
printf( CPU:%4lu MHz, ,
DIV_ROUND_UP(sysinfo.freqProcessor,100));
printf(CCB:%4lu MHz,\n, DIV_ROUND_UP(sysinfo.freqSystemBus,100));
- ddr_ratio = ((gur-porpllsr) 0x3e00) 9;
+
switch (ddr_ratio) {
case 0x0:
printf( DDR:%4lu MHz (%lu MT/s data rate), ,
--
1.5.4.5
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
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] TQM: move TQM boards to board/tqc
[EMAIL PROTECTED] wrote: From: Wolfgang Grandegger [EMAIL PROTECTED] Move all TQM board directories to the vendor specific directory tqc for modules from TQ-Components GmbH (http://www.tqc.de). Note: this patch is too big for posting here and therefore I removed the hunks moving the files. I could provide the full patch on request. Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED] Wolfgang, could you please apply this patch/commit directly, if there are no objections. Thanks. Wolfgang. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] 85xx: extended cpu identification
The current cpu identification code is used just to return the name
of the processor at boot. There are some other locations that the name
is useful (device tree setup).
Also, we add a feature field to convey useful attributes of the processor.
(for 85xx we have a single feature to tell if the processor has a crypto
engine or not).
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
cpu/mpc85xx/cpu.c | 77 ++
include/asm-ppc/processor.h | 13 +++
2 files changed, 53 insertions(+), 37 deletions(-)
diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index 58d23f4..7c842de 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -32,38 +32,41 @@
DECLARE_GLOBAL_DATA_PTR;
-struct cpu_type {
- char name[15];
- u32 soc_ver;
+struct cpu_type cpu_type_list [] = {
+ CPU_TYPE_ENTRY(8533, 8533, 0),
+ CPU_TYPE_ENTRY(8533, 8533_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8540, 8540, 0),
+ CPU_TYPE_ENTRY(8541, 8541, 0),
+ CPU_TYPE_ENTRY(8541, 8541_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8543, 8543, 0),
+ CPU_TYPE_ENTRY(8543, 8543_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8544, 8544, 0),
+ CPU_TYPE_ENTRY(8544, 8544_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8545, 8545, 0),
+ CPU_TYPE_ENTRY(8545, 8545_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8547, 8547_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8548, 8548, 0),
+ CPU_TYPE_ENTRY(8548, 8548_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8555, 8555, 0),
+ CPU_TYPE_ENTRY(8555, 8555_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8560, 8560, 0),
+ CPU_TYPE_ENTRY(8567, 8567, 0),
+ CPU_TYPE_ENTRY(8567, 8567_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8568, 8568, 0),
+ CPU_TYPE_ENTRY(8568, 8568_E, CPU_FTRS_HAS_CRYPTO),
+ CPU_TYPE_ENTRY(8572, 8572, 0),
+ CPU_TYPE_ENTRY(8572, 8572_E, CPU_FTRS_HAS_CRYPTO),
};
-#define CPU_TYPE_ENTRY(x) {#x, SVR_##x}
+struct cpu_type *identify_cpu(uint ver)
+{
+ int i;
+ for (i = 0; i ARRAY_SIZE(cpu_type_list); i++)
+ if (cpu_type_list[i].soc_ver == ver)
+ return cpu_type_list[i];
-struct cpu_type cpu_type_list [] = {
- CPU_TYPE_ENTRY(8533),
- CPU_TYPE_ENTRY(8533_E),
- CPU_TYPE_ENTRY(8540),
- CPU_TYPE_ENTRY(8541),
- CPU_TYPE_ENTRY(8541_E),
- CPU_TYPE_ENTRY(8543),
- CPU_TYPE_ENTRY(8543_E),
- CPU_TYPE_ENTRY(8544),
- CPU_TYPE_ENTRY(8544_E),
- CPU_TYPE_ENTRY(8545),
- CPU_TYPE_ENTRY(8545_E),
- CPU_TYPE_ENTRY(8547_E),
- CPU_TYPE_ENTRY(8548),
- CPU_TYPE_ENTRY(8548_E),
- CPU_TYPE_ENTRY(8555),
- CPU_TYPE_ENTRY(8555_E),
- CPU_TYPE_ENTRY(8560),
- CPU_TYPE_ENTRY(8567),
- CPU_TYPE_ENTRY(8567_E),
- CPU_TYPE_ENTRY(8568),
- CPU_TYPE_ENTRY(8568_E),
- CPU_TYPE_ENTRY(8572),
- CPU_TYPE_ENTRY(8572_E),
-};
+ return NULL;
+}
int checkcpu (void)
{
@@ -74,7 +77,7 @@ int checkcpu (void)
uint fam;
uint ver;
uint major, minor;
- int i;
+ struct cpu_type *cpu;
#ifdef CONFIG_DDR_CLK_FREQ
volatile ccsr_gur_t *gur = (void *)(CFG_MPC85xx_GUTS_ADDR);
u32 ddr_ratio = ((gur-porpllsr) 0x3e00) 9;
@@ -89,14 +92,14 @@ int checkcpu (void)
puts(CPU: );
- for (i = 0; i ARRAY_SIZE(cpu_type_list); i++)
- if (cpu_type_list[i].soc_ver == ver) {
- puts(cpu_type_list[i].name);
- break;
- }
-
- if (i == ARRAY_SIZE(cpu_type_list))
+ cpu = identify_cpu(ver);
+ if (cpu) {
+ puts(cpu-name);
+ if (cpu-features CPU_FTRS_HAS_CRYPTO)
+ puts(E);
+ } else {
puts(Unknown);
+ }
printf(, Version: %d.%d, (0x%08x)\n, major, minor, svr);
diff --git a/include/asm-ppc/processor.h b/include/asm-ppc/processor.h
index 8bdfb9d..acbf98a 100644
--- a/include/asm-ppc/processor.h
+++ b/include/asm-ppc/processor.h
@@ -960,6 +960,19 @@ n:
#define SR15 15
#ifndef __ASSEMBLY__
+
+struct cpu_type {
+ char name[15];
+ u32 soc_ver;
+ u32 features;
+};
+
+struct cpu_type *identify_cpu(uint ver);
+
+#define CPU_TYPE_ENTRY(n, v, f) \
+ { .name = #n, .soc_ver = SVR_##v, .features = f }
+#define CPU_FTRS_HAS_CRYPTO0x0001
+
#ifndef CONFIG_MACH_SPECIFIC
extern int _machine;
extern int have_of;
--
1.5.4.5
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Add sata sil3114 support (V2)
Add support for Silicon Images sil3114 sata chip using libata
Changes since last version
* use debug() print instead of local version
* Coding standard and whitespace fixes
Signed-off-by: Tor Krill [EMAIL PROTECTED]
---
drivers/block/Makefile |1 +
drivers/block/sata_sil3114.c | 839 ++
drivers/block/sata_sil3114.h | 147
3 files changed, 987 insertions(+), 0 deletions(-)
create mode 100644 drivers/block/sata_sil3114.c
create mode 100644 drivers/block/sata_sil3114.h
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 5f1298d..a09cd2a 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -29,6 +29,7 @@ COBJS-y += ahci.o
COBJS-y += ata_piix.o
COBJS-$(CONFIG_FSL_SATA) += fsl_sata.o
COBJS-$(CONFIG_LIBATA) += libata.o
+COBJS-$(CONFIG_SATA_SIL3114) += sata_sil3114.o
COBJS-y += sil680.o
COBJS-y += sym53c8xx.o
COBJS-y += systemace.o
diff --git a/drivers/block/sata_sil3114.c b/drivers/block/sata_sil3114.c
new file mode 100644
index 000..8399737
--- /dev/null
+++ b/drivers/block/sata_sil3114.c
@@ -0,0 +1,839 @@
+/*
+ * Copyright (C) Excito Elektronik i Skåne AB, All rights reserved.
+ * Author: Tor Krill [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
+ *
+ * This is a driver for Silicon Image sil3114 sata chip modelled on
+ * the ata_piix driver
+ */
+
+#include common.h
+#include pci.h
+#include command.h
+#include config.h
+#include asm/byteorder.h
+#include asm/io.h
+#include ide.h
+#include libata.h
+#include sata_sil3114.h
+
+/* Convert sectorsize to wordsize */
+#define ATA_SECTOR_WORDS (ATA_SECT_SIZE/2)
+
+/* Forwards */
+u8 sil3114_spin_up (int num);
+u8 sil3114_spin_down (int num);
+static int sata_bus_softreset (int num);
+static void sata_identify (int num, int dev);
+static u8 check_power_mode (int num);
+static void sata_port (struct sata_ioports *ioport);
+static void set_Feature_cmd (int num, int dev);
+static u8 sata_busy_wait (struct sata_ioports *ioaddr, int bits,
+ unsigned int max, u8 usealtstatus);
+static u8 sata_chk_status (struct sata_ioports *ioaddr, u8 usealtstatus);
+static void msleep (int count);
+
+static u32 iobase[6] = { 0, 0, 0, 0, 0, 0};/* PCI BAR registers for device
*/
+extern block_dev_desc_t sata_dev_desc[CFG_SATA_MAX_DEVICE];
+
+static struct sata_port port[CFG_SATA_MAX_DEVICE];
+
+static void output_data (struct sata_ioports *ioaddr, u16 * sect_buf, int
words)
+{
+ while (words--) {
+ __raw_writew (*sect_buf++, (void *)ioaddr-data_addr);
+ }
+}
+
+static int input_data (struct sata_ioports *ioaddr, u16 * sect_buf, int words)
+{
+ while (words--) {
+ *sect_buf++ = __raw_readw ((void *)ioaddr-data_addr);
+ }
+ return 0;
+}
+
+static int sata_bus_softreset (int num)
+{
+ u8 status = 0;
+
+ port[num].dev_mask = 1;
+
+ port[num].ctl_reg = 0x08; /*Default value of control reg */
+ writeb (port[num].ctl_reg, port[num].ioaddr.ctl_addr);
+ udelay (10);
+ writeb (port[num].ctl_reg | ATA_SRST, port[num].ioaddr.ctl_addr);
+ udelay (10);
+ writeb (port[num].ctl_reg, port[num].ioaddr.ctl_addr);
+
+ /* spec mandates = 2ms before checking status.
+* We wait 150ms, because that was the magic delay used for
+* ATAPI devices in Hale Landis's ATADRVR, for the period of time
+* between when the ATA command register is written, and then
+* status is checked. Because waiting for a while before
+* checking status is fine, post SRST, we perform this magic
+* delay here as well.
+*/
+ msleep (150);
+ status = sata_busy_wait (port[num].ioaddr, ATA_BUSY, 300, 0);
+ while ((status ATA_BUSY)) {
+ msleep (100);
+ status = sata_busy_wait (port[num].ioaddr, ATA_BUSY, 3, 0);
+ }
+
+ if (status ATA_BUSY) {
+ printf (ata%u is slow to respond,plz be patient\n, port);
+ }
+
+ while ((status ATA_BUSY)) {
+ msleep (100);
+ status = sata_chk_status (port[num].ioaddr, 0);
+ }
+
+ if (status ATA_BUSY) {
+ printf (ata%u failed to respond : , port);
+ printf (bus reset
[U-Boot-Users] [PATCH] Fix incorrect switch for IF_TYPE in part.c
Use correct field in block_dev_desc_t when writing interface type in dev_print.
Error introduced in 574b319512b13e10800f0045e39b993f4ca25e42.
Changes:
* Added fix from Martin Krause
Signed-off-by: Tor Krill [EMAIL PROTECTED]
---
disk/part.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/disk/part.c b/disk/part.c
index 316e254..5c4bf6b 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -109,7 +109,7 @@ void dev_print (block_dev_desc_t *dev_desc)
lbaint_t lba512;
#endif
- switch (dev_desc-type) {
+ switch (dev_desc-if_type) {
case IF_TYPE_SCSI:
printf ((%d:%d) Vendor: %s Prod.: %s Rev: %s\n,
dev_desc-target,dev_desc-lun,
@@ -124,7 +124,7 @@ void dev_print (block_dev_desc_t *dev_desc)
dev_desc-revision,
dev_desc-product);
break;
- case DEV_TYPE_UNKNOWN:
+ case IF_TYPE_UNKNOWN:
default:
puts (not available\n);
return;
--
1.5.5.1
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Latest U-Boot MD5 compile error??
All, Okay, I have tracked this farther into the compilation problem. I have no reason to believe that 'my system' is any different that any standard stock FC5 box, other than its been original since FC5 was released, pending updates. Looking through the code, though I haven't nailed it, it would seem that between: #include linux/types.h typedef __kernel_dev_t dev_t; #include asm/posix_types.h typedef unsigned int__kernel_dev_t; There are discrepancies in how '__kernel_dev_t' is defined. Now, I haven't found yet where 'dev_t' is defined. Can somebody possibly think of a reason this is being thrown? Again, I have downloaded the latest U-boot git tree, like 5 times to ensure that I am not using 'corrupted' code. Also have ensure that this problem doesn't exist prior to commit SHA - 8cf30809a82902a471866d2f07725ce3b8a22291. -Russ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2008 2:56 PM To: [EMAIL PROTECTED] Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] Latest U-Boot MD5 compile error?? In message [EMAIL PROTECTED] you wrote: Just pulled the latest GIT down today 1.3.3+, merged with my current code. Note, last I pulled was back at 1.3.1. Anyway, all is well until the newish MD5 code attempts to compile then I get two different types of errors. See Log Below Is this an artificat of an uncomplete merge perhaps? Probably. Try building for some other boards... Dependencies on a certain level of kernel that needs to be sitting in the ppc_6xx/usr/src/ directory? Or perhaps is FC5 to old to now correctly compile the latest U-boot? To old of an ELDK? I am using ELDK 4.1 Just tried to build a few boards on a FC5 host. A few warnings about including /usr/include/asm/byteorder.h, but it builds fine. 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] There is enough for the need of everyone in this world, but not for the greed of everyone. - Mahatma Gandhi - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Very slow JFFS2 scan time and directory listing
In Message-ID: [EMAIL PROTECTED] you wrote: It's taking an extremely long time to do a directory listing using the 'ls' command with JFFS2. Its taking nearly a minute to scan the file system and then about 1 second to print each line. What is could be the cause of this, and is there any way to speed this up currently? I too am suffering from this very slow JFFS2 problem. It is especially bad for NAND flash. I modified the fs/jffs2/Makefile to use fs/jffs2/jffs2_nand_1pass.c instead of jffs2_1pass.c, but that would not build. I eventually fixed that by quite large changes, but it still ran very slowly despite reading larger chunks of NAND. Has anyone out there fixed this problem? Regards, Mark - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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] TQM85xx: NAND support via local bus UPMB
On Wed, May 28, 2008 at 08:38:37PM +0200, Wolfgang Grandegger wrote: Scott Wood wrote: On Wed, May 28, 2008 at 08:12:28PM +0200, Wolfgang Grandegger wrote: This patch adds support for NAND FLASH on the TQM8548. It is disabled by default and can be enabled for the TQM8548 modules. Note that the R/B pin is not supported by that module requiring to use the specified maximum delay time. Note: With NAND support enabled the size of the U-Boot image exceeds 256 KB and TEXT_BASE must therefore be set to 0xfff8 in config.mk, doubling the image size :-(. What does this do differently from the code in drivers/mtd/nand/fsl_upm.c? Maybe it does not support multi banks on a NAND chip. I have to check. Me thinks that you'll have to call fsl_upm_nand_init() for each chip, and that's all. If not, feel free to patch it as you feel appropriate, I'll able to regress-test this driver on MPC8360E-RDK. How much of this is board-specific? Well, I already gave drivers/mtd/nand/fsl_upm.c a try but was unable to get it working on this board. Therefore I decided to keep this known to work driver which we have already for a while. This isn't really an excuse to duplicate drivers. :-) This driver was tested on MPC8555 and MPC8360 CPUs, so it should work with no drastic changes. Some issues might still be there, and if so, fixes are highly appreciated. With Linux, I had more success. ..especially if general idea works well, we should use single driver. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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] TQM85xx: NAND support via local bus UPMB
Anton Vorontsov wrote:
On Wed, May 28, 2008 at 08:38:37PM +0200, Wolfgang Grandegger wrote:
Scott Wood wrote:
On Wed, May 28, 2008 at 08:12:28PM +0200, Wolfgang Grandegger wrote:
This patch adds support for NAND FLASH on the TQM8548. It is disabled by
default and can be enabled for the TQM8548 modules. Note that the R/B pin
is not supported by that module requiring to use the specified maximum
delay time.
Note: With NAND support enabled the size of the U-Boot image exceeds
256 KB and TEXT_BASE must therefore be set to 0xfff8 in config.mk,
doubling the image size :-(.
What does this do differently from the code in drivers/mtd/nand/fsl_upm.c?
Maybe it does not support multi banks on a NAND chip. I have to check.
Me thinks that you'll have to call fsl_upm_nand_init() for each
chip, and that's all. If not, feel free to patch it as you feel appropriate,
I'll able to regress-test this driver on MPC8360E-RDK.
That seems not to be a minor problem. If CFG_MAX_NAND_DEVICE 1,
board_nand_init() will be called twice with the base address from
CFG_NAND_BASE_LIST. The only problem I see is that the UPM interface is
setup twice.
How much of this is board-specific?
Well, I already gave drivers/mtd/nand/fsl_upm.c a try but was unable to
get it working on this board. Therefore I decided to keep this known to
work driver which we have already for a while.
This isn't really an excuse to duplicate drivers. :-) This driver was
tested on MPC8555 and MPC8360 CPUs, so it should work with no drastic
changes. Some issues might still be there, and if so, fixes are highly
appreciated.
I know, sniff.
With Linux, I had more success.
..especially if general idea works well, we should use single driver.
I already had a closer look and realized a difference in writing the UPM
array. In fsl_upm.c there is:
static void fsl_upm_setup(struct fsl_upm *upm)
{
int i;
/* write upm array */
out_be32(upm-mxmr, FSL_UPM_MxMR_OP_WA);
for (i = 0; i 64; i++) {
out_be32(upm-mdr, upm-array[i]);
out_8(upm-io_addr, 0x0);
}
/* normal operation */
out_be32(upm-mxmr, FSL_UPM_MxMR_OP_NO);
while (in_be32(upm-mxmr) != FSL_UPM_MxMR_OP_NO)
eieio();
}
But in my driver I fold the machine address into mbmr for each value:
out_be32 (lbc-mbmr,
(in_be32 (lbc-mbmr) ~(MxMR_OP_NORM | MxMR_MAD)) |
MxMR_OP_WARR | (i MxMR_MAD));
^
Seem also that defines a duplicated :-(.
Has it been tested with an MPC85xx? I will do some more test now.
Wolfgang.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] can u-boot run standalone in qemu(qemu-system-arm) without kernel image(for mainstone II)
hi, all I'm a newbie to both u-boot and qemu. Maybe it's a silly question, but I can not find the solution through the Internet for almost 2 weeks, sorry :( Here is my question: I wanna run u-boot as a standalone app (or image?) in qemu, and I do't wanna any create linux image. Is that possible? I just wanna to study u-boot. And now, my idea is to create a flash image with u-boot, how about this way? Any reply would be appreciated. Thank you in advance :) stones. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ 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] TQM85xx: NAND support via local bus UPMB
On Thu, May 29, 2008 at 01:58:14PM +0200, Wolfgang Grandegger wrote:
Anton Vorontsov wrote:
On Wed, May 28, 2008 at 08:38:37PM +0200, Wolfgang Grandegger wrote:
Scott Wood wrote:
On Wed, May 28, 2008 at 08:12:28PM +0200, Wolfgang Grandegger wrote:
This patch adds support for NAND FLASH on the TQM8548. It is disabled by
default and can be enabled for the TQM8548 modules. Note that the R/B pin
is not supported by that module requiring to use the specified maximum
delay time.
Note: With NAND support enabled the size of the U-Boot image exceeds
256 KB and TEXT_BASE must therefore be set to 0xfff8 in config.mk,
doubling the image size :-(.
What does this do differently from the code in drivers/mtd/nand/fsl_upm.c?
Maybe it does not support multi banks on a NAND chip. I have to check.
Me thinks that you'll have to call fsl_upm_nand_init() for each
chip, and that's all. If not, feel free to patch it as you feel appropriate,
I'll able to regress-test this driver on MPC8360E-RDK.
That seems not to be a minor problem. If CFG_MAX_NAND_DEVICE 1,
board_nand_init() will be called twice with the base address from
CFG_NAND_BASE_LIST. The only problem I see is that the UPM interface is
setup twice.
Personally I think we should remove UPM programming code from the
fsl_upm_nand.c, and program the UPM via its own interface, see this post:
From: David Saada [EMAIL PROTECTED]
To: 'u-boot-users@lists.sourceforge.net' u-boot-users@lists.sourceforge.net
Date: Mon, 19 May 2008 19:05:04 +0300
Subject: [U-Boot-Users] [PATCH][resubmit] MPC85xx, MPC83xx: Add/Fix UPM
configuration support
^^^ But this is still WIP, and I'm not sure if this is suitable for our
needs (didn't try it).
How much of this is board-specific?
Well, I already gave drivers/mtd/nand/fsl_upm.c a try but was unable to
get it working on this board. Therefore I decided to keep this known to
work driver which we have already for a while.
This isn't really an excuse to duplicate drivers. :-) This driver was
tested on MPC8555 and MPC8360 CPUs, so it should work with no drastic
changes. Some issues might still be there, and if so, fixes are highly
appreciated.
I know, sniff.
With Linux, I had more success.
..especially if general idea works well, we should use single driver.
I already had a closer look and realized a difference in writing the UPM
array. In fsl_upm.c there is:
static void fsl_upm_setup(struct fsl_upm *upm)
{
int i;
/* write upm array */
out_be32(upm-mxmr, FSL_UPM_MxMR_OP_WA);
for (i = 0; i 64; i++) {
out_be32(upm-mdr, upm-array[i]);
out_8(upm-io_addr, 0x0);
}
/* normal operation */
out_be32(upm-mxmr, FSL_UPM_MxMR_OP_NO);
while (in_be32(upm-mxmr) != FSL_UPM_MxMR_OP_NO)
eieio();
}
But in my driver I fold the machine address into mbmr for each value:
out_be32 (lbc-mbmr,
(in_be32 (lbc-mbmr) ~(MxMR_OP_NORM | MxMR_MAD)) |
MxMR_OP_WARR | (i MxMR_MAD));
^
I see. I think there will be a problem with a
static void fsl_upm_start_pattern(struct fsl_upm *upm, u32 pat_offset)
{
out_be32(upm-mxmr, FSL_UPM_MxMR_OP_RP | pat_offset);
}
static void fsl_upm_end_pattern(struct fsl_upm *upm)
{
out_be32(upm-mxmr, FSL_UPM_MxMR_OP_NO);
while (in_be32(upm-mxmr) != FSL_UPM_MxMR_OP_NO)
eieio();
}
Since it zeroes these values. No problem though, this should
be replaced by the Linux' versions, that is
clrsetbits_be32(upm-mxmr, MxMR_MAD, MxMR_OP_RP | pat_offset);
for start_pattern, and clrbits32(upm-mxmr, MxMR_OP_RP); for
end_pattern.
So, this will leave your values intact, and will work for all boards as
well.
Seem also that defines a duplicated :-(.
No problem. Please, remove the ones you don't like, and leave the ones
you do like. :-) Feel completely free to do everything you need to make
fsl_upm_nand.c work on your hardware, and then we'll see what we can do
to make our hardware work together.
As for UPM programming, as I've said, just remove UPM programming code
from the NAND driver, and leave it in the board file until (if) we'll
start using generic interface.
Has it been tested with an MPC85xx? I will do some more test now.
Yup, MPC8555.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Very slow JFFS2 scan time and directory listing
On Thu, May 29, 2008 at 6:39 AM, Mark Craske [EMAIL PROTECTED] wrote: In Message-ID: [EMAIL PROTECTED] you wrote: It's taking an extremely long time to do a directory listing using the 'ls' command with JFFS2. Its taking nearly a minute to scan the file system and then about 1 second to print each line. What is could be the cause of this, and is there any way to speed this up currently? I too am suffering from this very slow JFFS2 problem. It is especially bad for NAND flash. I'm also using NAND flash, and at this time the performance off JFFS2 will not allow us to use it even though we'd like too. I modified the fs/jffs2/Makefile to use fs/jffs2/jffs2_nand_1pass.c instead of jffs2_1pass.c, but that would not build. I eventually fixed that by quite large changes, but it still ran very slowly despite reading larger chunks of NAND. I've not yet looked at the code so you know more than I do, but we were speculating that the JFFS layer was not building an inode table in RAM, so that each time it finds a file it goes back to the begining of the fs and starts searching for the next without remembering what it has already seen. Does this make sense? Would caching the inodes in RAM help? -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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 1/2] 83xx/85xx/86xx: factor out Freescale Localbus defines out of mpc83xx.h
On Wed, May 28, 2008 at 12:23:01PM -0500, Scott Wood wrote: Anton Vorontsov wrote: This patch moves Freescale Localbus defines out of mpc83xx.h, so we could use it on MPC85xx and MPC86xx processors. Can we similarly merge lbus83xx_t with ccsr_lbc? Yes, why not. But this will need much more efforts. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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 shell variable UNDEF_SYM.
UNDEF_SYM is a shell variable in the main Makefile used to force the
linker to add all u-boot commands to the final image. It has no use here.
Signed-off-by: Kenneth Johansson [EMAIL PROTECTED]
---
nand_spl/board/amcc/acadia/Makefile |2 +-
nand_spl/board/amcc/bamboo/Makefile |2 +-
nand_spl/board/amcc/canyonlands/Makefile |2 +-
nand_spl/board/amcc/kilauea/Makefile |2 +-
nand_spl/board/amcc/sequoia/Makefile |2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/nand_spl/board/amcc/acadia/Makefile
b/nand_spl/board/amcc/acadia/Makefile
index 4272108..931f04b 100644
--- a/nand_spl/board/amcc/acadia/Makefile
+++ b/nand_spl/board/amcc/acadia/Makefile
@@ -51,7 +51,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl
$(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
$(nandobj)u-boot-spl: $(OBJS)
- cd $(LNDIR) $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
+ cd $(LNDIR) $(LD) $(LDFLAGS) $(__OBJS) \
-Map $(nandobj)u-boot-spl.map \
-o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/amcc/bamboo/Makefile
b/nand_spl/board/amcc/bamboo/Makefile
index aed7960..e1c1467 100644
--- a/nand_spl/board/amcc/bamboo/Makefile
+++ b/nand_spl/board/amcc/bamboo/Makefile
@@ -50,7 +50,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl
$(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
$(nandobj)u-boot-spl: $(OBJS)
- cd $(LNDIR) $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
+ cd $(LNDIR) $(LD) $(LDFLAGS) $(__OBJS) \
-Map $(nandobj)u-boot-spl.map \
-o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/amcc/canyonlands/Makefile
b/nand_spl/board/amcc/canyonlands/Makefile
index 47c7d02..fb86752 100644
--- a/nand_spl/board/amcc/canyonlands/Makefile
+++ b/nand_spl/board/amcc/canyonlands/Makefile
@@ -55,7 +55,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl
$(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
$(nandobj)u-boot-spl: $(OBJS)
- cd $(LNDIR) $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
+ cd $(LNDIR) $(LD) $(LDFLAGS) $(__OBJS) \
-Map $(nandobj)u-boot-spl.map \
-o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/amcc/kilauea/Makefile
b/nand_spl/board/amcc/kilauea/Makefile
index 84bd298..f47261f 100644
--- a/nand_spl/board/amcc/kilauea/Makefile
+++ b/nand_spl/board/amcc/kilauea/Makefile
@@ -50,7 +50,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl
$(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
$(nandobj)u-boot-spl: $(OBJS)
- cd $(LNDIR) $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
+ cd $(LNDIR) $(LD) $(LDFLAGS) $(__OBJS) \
-Map $(nandobj)u-boot-spl.map \
-o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/amcc/sequoia/Makefile
b/nand_spl/board/amcc/sequoia/Makefile
index 93150aa..fba0322 100644
--- a/nand_spl/board/amcc/sequoia/Makefile
+++ b/nand_spl/board/amcc/sequoia/Makefile
@@ -50,7 +50,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl
$(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
$(nandobj)u-boot-spl: $(OBJS)
- cd $(LNDIR) $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
+ cd $(LNDIR) $(LD) $(LDFLAGS) $(__OBJS) \
-Map $(nandobj)u-boot-spl.map \
-o $(nandobj)u-boot-spl
--
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
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 1/2] 83xx/85xx/86xx: factor out Freescale Localbus defines out of mpc83xx.h
On Wed, May 28, 2008 at 12:21:26PM -0500, Kim Phillips wrote: On Wed, 28 May 2008 18:20:15 +0400 Anton Vorontsov [EMAIL PROTECTED] wrote: This patch moves Freescale Localbus defines out of mpc83xx.h, so we could use it on MPC85xx and MPC86xx processors. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- include/asm-ppc/fsl_lbc.h | 251 + include/mpc83xx.h | 234 +- include/mpc85xx.h |2 + include/mpc86xx.h |2 + 4 files changed, 256 insertions(+), 233 deletions(-) create mode 100644 include/asm-ppc/fsl_lbc.h can we move the BRx_* and ORx_* left behind in mpc85xx.h also? Yes, easily (because there is no single user). The same is needed for mpc8xx.h and mpc8260.h (defines are almost the same, just few differences which needs some attention though). But the bad news for mpc8xx and mpc8260 is that there are a lot of users of these defines. So this cleanup I'll leave for the better times. - - - - From: Anton Vorontsov [EMAIL PROTECTED] Subject: 83xx/85xx: further localbus cleanups Merge mpc85xx.h's LBC defines to fsl_lbc.h. Also, adopt ACS names from mpc85xx.h, so ACS_0b10 renamed to ACS_DIV4, ACS_0b11 to ACS_DIV2. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- include/asm-ppc/fsl_lbc.h | 17 +++-- include/configs/MPC8315ERDB.h |2 +- include/configs/MPC8349EMDS.h |2 +- include/configs/MPC8349ITX.h |4 ++-- include/configs/MPC8360EMDS.h |2 +- include/configs/MPC8360ERDK.h |2 +- include/configs/MPC837XEMDS.h |2 +- include/configs/TQM834x.h |2 +- include/mpc85xx.h | 35 --- 9 files changed, 23 insertions(+), 45 deletions(-) diff --git a/include/asm-ppc/fsl_lbc.h b/include/asm-ppc/fsl_lbc.h index a129dca..4529f02 100644 --- a/include/asm-ppc/fsl_lbc.h +++ b/include/asm-ppc/fsl_lbc.h @@ -44,7 +44,11 @@ #define BR_MSEL_SHIFT 5 #define BR_MS_GPCM 0x /* GPCM */ #define BR_MS_FCM 0x0020 /* FCM */ +#ifdef CONFIG_MPC83xx #define BR_MS_SDRAM0x0060 /* SDRAM */ +#elif defined(CONFIG_MPC85xx) +#define BR_MS_SDRAM0x /* SDRAM */ +#endif #define BR_MS_UPMA 0x0080 /* UPMA */ #define BR_MS_UPMB 0x00A0 /* UPMB */ #define BR_MS_UPMC 0x00C0 /* UPMC */ @@ -80,8 +84,8 @@ #define OR_GPCM_CSNT_SHIFT 11 #define OR_GPCM_ACS0x0600 #define OR_GPCM_ACS_SHIFT 9 -#define OR_GPCM_ACS_0b10 0x0400 -#define OR_GPCM_ACS_0b11 0x0600 +#define OR_GPCM_ACS_DIV2 0x0600 +#define OR_GPCM_ACS_DIV4 0x0400 #define OR_GPCM_XACS 0x0100 #define OR_GPCM_XACS_SHIFT 8 #define OR_GPCM_SCY0x00F0 @@ -110,6 +114,10 @@ #define OR_GPCM_EAD0x0001 #define OR_GPCM_EAD_SHIFT 0 +/* helpers to convert values into an OR address mask (GPCM mode) */ +#define P2SZ_TO_AM(s) ((~((s) - 1)) 0x8000) /* must be pow of 2 */ +#define MEG_TO_AM(m) P2SZ_TO_AM((m) 20) + #define OR_FCM_AM 0x8000 #define OR_FCM_AM_SHIFT15 #define OR_FCM_BCTLD 0x1000 @@ -153,6 +161,11 @@ #define OR_UPM_EAD 0x0001 #define OR_UPM_EAD_SHIFT 0 +#define MxMR_OP_NORM 0x /* Normal Operation */ +#define MxMR_DSx_2_CYCL0x0040 /* 2 cycle Disable Period */ +#define MxMR_OP_WARR 0x1000 /* Write to Array */ +#define MxMR_BSEL 0x8000 /* Bus Select */ + #define OR_SDRAM_AM0x8000 #define OR_SDRAM_AM_SHIFT 15 #define OR_SDRAM_XAM 0x6000 diff --git a/include/configs/MPC8315ERDB.h b/include/configs/MPC8315ERDB.h index e0a887c..413b4f5 100644 --- a/include/configs/MPC8315ERDB.h +++ b/include/configs/MPC8315ERDB.h @@ -203,7 +203,7 @@ #define CFG_OR0_PRELIM ( (~(CFG_FLASH_SIZE - 1) 20) \ | OR_UPM_XAM \ | OR_GPCM_CSNT \ - | OR_GPCM_ACS_0b11 \ + | OR_GPCM_ACS_DIV2 \ | OR_GPCM_XACS \ | OR_GPCM_SCY_15 \ | OR_GPCM_TRLX \ diff --git a/include/configs/MPC8349EMDS.h b/include/configs/MPC8349EMDS.h index 119e7ac..10a7b53 100644 --- a/include/configs/MPC8349EMDS.h +++ b/include/configs/MPC8349EMDS.h @@ -157,7 +157,7 @@ (2 BR_PS_SHIFT) |/* 16 bit port size */ \
[U-Boot-Users] [PATCH] 85xx: Add setting of cache props in the device tree.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
cpu/mpc85xx/fdt.c | 128 +
1 files changed, 128 insertions(+), 0 deletions(-)
diff --git a/cpu/mpc85xx/fdt.c b/cpu/mpc85xx/fdt.c
index bb87740..92952e6 100644
--- a/cpu/mpc85xx/fdt.c
+++ b/cpu/mpc85xx/fdt.c
@@ -26,6 +26,7 @@
#include common.h
#include libfdt.h
#include fdt_support.h
+#include asm/processor.h
extern void ft_qe_setup(void *blob);
#ifdef CONFIG_MP
@@ -77,6 +78,131 @@ void ft_fixup_cpu(void *blob, u64 memory_limit)
}
#endif
+#ifdef CONFIG_L2_CACHE
+/* return size in kilobytes */
+static inline u32 l2cache_size(void)
+{
+ volatile ccsr_l2cache_t *l2cache = (void *)CFG_MPC85xx_L2_ADDR;
+ volatile u32 l2siz_field = (l2cache-l2ctl 28) 0x3;
+ u32 ver = SVR_SOC_VER(get_svr());
+
+ switch (l2siz_field) {
+ case 0x0:
+ break;
+ case 0x1:
+ if (ver == SVR_8540 || ver == SVR_8560 ||
+ ver == SVR_8541 || ver == SVR_8541_E ||
+ ver == SVR_8555 || ver == SVR_8555_E)
+ return 128;
+ else
+ return 256;
+ break;
+ case 0x2:
+ if (ver == SVR_8540 || ver == SVR_8560 ||
+ ver == SVR_8541 || ver == SVR_8541_E ||
+ ver == SVR_8555 || ver == SVR_8555_E)
+ return 256;
+ else
+ return 512;
+ break;
+ case 0x3:
+ return 1024;
+ break;
+ }
+
+ return 0;
+}
+
+static inline void ft_fixup_l2cache(void *blob)
+{
+ int len, off;
+ u32 *ph;
+ struct cpu_type *cpu = identify_cpu(SVR_SOC_VER(get_svr()));
+ char compat_buf[38];
+
+ const u32 line_size = 32;
+ const u32 num_ways = 8;
+ const u32 size = l2cache_size() * 1024;
+ const u32 num_sets = size / (line_size * num_ways);
+
+ off = fdt_node_offset_by_prop_value(blob, -1, device_type, cpu, 4);
+ if (off 0) {
+ debug(no cpu node fount\n);
+ return;
+ }
+
+ ph = (u32 *)fdt_getprop(blob, off, next-level-cache, 0);
+
+ if (ph == NULL) {
+ debug(no next-level-cache property\n);
+ return ;
+ }
+
+ off = fdt_node_offset_by_phandle(blob, *ph);
+ if (off 0) {
+ printf(%s: %s\n, __func__, fdt_strerror(off));
+ return ;
+ }
+
+ if (cpu) {
+ len = sprintf(compat_buf, fsl,mpc%s-l2-cache-controller,
+ cpu-name);
+ sprintf(compat_buf[len + 1], cache);
+ }
+ fdt_setprop(blob, off, cache-unified, NULL, 0);
+ fdt_setprop_cell(blob, off, cache-block-size, line_size);
+ fdt_setprop_cell(blob, off, cache-line-size, line_size);
+ fdt_setprop_cell(blob, off, cache-size, size);
+ fdt_setprop_cell(blob, off, cache-sets, num_sets);
+ fdt_setprop_cell(blob, off, cache-level, 2);
+ fdt_setprop(blob, off, compatible, compat_buf, sizeof(compat_buf));
+}
+#else
+#define ft_fixup_l2cache(x)
+#endif
+
+static inline void ft_fixup_cache(void *blob)
+{
+ int off;
+
+ off = fdt_node_offset_by_prop_value(blob, -1, device_type, cpu, 4);
+
+ while (off != -FDT_ERR_NOTFOUND) {
+ u32 l1cfg0 = mfspr(SPRN_L1CFG0);
+ u32 l1cfg1 = mfspr(SPRN_L1CFG1);
+ u32 isize, iline_size, inum_sets, inum_ways;
+ u32 dsize, dline_size, dnum_sets, dnum_ways;
+
+ /* d-side config */
+ dsize = (l1cfg0 0x7ff) * 1024;
+ dnum_ways = ((l1cfg0 11) 0xff) + 1;
+ dline_size = (((l1cfg0 23) 0x3) + 1) * 32;
+ dnum_sets = dsize / (dline_size * dnum_ways);
+
+ fdt_setprop_cell(blob, off, d-cache-block-size, dline_size);
+ fdt_setprop_cell(blob, off, d-cache-line-size, dline_size);
+ fdt_setprop_cell(blob, off, d-cache-size, dsize);
+ fdt_setprop_cell(blob, off, d-cache-sets, dnum_sets);
+
+ /* i-side config */
+ isize = (l1cfg1 0x7ff) * 1024;
+ inum_ways = ((l1cfg1 11) 0xff) + 1;
+ iline_size = (((l1cfg1 23) 0x3) + 1) * 32;
+ inum_sets = isize / (iline_size * inum_ways);
+
+ fdt_setprop_cell(blob, off, i-cache-block-size, iline_size);
+ fdt_setprop_cell(blob, off, i-cache-line-size, iline_size);
+ fdt_setprop_cell(blob, off, i-cache-size, isize);
+ fdt_setprop_cell(blob, off, i-cache-sets, inum_sets);
+
+ off = fdt_node_offset_by_prop_value(blob, off,
+ device_type, cpu, 4);
+ }
+
+ ft_fixup_l2cache(blob);
+}
+
+
void ft_cpu_setup(void *blob, bd_t *bd)
{
#if defined(CONFIG_HAS_ETH0) ||
[U-Boot-Users] help with warnings and gcc-4.3.0
I'm building with a native ppc compiler (fedora 9 install) and I get: dlmalloc.c:2444: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2483: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2483: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'realloc': dlmalloc.c:2594: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2599: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2604: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2605: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2637: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2646: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2647: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'calloc': dlmalloc.c:2896: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2897: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'malloc_trim': dlmalloc.c:2987: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2997: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3008: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3012: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3021: warning: dereferencing type-punned pointer will break strict-aliasing rules The warnings seem to come from: #define bin_at(i) ((mbinptr)((char*)(av_[2*(i) + 2]) - 2*SIZE_SZ)) #define next_bin(b)((mbinptr)((char*)(b) + 2 * sizeof(mbinptr))) #define prev_bin(b)((mbinptr)((char*)(b) - 2 * sizeof(mbinptr))) .. #define top(bin_at(0)-fd) /* The topmost chunk */ #define last_remainder (bin_at(1)) /* remainder from last split */ but I can't seem to do anything to bin_at() to make them stop. Was wondering if anyone had any suggestions. - k - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] help with warnings and gcc-4.3.0
On Thu, May 29, 2008 at 11:31:28AM -0500, Kumar Gala wrote: #define bin_at(i) ((mbinptr)((char*)(av_[2*(i) + 2]) - 2*SIZE_SZ)) #define next_bin(b)((mbinptr)((char*)(b) + 2 * sizeof(mbinptr))) #define prev_bin(b)((mbinptr)((char*)(b) - 2 * sizeof(mbinptr))) .. #define top(bin_at(0)-fd) /* The topmost chunk */ #define last_remainder (bin_at(1)) /* remainder from last split */ but I can't seem to do anything to bin_at() to make them stop. Was wondering if anyone had any suggestions. We could compile that file with -fno-strict-aliasing, which is probably warranted anyway for the kind of pointer manipulation that malloc needs to do. -Scott - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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] ColdFire: Fix UART baudrate at 115200
I see your point. I use your formula if you have not other comments. Regards, TsiChung -Original Message- From: Jerry Van Baren [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2008 10:57 PM To: Liew Tsi Chung Cc: Jerry Van Baren; U-Boot-Users; Wolfgang Denx; Rigby John Subject: Re: [U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate at 115200 Liew Tsi Chung wrote: Where are you getting the +31 from? Is this in the User's Manual? No in user's manual. The +31 is rounding up purpose. The formula (n + 31) / 32 is *NOT ROUNDING* the answer, it is doing a ceiling function. You need to add 1/2 the divisor to *ROUND*, i.e. (n + 16) / 32. Computations are for mathematicians. Real engineers measure the actual frequency. ;-) Agree. If you change the - 31 to - 42, your computations will result in a different divisor. Why are you subtracting what appears to be an arbitrary number (31)? Can't use 42 when the user's manual spec the divisor is 32. The - 31 comes from counter = ((bus_freq / baudrate) + 31) / 32. Using the same calculation as mentioned here to find out bus_freq. bus_freq = ((counter * 32) - 31) * baudrate. The 42 is an obscure reference to the Hitchhiker's Guide to the Galaxy - the answer to the question of life, the universe and everything. In other words, it is a totally arbitrary number. Your use of +31 is not a *ROUNDING*, it is *CEILING* and thus I claim it is arbitrary, especially with the +1 to the divisor if your baud rate is suppose to be 115200 baud. You don't understand your hardware (if it makes you feel better, neither do I, but it is important that *you* understand it). Are you sure your input frequency is 140MHz and not 144MHZ??? Have you read the itty-bitty numbers on the crystal? Have you put a scope on it and actually measured it? Never trust those hardware people. ;-) Actually, the bus freq is 70Mhz, 140Mhz is cpu freq (scope measurement). The input freq (crystal/oscillator) not always 1 to 1 ratio. Take M5253EVBE for example, the input clk is 11Mhz. Then, it multiply up and divide down for CPU and bus frequency. This *REALLY* makes your formula wrong. According to the MCF5253 Reference Manual Eqn. 15-1, the baud rate is fsys / (32 * divisor) and fsys is 70MHz, *NOT* 140MHz. baud = SysClk / (32 * divisor) divisor = (70e6 / 32) / baud divisor = 2187500 / 115200 divisor = 18.99 = 19 To *round*, add 1/2 the desired baud rate divisor = ((70e6 / 32) * (baud / 2)) / baud divisor = (2187500 + 57600) / 115200 divisor = 19.5 = integer truncation = 19 This means gd-bus_clk is *70MHz* (1/2 the CPU frequency), *NOT* 140MHz as you assume (note that this matches the Reference Manual). I return to my contention: Note, however, that (gd-baudrate / 2) is going to be relatively small compared to gd-bus_clk and (gd-baudrate * 16), so I suspect that the above formula could be changed to the following formula with no significant impact in accuracy: counter = (u32) ( ((gd-bus_clk + (gd-baudrate * 16)) / (gd-baudrate * 32); Simplifying the *32 factor to match my formula above: counter = (u32) ( ((gd-bus_clk / 32) + (gd-baudrate / 2)) / gd-baudrate); counter = ((70e6 / 32) + (115200 / 2)) / 115200 counter = 19 (after inter truncation) Note that, without adding (baudrate / 2) - rounding, the above formula results in a divisor of 18 rather than the proper 19. THIS IS YOUR PROBLEM and also what your fix should be. If you rounded properly, the baud rate calculation would work without all the magic. Here is what your change actually does: /* Setting up BaudRate */ counter = (u32) (gd-bus_clk / (gd-baudrate)); This divide is doing an integer truncation and you are losing significant digits. 70e6 / 115200 = 607.64 = integer truncation = 607 counter = (counter + 31) 5; This is ceiling, but you've already lost the digits due to the previous divide with integer truncation (no rounding). (607 + 31) / 32 = 19.9 = integer truncation = 19 You get lucky and get the right answer even though you don't deserve it. ;-) if ((gd-bus_clk 1) (gd-baudrate = 115200)) counter++; This is totally bogus. gd-bus_clk == 70e6 so this is *always false.* Looking at the MFC5407 (arbitrarily, not knowing what processor you have), the dividers are as expected and *do not* match your - 31 calculations. They have a simple example and simple math that matches (no - 31). Hmmm, the MFC5407 has a max CLKIN (and thus bus clock) of 54MHz. You must have a different flavor. MFC548x maxes at 50MHz. What processor are you using? 52x2, 532x, 547x_8x, 5445x. The 5253EVB is having the issue where the calculation does not apply if baudrate is 115200. Ahh, MFC5249 has a 140MHz bus. Still is a straight forward divide-by n*32, no - 31. I thought the same too, but the 140Mhz
Re: [U-Boot-Users] [PATCH]env_nand.c Added bad block management for environment variables
Scott,
Here is a new version of my patch to env_nand.c. Thanks for the good comments.
Fixed a problem with the new code that allowed it to read a
environment area even
if it contained a bad block after the good environment data.
diff --git a/common/env_nand.c b/common/env_nand.c
index 49742f5..3ee42e0 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -1,4 +1,7 @@
/*
+ * (C) Copywrite 2008
+ * Stuart Wood, Lab X Technologies [EMAIL PROTECTED]
+ *
* (C) Copyright 2004
* Jian Zhang, Texas Instruments, [EMAIL PROTECTED]
@@ -53,6 +56,10 @@
#error CONFIG_INFERNO not supported yet
#endif
+#ifndef CFG_ENV_RANGE
+#define CFG_ENV_RANGE CFG_ENV_SIZE
+#endif
+
int nand_legacy_rw (struct nand_chip* nand, int cmd,
size_t start, size_t len,
size_t * retlen, u_char * buf);
@@ -152,30 +159,57 @@ int env_init(void)
* nand_dev_desc + 0. This is also the behaviour using the new NAND code.
*/
#ifdef CFG_ENV_OFFSET_REDUND
+size_t erase_env(size_t offset)
+{
+ size_t end;
+
+ end = offset + CFG_ENV_RANGE;
+
+ while (offset end nand_erase(nand_info[0],offset, CFG_ENV_SIZE))
+ offset += CFG_ENV_SIZE;
+
+ if (offset = end)
+ return 0;
+
+ return offset;
+}
+
int saveenv(void)
{
size_t total;
+ size_t offset;
int ret = 0;
env_ptr-flags++;
total = CFG_ENV_SIZE;
+ if (CFG_ENV_RANGE CFG_ENV_SIZE)
+ return 1;
if(gd-env_valid == 1) {
- puts (Erasing redundant Nand...);
- if (nand_erase(nand_info[0],
- CFG_ENV_OFFSET_REDUND, CFG_ENV_SIZE))
+ puts (Erasing redundant Nand...\n);
+
+ offset = erase_env(CFG_ENV_OFFSET_REDUND);
+ if (offset == 0) {
+ puts (Redundant Nand area is completely bad!\n);
+ gd-env_valid = 2;
return 1;
+ }
+
puts (Writing to redundant Nand... );
- ret = nand_write(nand_info[0], CFG_ENV_OFFSET_REDUND, total,
+ ret = nand_write(nand_info[0], offset, total,
(u_char*) env_ptr);
} else {
- puts (Erasing Nand...);
- if (nand_erase(nand_info[0],
- CFG_ENV_OFFSET, CFG_ENV_SIZE))
+ puts (Erasing Nand...\n);
+
+ offset = erase_env(CFG_ENV_OFFSET);
+ if (offset == 0) {
+ puts (Nand area is completely bad!\n);
+ gd-env_valid = 1;
return 1;
+ }
puts (Writing to Nand... );
- ret = nand_write(nand_info[0], CFG_ENV_OFFSET, total,
+ ret = nand_write(nand_info[0], offset, total,
(u_char*) env_ptr);
}
if (ret || total != CFG_ENV_SIZE)
@@ -189,15 +223,23 @@ int saveenv(void)
int saveenv(void)
{
size_t total;
+ size_t offset;
int ret = 0;
- puts (Erasing Nand...);
- if (nand_erase(nand_info[0], CFG_ENV_OFFSET, CFG_ENV_SIZE))
+ if (CFG_ENV_RANGE CFG_ENV_SIZE)
return 1;
+ puts (Erasing Nand...\n);
+
+ offset = erase_env(CFG_ENV_OFFSET);
+
+ if (offset == 0) {
+ puts (Nand area is completely bad!\n);
+ return 1;
+ }
puts (Writing to Nand... );
total = CFG_ENV_SIZE;
- ret = nand_write(nand_info[0], CFG_ENV_OFFSET, total,
(u_char*)env_ptr);
+ ret = nand_write(nand_info[0], offset, total, (u_char*)env_ptr);
if (ret || total != CFG_ENV_SIZE)
return 1;
@@ -208,10 +250,26 @@ int saveenv(void)
#endif /* CMD_SAVEENV */
#ifdef CFG_ENV_OFFSET_REDUND
+int check_env_size (size_t offset)
+{
+ size_t end;
+ int ret_val = 0;
+ end = offset + CFG_ENV_SIZE;
+
+ for (; offset end; offset += nand_info[0].erasesize) {
+ if (nand_block_isbad(nand_info[0],offset))
+ ret_val = 1;
+ }
+
+ return ret_val;
+}
+
void env_relocate_spec (void)
{
#if !defined(ENV_IS_EMBEDDED)
size_t total;
+ size_t offset;
+ size_t end;
int crc1_ok = 0, crc2_ok = 0;
env_t *tmp_env1, *tmp_env2;
@@ -220,10 +278,27 @@ void env_relocate_spec (void)
tmp_env1 = (env_t *) malloc(CFG_ENV_SIZE);
tmp_env2 = (env_t *) malloc(CFG_ENV_SIZE);
- nand_read(nand_info[0], CFG_ENV_OFFSET, total,
- (u_char*) tmp_env1);
- nand_read(nand_info[0], CFG_ENV_OFFSET_REDUND, total,
- (u_char*) tmp_env2);
+ offset = CFG_ENV_OFFSET;
+ end = offset + CFG_ENV_RANGE;
+
+ while (offset end check_env_size(offset)) {
+ offset += CFG_ENV_SIZE;
+ }
+ if (offset = end)
+ puts(No Valid Environment Area Found\n);
+
Re: [U-Boot-Users] [PATCH]env_nand.c Added bad block management for environment variables
Scott Wood wrote:
+size_t end;
+int ret_val = 0;
+end = offset + CFG_ENV_SIZE;
+
+for (; offset end; offset += nand_info[0].erasesize) {
+if (nand_block_isbad(nand_info[0],offset))
+ret_val = 1;
+}
+
+return ret_val;
size_t end = offset + CFG_ENV_SIZE;
while (offset end)
if (nand_block_isbad(nand_info[0], offset))
return 1;
return 0;
Err, with an offset increment in the loop, of course.
-Scott
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [GIT PULL] avr32 update
Hi Wolfgang,
Please pull the 'master' branch of
git://git.denx.de/u-boot-avr32.git master
to receive the below updates.
The SPI stuff and a few other patches I've posted are not included here
since they aren't really avr32-related. I'm hoping you'll still apply
them before the merge window closes.
David Brownell (2):
avr32: stk1002 and ngw100 convergence
avr32: Disable the AP7000 internal watchdog on startup
Haavard Skinnemoen (15):
avr32: Use correct condition around macb clock accessors
avr32: Get rid of the .flashprog section
avr32: Add support for the ATSTK1006 board
avr32: Clean up the HMATRIX code
avr32: Remove unused file cpu/at32ap/pm.c
avr32: Use new-style Makefile for the at32ap platform
avr32: Rename pm_init() as clk_init() and make SoC-specific
avr32: Put memset in its own section
avr32: Use the same entry point for reset and exception handling
avr32: Do stricter stack checking in the exception handler
avr32: Rework SDRAM initialization code
avr32: Fix two warnings in atmel_mci.c
avr32: Fix wrong error flags in atmel_mci driver
avr32: Compile atmel_mci.o conditionally
avr32: Fix theoretical race in udelay()
MAINTAINERS|1 +
MAKEALL|1 +
Makefile |3 +
board/atmel/atngw100/atngw100.c| 27 ++-
board/atmel/atngw100/u-boot.lds|9 +-
board/atmel/atstk1000/atstk1000.c | 54 +-
board/atmel/atstk1000/flash.c |6 +-
board/atmel/atstk1000/u-boot.lds |9 +-
cpu/at32ap/Makefile| 20 ++-
cpu/at32ap/at32ap700x/Makefile |2 +-
cpu/at32ap/at32ap700x/clk.c| 68 +++
cpu/at32ap/{ = at32ap700x}/sm.h |0
cpu/at32ap/atmel_mci.c | 12 +-
cpu/at32ap/cpu.c | 50 +-
cpu/at32ap/entry.S | 64 ---
cpu/at32ap/exception.c |3 +-
cpu/at32ap/hsdramc.c | 102 ---
cpu/at32ap/interrupts.c| 16 +-
cpu/at32ap/pm.c| 42 -
cpu/at32ap/start.S | 129 -
include/asm-avr32/arch-at32ap700x/clk.h|4 +-
include/asm-avr32/arch-at32ap700x/hmatrix.h| 61 ++
include/asm-avr32/arch-at32ap700x/hmatrix2.h | 232
include/asm-avr32/arch-at32ap700x/memory-map.h | 20 ++
include/asm-avr32/hmatrix-common.h | 131 +
include/asm-avr32/sdram.h | 27 +++-
include/asm-avr32/sections.h |7 -
include/configs/atngw100.h | 26 +--
include/configs/atstk1002.h| 19 +-
include/configs/atstk1003.h| 15 +-
include/configs/atstk1004.h| 16 +-
include/configs/atstk1006.h| 203 +
lib_avr32/memset.S |2 +-
33 files changed, 817 insertions(+), 564 deletions(-)
create mode 100644 cpu/at32ap/at32ap700x/clk.c
rename cpu/at32ap/{ = at32ap700x}/sm.h (100%)
delete mode 100644 cpu/at32ap/entry.S
delete mode 100644 cpu/at32ap/pm.c
create mode 100644 include/asm-avr32/arch-at32ap700x/hmatrix.h
delete mode 100644 include/asm-avr32/arch-at32ap700x/hmatrix2.h
create mode 100644 include/asm-avr32/hmatrix-common.h
create mode 100644 include/configs/atstk1006.h
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Allow per file CFLAGS and AFLAGS
Mimic the linux kernel build system's ability to have per source file CFLAGS or AFLAGS. In the makefile you can now do: CFLAGS_file.o += MY_FLAGS_OPTIONS Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- config.mk | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/config.mk b/config.mk index b08b7a7..1359f7d 100644 --- a/config.mk +++ b/config.mk @@ -237,20 +237,20 @@ exportTEXT_BASE PLATFORM_CPPFLAGS PLATFORM_RELFLAGS CPPFLAGS CFLAGS AFLAGS ifndef REMOTE_BUILD %.s: %.S - $(CPP) $(AFLAGS) -o $@ $ + $(CPP) $(AFLAGS) $(AFLAGS_$@) -o $@ $ %.o: %.S - $(CC) $(AFLAGS) -c -o $@ $ + $(CC) $(AFLAGS) $(AFLAGS_$@) -c -o $@ $ %.o: %.c - $(CC) $(CFLAGS) -c -o $@ $ + $(CC) $(CFLAGS) $(CFLAGS_$@) -c -o $@ $ else $(obj)%.s: %.S - $(CPP) $(AFLAGS) -o $@ $ + $(CPP) $(AFLAGS) $(AFLAGS_$@) -o $@ $ $(obj)%.o: %.S - $(CC) $(AFLAGS) -c -o $@ $ + $(CC) $(AFLAGS) $(AFLAGS_$@) -c -o $@ $ $(obj)%.o: %.c - $(CC) $(CFLAGS) -c -o $@ $ + $(CC) $(CFLAGS) $(CFLAGS_$@) -c -o $@ $ endif # -- 1.5.4.5 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Changes ADS5121 splash screen from hard-coded bmp to flash bmp
Signed-off-by: Martha Marx [EMAIL PROTECTED]
---
board/ads5121/Makefile |1 -
board/ads5121/ads5121_diu.c | 66 +++
board/freescale/common/fsl_diu_fb.c |6 +++-
include/configs/ads5121.h |2 +
4 files changed, 66 insertions(+), 9 deletions(-)
diff --git a/board/ads5121/Makefile b/board/ads5121/Makefile
index f4dacce..0e4de61 100644
--- a/board/ads5121/Makefile
+++ b/board/ads5121/Makefile
@@ -30,7 +30,6 @@ LIB = $(obj)lib$(BOARD).a
COBJS-y:= $(BOARD).o
COBJS-${CONFIG_FSL_DIU_FB} += ads5121_diu.o
COBJS-${CONFIG_FSL_DIU_FB} += ../freescale/common/fsl_diu_fb.o
-COBJS-${CONFIG_FSL_DIU_FB} += ../freescale/common/fsl_logo_bmp.o
COBJS-$(CONFIG_PCI) += pci.o
COBJS := $(COBJS-y)
diff --git a/board/ads5121/ads5121_diu.c b/board/ads5121/ads5121_diu.c
index 87cf0cb..a57d505 100644
--- a/board/ads5121/ads5121_diu.c
+++ b/board/ads5121/ads5121_diu.c
@@ -26,6 +26,7 @@
#include common.h
#include command.h
#include asm/io.h
+#include malloc.h
#ifdef CONFIG_FSL_DIU_FB
@@ -61,16 +62,67 @@ void diu_set_pixel_clock(unsigned int pixclock)
debug(DIU: Modified value of CLKDVDR = 0x%08x\n, *clkdvdr);
}
+char *valid_bmp(char *addr)
+{
+ unsigned long h_addr;
+
+ h_addr = simple_strtoul(addr, NULL, 16);
+ if (h_addr CFG_FLASH_BASE ||
+ h_addr = (CFG_FLASH_BASE + CFG_FLASH_SIZE - 1)) {
+ printf(bmp addr %x is not a valid flash address\n, h_addr);
+ return 0;
+ } else if ((*(char *)(h_addr) != 'B') || (*(char *)(h_addr+1) != 'M')) {
+ printf(bmp addr is not a bmp\n);
+ return 0;
+ } else
+ return (char *)h_addr;
+}
+
int ads5121_diu_init(void)
{
+ int gamma_fix;
unsigned int pixel_format;
-
- xres = 1024;
- yres = 768;
- pixel_format = 0x3316;
-
- return fsl_diu_init(xres, pixel_format, 0,
-(unsigned char *)FSL_Logo_BMP);
+ char *bmp_env, *bmp, *monitor_port;
+ unsigned char *dest;
+ long bmp_sz;
+
+ debug(ads5121_diu_init\n);
+ bmp_env = getenv(bmp_addr);
+ if (bmp_env == NULL) {
+ debug(Environment Variable bmp_addr is not set \n);
+ bmp = 0;
+ } else {
+ bmp = valid_bmp(bmp_env);
+ }
+ if (bmp) {
+ bmp_sz = (bmp[5] 24) | (bmp[4] 16) |
+ (bmp[3] 8) | bmp[2];
+ debug(bmp_sz = %u\n, bmp_sz);
+ if (bmp_sz CFG_SPLASH_SIZE) {
+ printf(BMP exceeds size limit of %d\n,
+ CFG_SPLASH_SIZE);
+ bmp = 0;
+ } else {
+ dest = malloc(bmp_sz);
+ (void)memcpy((void *)dest, bmp, bmp_sz);
+ }
+ }
+ monitor_port = getenv(monitor_port);
+ if (!strncmp(monitor_port, LCD, 3)) {
+ debug(LCD Monitor port\n);
+ xres = 1024;
+ yres = 768;
+ pixel_format = 0x3316;
+ gamma_fix = 1;
+ } else {
+ debug(DVI Monitor port\n);
+ xres = 1024;
+ yres = 768;
+ pixel_format = 0x3316;
+ gamma_fix = 0;
+ }
+ return fsl_diu_init(xres, pixel_format, gamma_fix,
+(unsigned char *)bmp);
}
int ads5121diu_init_show_bmp(cmd_tbl_t *cmdtp,
diff --git a/board/freescale/common/fsl_diu_fb.c
b/board/freescale/common/fsl_diu_fb.c
index 75f782e..a3bee17 100644
--- a/board/freescale/common/fsl_diu_fb.c
+++ b/board/freescale/common/fsl_diu_fb.c
@@ -301,11 +301,15 @@ int fsl_diu_init(int xres,
debug(Fix gamma table\n);
gamma_table_base = gamma.paddr;
for (i = 0; i 256*3; i++) {
+#ifdef CONFIG_ADS5121
+ gamma_table_base[i] = ((gamma_table_base[i] % 4) 6)
+ | (gamma_table_base[i] 2);
+#else
gamma_table_base[i] = (gamma_table_base[i] 2)
| ((gamma_table_base[i] 6) 0x03);
+#endif
}
}
-
debug(update-lcdc: HW - %p\n Disabling DIU\n, hw);
/* Program DIU registers */
diff --git a/include/configs/ads5121.h b/include/configs/ads5121.h
index 21374e9..ae98359 100644
--- a/include/configs/ads5121.h
+++ b/include/configs/ads5121.h
@@ -45,6 +45,7 @@
*/
#define CONFIG_E3001 /* E300 Family */
#define CONFIG_MPC512X 1 /* MPC512X family */
+#define CONFIG_ADS5121 1 /* ADS5121 board */
#define CONFIG_FSL_DIU_FB 1 /* FSL DIU */
/* video */
@@ -222,6 +223,7 @@
#define CFG_MONITOR_LEN(256 * 1024)/* Reserve 256
kB for Mon */
#ifdef CONFIG_FSL_DIU_FB
#define CFG_MALLOC_LEN (6 * 1024 * 1024) /* Reserved for
[U-Boot-Users] Command history no longer working
Hi, I have observed that after this commit, the command history is no longer working: --- commit 597f6c26a18b389903a64692bacbf9a1ca69355b Author: James Yang [EMAIL PROTECTED] Date: Mon May 5 10:22:53 2008 -0500 Fix readline_into_buffer() with CONFIG_CMDLINE_EDITING before relocating When CONFIG_CMDLINE_EDITING is enabled, readline_into_buffer() doesn't work before relocating to RAM because command history is written into a global array that is not writable before relocation. This patch defers to the no-editing and no-history code in readline_into_buffer() if it is called before relocation. --- Based on the comments, I dont understand why it ceases to work because, in my case, U-Boot runs entirely from RAM (it is copied from flash to RAM by a first stage bootloader). I have CONFIG_CMDLINE_EDITING defined. Hugo V. Hugo Villeneuve Hardware developer | Concepteur matériel Lyrtech Phone/Tél. : (1) (418) 877-4644 #2395 Toll-free/Sans frais — Canada USA : (1) (888) 922-4644 #2395 Fax/Téléc. : (1) (418) 877-7710 www.lyrtech.com Infinite possibilities…TM - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Consolidates ADS5121 IO Pin configuration
Signed-off-by: Martha Marx [EMAIL PROTECTED]
---
board/ads5121/Makefile|2 +-
board/ads5121/ads5121.c | 36 +---
board/ads5121/iopin.c | 96
board/ads5121/iopin.h | 220 +
cpu/mpc512x/fec.c | 15 ---
include/configs/ads5121.h |1 +
6 files changed, 321 insertions(+), 49 deletions(-)
create mode 100644 board/ads5121/iopin.c
create mode 100644 board/ads5121/iopin.h
diff --git a/board/ads5121/Makefile b/board/ads5121/Makefile
index 0e4de61..88da762 100644
--- a/board/ads5121/Makefile
+++ b/board/ads5121/Makefile
@@ -27,7 +27,7 @@ $(shell mkdir -p $(OBJTREE)/board/freescale/common)
LIB= $(obj)lib$(BOARD).a
-COBJS-y:= $(BOARD).o
+COBJS-y:= $(BOARD).o iopin.o
COBJS-${CONFIG_FSL_DIU_FB} += ads5121_diu.o
COBJS-${CONFIG_FSL_DIU_FB} += ../freescale/common/fsl_diu_fb.o
COBJS-$(CONFIG_PCI) += pci.o
diff --git a/board/ads5121/ads5121.c b/board/ads5121/ads5121.c
index 95559ca..f6649a6 100644
--- a/board/ads5121/ads5121.c
+++ b/board/ads5121/ads5121.c
@@ -47,28 +47,13 @@
#define CSAW_START(start) ((start) 0x)
#define CSAW_STOP(start, size) (((start) + (size) - 1) 16)
-#define MPC5121_IOCTL_PSC6_0 (0x284/4)
-#define MPC5121_IO_DIU_START (0x288/4)
-#define MPC5121_IO_DIU_END (0x2fc/4)
-
-/* Functional pin muxing */
-#define MPC5121_IO_FUNC1 (0 7)
-#define MPC5121_IO_FUNC2 (1 7)
-#define MPC5121_IO_FUNC3 (2 7)
-#define MPC5121_IO_FUNC4 (3 7)
-#define MPC5121_IO_ST (1 2)
-#define MPC5121_IO_DS_1(0)
-#define MPC5121_IO_DS_2(1)
-#define MPC5121_IO_DS_3(2)
-#define MPC5121_IO_DS_4(3)
-
long int fixed_sdram(void);
+extern void iopin_initialize(void);
int board_early_init_f (void)
{
volatile immap_t *im = (immap_t *) CFG_IMMR;
u32 lpcaw, tmp32;
- volatile ioctrl512x_t *ioctl = (im-io_ctrl);
int i;
/*
@@ -114,16 +99,6 @@ int board_early_init_f (void)
im-clk.sccr[0] = SCCR1_CLOCKS_EN;
im-clk.sccr[1] = SCCR2_CLOCKS_EN;
- /* Configure DIU clock pin */
- tmp32 = ioctl-regs[MPC5121_IOCTL_PSC6_0];
- tmp32 = ~0x1ff;
- tmp32 |= MPC5121_IO_FUNC3 | MPC5121_IO_DS_4;
- ioctl-regs[MPC5121_IOCTL_PSC6_0] = tmp32;
-
- /* Initialize IO pins (pin mux) for DIU function */
- for (i = MPC5121_IO_DIU_START; i MPC5121_IO_DIU_END; i++)
- ioctl-regs[i] |= (MPC5121_IO_FUNC3 | MPC5121_IO_DS_4);
-
return 0;
}
@@ -265,17 +240,12 @@ int checkboard (void)
{
ushort brd_rev = *(vu_short *) (CFG_CPLD_BASE + 0x00);
uchar cpld_rev = *(vu_char *) (CFG_CPLD_BASE + 0x02);
- volatile immap_t *im = (immap_t *) CFG_IMMR;
- volatile unsigned long *reg;
- int i;
printf (Board: ADS5121 rev. 0x%04x (CPLD rev. 0x%02x)\n,
brd_rev, cpld_rev);
+ /* initialize function mux slew rate IO inter alia on IO Pins */
+ iopin_initialize();
- /* change the slew rate on all pata pins to max */
- reg = (unsigned long *) (im-io_ctrl.regs[PATA_CE1_IDX]);
- for (i = 0; i 9; i++)
- reg[i] |= 0x0003;
return 0;
}
diff --git a/board/ads5121/iopin.c b/board/ads5121/iopin.c
new file mode 100644
index 000..6a35c81
--- /dev/null
+++ b/board/ads5121/iopin.c
@@ -0,0 +1,96 @@
+/*
+ * (C) Copyright 2008
+ * Martha J Marx, Silicon Turnkey Express, [EMAIL PROTECTED]
+ * mpc512x I/O pin/pad initialization for the ADS5121 board
+ * 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 linux/types.h
+#include iopin.h
+
+/*
+ * IO PAD TYPES
+ * for all types fmux is used to select the funtion
+ * ds sets the slew rate
+ * STD pins nothing extra (can set ds fmux only)
+ * STD_PUpue=1 to enable pull pud sets whether up or down resistors
+ * STD_STst sets the Schmitt trigger
+ * STD_PU_ST pue pud sets pull-up/down resistors as in STD_PU
+ * st sets the Schmitt trigger
+ * PCI hold sets output delay
+ * PCI_SThold sets output delay and st
Re: [U-Boot-Users] [Junk released by Allow List] Command history no longer working
[EMAIL PROTECTED] wrote: Hi, I have observed that after this commit, the command history is no longer working: --- commit 597f6c26a18b389903a64692bacbf9a1ca69355b Author: James Yang [EMAIL PROTECTED] Date: Mon May 5 10:22:53 2008 -0500 Fix readline_into_buffer() with CONFIG_CMDLINE_EDITING before relocating When CONFIG_CMDLINE_EDITING is enabled, readline_into_buffer() doesn't work before relocating to RAM because command history is written into a global array that is not writable before relocation. This patch defers to the no-editing and no-history code in readline_into_buffer() if it is called before relocation. --- Based on the comments, I dont understand why it ceases to work because, in my case, U-Boot runs entirely from RAM (it is copied from flash to RAM by a first stage bootloader). I have CONFIG_CMDLINE_EDITING defined. Well after reading through the code in common/main.c, I figured that by setting GD_FLG_RELOC in my board init function: gd-flags |= GD_FLG_RELOC; command history would be working again, and it did. But is it the right thing to do? I noticed that not a lot of platforms/boards set GD_FLG_RELOC so command history will probably cease to work for these boards also? Hugo V. Hugo Villeneuve Hardware developer | Concepteur matériel Lyrtech Phone/Tél. : (1) (418) 877-4644 #2395 Toll-free/Sans frais — Canada USA : (1) (888) 922-4644 #2395 Fax/Téléc. : (1) (418) 877-7710 www.lyrtech.com Infinite possibilities…TM - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Junk released by Allow List] Command history no longer working
On Thu, 2008-05-29 at 15:41 -0400, Hugo Villeneuve wrote: [EMAIL PROTECTED] wrote: Hi, I have observed that after this commit, the command history is no longer working: --- commit 597f6c26a18b389903a64692bacbf9a1ca69355b Author: James Yang [EMAIL PROTECTED] Date: Mon May 5 10:22:53 2008 -0500 Fix readline_into_buffer() with CONFIG_CMDLINE_EDITING before relocating When CONFIG_CMDLINE_EDITING is enabled, readline_into_buffer() doesn't work before relocating to RAM because command history is written into a global array that is not writable before relocation. This patch defers to the no-editing and no-history code in readline_into_buffer() if it is called before relocation. --- Based on the comments, I dont understand why it ceases to work because, in my case, U-Boot runs entirely from RAM (it is copied from flash to RAM by a first stage bootloader). I have CONFIG_CMDLINE_EDITING defined. Well after reading through the code in common/main.c, I figured that by setting GD_FLG_RELOC in my board init function: gd-flags |= GD_FLG_RELOC; command history would be working again, and it did. But is it the right thing to do? Yes. I noticed that not a lot of platforms/boards set GD_FLG_RELOC so command history will probably cease to work for these boards also? Most boards do the relocation and then it gets set by the common board_init_r() function. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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] Consolidates ADS5121 IO Pin configuration
On Thu, 2008-05-29 at 15:37 -0400, Martha Marx wrote: Signed-off-by: Martha Marx [EMAIL PROTECTED] --- board/ads5121/Makefile|2 +- board/ads5121/ads5121.c | 36 +--- board/ads5121/iopin.c | 96 board/ads5121/iopin.h | 220 + cpu/mpc512x/fec.c | 15 --- include/configs/ads5121.h |1 + 6 files changed, 321 insertions(+), 49 deletions(-) create mode 100644 board/ads5121/iopin.c create mode 100644 board/ads5121/iopin.h It's good that you remove iomux setting from the drivers like fec it should not be there. It's NOT good that you now put them in another driver iopin. The pins should be in board specific files. iopin should only contain helper functions not data that everybody that do a new board needs to go in and change/add. put the table in ads5121.c and I'm happy with it. well I'm not sure we need this fancy stuff only gets harder to read but I take that over having the config spread out over different files like it's now. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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 duplicate code introduced by commit 597f6c26a18b389903a64692bacbf9a1ca69355b
Remove duplicate code introduced by commit
597f6c26a18b389903a64692bacbf9a1ca69355b
Signed-off-by: Hugo Villeneuve [EMAIL PROTECTED]
---
common/main.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/common/main.c b/common/main.c
index a17b60b..046da6f 100644
--- a/common/main.c
+++ b/common/main.c
@@ -940,12 +940,6 @@ int readline_into_buffer (const char *const prompt, char *
buffer)
int rc;
static int initted = 0;
- if (!initted) {
- hist_init();
- initted = 1;
- }
-
-
/*
* History uses a global array which is not
* writable until after relocation to RAM.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate formula
From: TsiChung Liew [EMAIL PROTECTED] The formula counter = (u32) (gd-bus_clk / gd-baudrate) / 32 can generate the wrong divisor due to integer division truncation. Round the calculated divisor value by adding 1/2 the baudrate before dividing by the baudrate. Signed-off-by: TsiChung Liew [EMAIL PROTECTED] Acked-by: Gerald Van Baren [EMAIL PROTECTED] --- drivers/serial/mcfuart.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c index 88f3eb1..75e85b7 100644 --- a/drivers/serial/mcfuart.c +++ b/drivers/serial/mcfuart.c @@ -63,8 +63,8 @@ int serial_init(void) uart-umr = UART_UMR_SB_STOP_BITS_1; /* Setting up BaudRate */ - counter = (u32) (gd-bus_clk / (gd-baudrate)); - counter = 5; + counter = (u32) (gd-bus_clk / 32) + (gd-baudrate / 2)); + counter = counter / gd-baudrate; /* write to CTUR: divide counter upper byte */ uart-ubg1 = (u8) ((counter 0xff00) 8); -- 1.5.4.1 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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] ColdFire: Fix UART baudrate formula
On Thu, 2008-05-29 at 15:26 -0500, Tsi-Chung.Liew wrote: From: TsiChung Liew [EMAIL PROTECTED] The formula counter = (u32) (gd-bus_clk / gd-baudrate) / 32 can generate the wrong divisor due to integer division truncation. Round the calculated divisor value by adding 1/2 the baudrate before dividing by the baudrate. Signed-off-by: TsiChung Liew [EMAIL PROTECTED] Acked-by: Gerald Van Baren [EMAIL PROTECTED] --- drivers/serial/mcfuart.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c index 88f3eb1..75e85b7 100644 --- a/drivers/serial/mcfuart.c +++ b/drivers/serial/mcfuart.c @@ -63,8 +63,8 @@ int serial_init(void) uart-umr = UART_UMR_SB_STOP_BITS_1; /* Setting up BaudRate */ - counter = (u32) (gd-bus_clk / (gd-baudrate)); - counter = 5; + counter = (u32) (gd-bus_clk / 32) + (gd-baudrate / 2)); And you compiled this ?? + counter = counter / gd-baudrate; /* write to CTUR: divide counter upper byte */ uart-ubg1 = (u8) ((counter 0xff00) 8); - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] boot pc with uboot
On Wednesday 28 May 2008, Jerry Van Baren wrote: Soodeh Bakhshandeh wrote: Dear sir I have a problem. I want to boot my pc with uboot. Which work I shold do?what is my roadmap? First you should be sure if that's exactly what you want. If you just want to play with u-boot on x86, porting it to bochs (or another virtual pc) should be easier and have more benefits than your pc. http://bochs.sourceforge.net/ If you want free software to boot your PC, you should have a look at coreboot (linuxbios) as well. It can also boot other PC related (BIOS dependent) operating systems, like freedos, which you probably wont be able to boot with u-boot. There is a port for bochs, so you can already play with it. http://www.coreboot.org/ The big problem is that full hardware documentation is hard to get. Depending on your board and the chips used on it, you might be able to get the documentation, but historically it is a show stopper problem. This may be changing with hardware becoming more open for linux drivers, or maybe you will get lucky... Getting a board which is already supported by Linuxbios should be the best starting point to port u-boot on it. Good Luck Markus - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Latest U-Boot MD5 compile error??
All, Possible fix, since I am a newbie at messing with somebody elses code can the owner of the MD5 code verify this problem / fix?? I found that if I did the following with changing some include files, this will now compile on my older FC5 system. Oddly I tried the newer ELDK42, etc.. not sure why this is broke on my box, but it was not the ELDK install or the source code being corrupted. MD5 Compile Fix: 1) In file 'include/u-boot/md5.h' change the #include linux/types.h -- #include asm/types.h 2) In file 'tools/md5.c' remove the reference to #include linux/types.h This corrects the problems on my system and removes all compile / errors and warning about implicit declarations for the string.h functions as well as the double declarations for __kernel_dev_t -Russ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2008 2:56 PM To: [EMAIL PROTECTED] Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] Latest U-Boot MD5 compile error?? In message [EMAIL PROTECTED] you wrote: Just pulled the latest GIT down today 1.3.3+, merged with my current code. Note, last I pulled was back at 1.3.1. Anyway, all is well until the newish MD5 code attempts to compile then I get two different types of errors. See Log Below Is this an artificat of an uncomplete merge perhaps? Probably. Try building for some other boards... Dependencies on a certain level of kernel that needs to be sitting in the ppc_6xx/usr/src/ directory? Or perhaps is FC5 to old to now correctly compile the latest U-boot? To old of an ELDK? I am using ELDK 4.1 Just tried to build a few boards on a FC5 host. A few warnings about including /usr/include/asm/byteorder.h, but it builds fine. 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] There is enough for the need of everyone in this world, but not for the greed of everyone. - Mahatma Gandhi - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Update kernel image in NAND from linux user space
I wonder what is the best way to handle kernel updates from linux user space. The NAND area where the kernel is placed has been defined as a MTD partition. So perhaps using mtd util's nandwrite will be it. Are the algorithm in nandwrite the same in both linux and u-boot wrt bad block skipping? Thanks, Norman - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate formula
From: TsiChung Liew [EMAIL PROTECTED] The formula counter = (u32) (gd-bus_clk / gd-baudrate) / 32 can generate the wrong divisor due to integer division truncation. Round the calculated divisor value by adding 1/2 the baudrate before dividing by the baudrate. Signed-off-by: TsiChung Liew [EMAIL PROTECTED] Acked-by: Gerald Van Baren [EMAIL PROTECTED] --- drivers/serial/mcfuart.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c index 88f3eb1..5eb4f45 100644 --- a/drivers/serial/mcfuart.c +++ b/drivers/serial/mcfuart.c @@ -63,8 +63,8 @@ int serial_init(void) uart-umr = UART_UMR_SB_STOP_BITS_1; /* Setting up BaudRate */ - counter = (u32) (gd-bus_clk / (gd-baudrate)); - counter = 5; + counter = (u32) ((gd-bus_clk / 32) + (gd-baudrate / 2)); + counter = counter / gd-baudrate; /* write to CTUR: divide counter upper byte */ uart-ubg1 = (u8) ((counter 0xff00) 8); -- 1.5.4.1 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] u-boot and Linux kernel forward compatibility is unsure?
Hello Wolfgang, On Thu, May 29, 2008 at 12:41 AM, Wolfgang Denk [EMAIL PROTECTED] wrote: in message [EMAIL PROTECTED] you wrote: For how long can I expect current u-boot (say 1.3.4) to be forward compatible with newer Linux kernels? I think chances are pretty good. Please keep in mind that we're right But even today you can build a current Linux kernel using the cuImage wrapper and boot it on an old (say, version 1.2.0) U-Boot. Thanks for your clear answer, takes away my cloud of doubt. Also, is there any plan to add fail-safe features to u-boot? What are you thinking of? My main requirement is to have the bootloader make a decision to boot a fall back image in case the normal image does not boot (for whatever reason). The fall back image is a user friendly way to unbrick the device. It itself is never overwritten. (In my case a web server with firmware upgrade Java applet, for example). Currently, my flow is as follows (with implementation in redboot) boot loader: enable hardware watchdog if flag A is set clear flag A load normal image, boot else if the normal image was not loaded, boot fallback. else boot fallback the normal image sets flag A when it wants to reboot, then stops servicing the watchdog and resets if normal image either did not set flag A (it crashes) or it did not service the watchdog, the watchdog will reset the board. I wonder if this is a common use and if it makes sense to implement this for mainstream u-boot, or is this very specific? Regards, -- Leon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Bis zu 2500 Euro Nebenverdienst
Ein marktgewinnendes Handelsbetrieb sucht neue Mitarbeiter !! Sie haben 6 Stunden in der Woche frei , besitzen einige PCkenntnisse und sind immer erreichebar?? - Sie haben dann die Moeglichkeit bei uns einzusteigen und sehr gutes Geld zu verdienen!! Begeistert? - schreiben Sie uns an [EMAIL PROTECTED] und lassen Sie sich genauere Details zumailen. Mit freundlichen Gruessen ELF LTD - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
