Re: [U-Boot] [PATCH] Enable usb ehci support for p2020ds board
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Tuesday, September 15, 2009 2:55 AM > To: Zang Roy-R61911 > Cc: Felix Radensky; U-Boot-Denx; Zhang Junjie-B18070; Kumar Gala > Subject: Re: [U-Boot] [PATCH] Enable usb ehci support for > p2020ds board > > Dear "Zang Roy-R61911", > > In message > <7df0af56456b8f4081e3c44ccce311de5a3...@zch01exm23.fsl.freesca > le.net> you wrote: > > > ... > > You need to run > > => usb start > > to start usb, then run > > => usb dev 0 > > to specify the device, then run > > This should not be needed... > > > => ext2ls usb 0:1 > > to ls the sda1 content. make sure it is ext2. > > ... as this command explicitly sets the device. You are correct. Thanks. Roy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Enable usb ehci support for p2020ds board
Hu Mingkai-B21284 wrote: > > > >> -Original Message- >> From: u-boot-boun...@lists.denx.de >> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Felix Radensky >> Sent: Monday, September 14, 2009 3:50 PM >> To: Zang Roy-R61911 >> Cc: U-Boot-Denx; Zhang Junjie-B18070; Kumar Gala >> Subject: Re: [U-Boot] [PATCH] Enable usb ehci support for >> p2020ds board >> >> Hi, >> >> This is what I get on MPC8536DS: >> >> U-Boot 2009.08-rc3 (Aug 26 2009 - 18:18:31) >> >> CPU: 8536E, Version: 1.0, (0x803f0090) >> Core: E500, Version: 3.0, (0x80210030) >> Clock Configuration: >>CPU0:1249.988 MHz, >>CCB:499.995 MHz, >>DDR:249.998 MHz (499.995 MT/s data rate) >> (Synchronous), LBC:31.250 MHz >> L1:D-cache 32 kB enabled >>I-cache 32 kB enabled >> Board: MPC8536DS Sys ID: 0x15, Sys Ver: 0x10, FPGA Ver: 0x13, vBank: 0 >> I2C: ready >> DRAM: InitializingDDR: 512 MB (DDR2, 64-bit, CL=4, ECC off) >> Top of RAM usable for U-Boot at: 2000 Reserving 800k for >> U-Boot at: 1ff3 Reserving 1032k for malloc() at: 1fe2e000 >> Reserving 80 Bytes for Board Info at: 1fe2dfb0 Reserving 76 >> Bytes for Global Data at: 1fe2df64 Stack Pointer at: 1fe2df48 >> New Stack Pointer is: 1fe2df48 Now running in RAM - U-Boot >> at: 1ff3 >> FLASH: 128 MB >> L2:512 KB enabled >> NAND: 4096 MiB >> Invalid ID (ff ff ff ff) >> >> PCIE3 connected to Slot3 as Root Complex (base address ffe0b000) >>Scanning PCI bus 01 >> 01 00 8086 10b9 0200 00 >> PCIE3 on bus 00 - 01 >> >> PCIE1 connected to Slot1 as Root Complex (base address ffe0a000) >> PCIE1 on bus 02 - 02 >> >> PCIE2 connected to Slot 2 as Root Complex (base address ffe09000) >> PCIE2 on bus 03 - 03 >> >> PCI: 32 bit, 66 MHz, async, host, arbiter (base address ffe08000) >>Scanning PCI bus 04 >> PCI on bus 04 - 04 >> Video: No radeon video card found! >> U-Boot relocated to 1ff3 >> MMC: FSL_ESDHC: 0 >> Net: e1000: 00:1b:21:1e:2d:2a >> eTSEC1, eTSEC3, e1000#0 >> Warning: e1000#0 MAC addresses don't match: >> Address in SROM is 00:1b:21:1e:2d:2a >> Address in environment is 04:00:00:00:00:0c >> >> Hit any key to stop autoboot: 0 >> => usb reset >> (Re)start USB... >> USB: Register 10011 NbrPorts 1 >> USB EHCI 1.00 >> scanning bus for devices... 2 USB Device(s) found >>scanning bus for storage devices... Device NOT ready >>Request Sense returned 00 00 00 >> 0 Storage Device(s) found >> => usb info >> 1: Hub, USB Revision 2.0 >> - u-boot EHCI Host Controller >> - Class: Hub >> - PacketSize: 64 Configurations: 1 >> - Vendor: 0x Product 0x Version 1.0 >>Configuration: 1 >>- Interfaces: 1 Self Powered 0mA >> Interface: 0 >> - Alternate Setting 0, Endpoints: 1 >> - Class Hub >> - Endpoint 1 In Interrupt MaxPacket 2048 Interval 0ms >> >> 2: Mass Storage, USB Revision 2.0 >> - SanDisk Corporation Cruzer Mini 200435130107dcd07f5f >> - Class: (from Interface) Mass Storage >> - PacketSize: 64 Configurations: 1 >> - Vendor: 0x0781 Product 0x5150 Version 0.32 >>Configuration: 1 >>- Interfaces: 1 Bus Powered 200mA >> Interface: 0 >> - Alternate Setting 0, Endpoints: 2 >> - Class Mass Storage, Transp. SCSI, Bulk only >> - Endpoint 1 In Bulk MaxPacket 512 >> - Endpoint 1 Out Bulk MaxPacket 512 >> >> => fatls usb 0:1 >> Device NOT ready >>Request Sense returned 00 00 00 >> ** Can't read from device 0 ** >> >> ** Unable to use usb 0:1 for fatls ** >> >> > > Hi Felix, > > I tested this on my 8536DS board, it works well. > > I noticed that when scan the USB, the device is not ready, so does the > board supply > the power to USB stick? I run into this problem sometimes. > Yes, USB stick is powered on, the green led on the stick is on. > > And the CPU version you used is 1.0, so your board version should less > than B2. > I'm not sure whether this affects the results. > I've tested another USB stick with this board, and was recognized properly. Also, the problematic stick works fine with Linux, so I still suspect there's a problem in u-boot EHCI driver. Can you test your board with smaller/older devices, the one that has problems is 512MB Sandisk Cruizer Mini. Thanks. Felix. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ubifs: Add support for looking up directory and relative symlinks
ubifs: Add support for looking up directory and relative symlinks
This patch adds support for resolving symlinks to directories as well as
relative symlinks. Symlinks are now always resolved during file lookup,
so the load stage no longer needs to special-case them.
Signed-off-by: Simon Kagstrom
---
fs/ubifs/ubifs.c | 68 ++---
1 files changed, 43 insertions(+), 25 deletions(-)
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 8ede188..b03ed0b 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -379,9 +379,11 @@ static unsigned long ubifs_findfile(struct super_block
*sb, char *filename)
int ret;
char *next;
char fpath[128];
+ char symlinkpath[128];
char *name = fpath;
unsigned long root_inum = 1;
unsigned long inum;
+ int symlink_count = 0; /* Don't allow symlink recursion */
strcpy(fpath, filename);
@@ -397,6 +399,9 @@ static unsigned long ubifs_findfile(struct super_block *sb,
char *filename)
return inum;
for (;;) {
+ struct inode *inode;
+ struct ubifs_inode *ui;
+
/* Extract the actual part from the pathname. */
next = strchr(name, '/');
if (next) {
@@ -406,18 +411,48 @@ static unsigned long ubifs_findfile(struct super_block
*sb, char *filename)
}
ret = ubifs_finddir(sb, name, root_inum, &inum);
+ if (!ret)
+ return 0;
+ inode = ubifs_iget(sb, inum);
+
+ if (!inode)
+ return 0;
+ ui = ubifs_inode(inode);
+
+ if ((inode->i_mode & S_IFMT) == S_IFLNK) {
+ char link_name[64];
+ char buf[128];
+
+ /* We have some sort of symlink recursion, bail out */
+ if (symlink_count++ > 8) {
+ printf("Symlink recursion, aborting\n");
+ return 0;
+ }
+ memcpy(link_name, ui->data, ui->data_len);
+ link_name[ui->data_len] = '\0';
+
+ if (link_name[0] == '/') {
+ /* Absolute path, redo everything without
+* the leading slash */
+ next = name = link_name + 1;
+ root_inum = 1;
+ continue;
+ }
+ /* Relative to cur dir */
+ sprintf(buf, "%s%s",
+ link_name, next == NULL ? "" : next);
+ memcpy(symlinkpath, buf, sizeof(buf));
+ next = name = symlinkpath;
+ continue;
+ }
/*
* Check if directory with this name exists
*/
/* Found the node! */
- if (!next || *next == '\0') {
- if (ret)
- return inum;
-
- break;
- }
+ if (!next || *next == '\0')
+ return inum;
root_inum = inum;
name = next;
@@ -614,10 +649,10 @@ int ubifs_load(char *filename, u32 addr, u32 size)
int err = 0;
int i;
int count;
- char link_name[64];
- struct ubifs_inode *ui;
c->ubi = ubi_open_volume(c->vi.ubi_num, c->vi.vol_id, UBI_READONLY);
+ /* ubifs_findfile will resolve symlinks, so we know that we get
+* the real file here */
inum = ubifs_findfile(ubifs_sb, filename);
if (!inum) {
err = -1;
@@ -635,23 +670,6 @@ int ubifs_load(char *filename, u32 addr, u32 size)
}
/*
-* Check for symbolic link
-*/
- ui = ubifs_inode(inode);
- if (((inode->i_mode & S_IFMT) == S_IFLNK) && ui->data_len) {
- memcpy(link_name, ui->data, ui->data_len);
- link_name[ui->data_len] = '\0';
- printf("%s is linked to %s!\n", filename, link_name);
- ubifs_iput(inode);
-
- /*
-* Now we have the "real" filename, call ubifs_load()
-* again (recursive call) to load this file instead
-*/
- return ubifs_load(link_name, addr, size);
- }
-
- /*
* If no size was specified or if size bigger than filesize
* set size to filesize
*/
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Enable usb ehci support for p2020ds board
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Felix Radensky > Sent: Tuesday, September 15, 2009 3:48 PM > To: Hu Mingkai-B21284 > Cc: U-Boot-Denx; Zhang Junjie-B18070; Kumar Gala > Subject: Re: [U-Boot] [PATCH] Enable usb ehci support for > p2020ds board > > > And the CPU version you used is 1.0, so your board version > should less > > than B2. > > I'm not sure whether this affects the results. > > > > I've tested another USB stick with this board, and was > recognized properly. > Also, the problematic stick works fine with Linux, so I still > suspect there's a problem in u-boot EHCI driver. Can you > test your board with smaller/older devices, the one that has > problems is 512MB Sandisk Cruizer Mini. > I used the old one - SanDisk Cruzer Micro 256MB :-) But sometime, the reset command don't list the device, I had to run the reset command again. Best regards, Mingkai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kwbimage.c: Fix compile warning when building on 32/64 bit systems
Commit 51003b89 [kwbimage.c: Fix compile warning when building on
64 bit systems] changed the printf format for "sizeof(uint32_t)"
from "%d" to "%ld". This now generates the following warning on
32 bit build systems:
tools/kwbimage.c: In function âkwbimage_checksum32â:
tools/kwbimage.c:135: warning: format â%ldâ expects type âlong intâ,
but argument 4 has type âunsigned intâ
The problem is that sizeof(uint32_t) has different types on 32 bit and
64 bit build systems. This patch now changes the format to "%d" again and
casts sizeof() to uint32_t, fixing the problem on both build systems.
Signed-off-by: Stefan Roese
Cc: Wolfgang Denk
Cc: Prafulla Wadaskar
---
tools/kwbimage.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index ee067cb..2c542da 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -131,8 +131,8 @@ static uint32_t kwbimage_checksum32 (uint32_t *start,
uint32_t len, uint32_t csu
return 0;
if (len % sizeof(uint32_t)) {
- printf ("Error:%s[%d] - lenght is not in multiple of %ld\n",
- __FUNCTION__, len, sizeof(uint32_t));
+ printf ("Error:%s[%d] - lenght is not in multiple of %d\n",
+ __FUNCTION__, len, (uint32_t)sizeof(uint32_t));
return 0;
}
--
1.6.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] UBIFS LZO decompression failure
Hi List! I have a slight problem with UBIFS on the OpenRD base board (an ARM board very similar to sheevaplug). Loading files which have been compressed with LZO by ubifs fails: OpenRD>> ubi part root; ubifsmount rootfs Creating 1 MTD partitions on "nand0": 0x001e-0x2000 : "mtd=1" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:129024 bytes UBI: smallest flash I/O unit:2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset:2048 UBI: attached mtd1 to ubi0 UBI: MTD device name:"mtd=1" UBI: MTD device size:510 MiB UBI: number of good PEBs:4081 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold:4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 1 UBI: available PEBs: 54 UBI: total number of reserved PEBs: 4027 UBI: number of PEBs reserved for bad PEB handling: 40 UBI: max/mean erase counter: 6/4 UBIFS: mounted UBI device 0, volume 0, name "rootfs" UBIFS: mounted read-only UBIFS: file system size: 511967232 bytes (499968 KiB, 488 MiB, 3968 LEBs) UBIFS: journal size: 25675776 bytes (25074 KiB, 24 MiB, 199 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS: default compressor: LZO UBIFS: reserved for root: 5182151 bytes (5060 KiB) OpenRD>> ubifsload 0x800 /boot/primary/uImage Loading file '/boot/primary/uImage' to addr 0x0800 with size 7196920 (0x006dd0f8)... UBIFS error (pid 0): ubifs_decompress: cannot decompress 3204 bytes, compressor LZO, error -6 UBIFS error (pid 0): read_block: bad data node (block 0, inode 88) UBIFS error (pid 0): do_readpage: cannot read page 0 of inode 88, error -22 Error reading file '/boot/primary/uImage' I've created the filesystem in Linux on the target (v2.6.31). The compression error -6 is LZO_E_LOOKBEHIND_OVERRUN, and it fails because of this test in lzo1x_decompress.c: if (HAVE_LB(m_pos, out, op)) goto lookbehind_overrun; where HAVE_LB is defined as (m_pos < out || m_pos >= op) and the m_pos, out and op values are 0x07ffde77, 0x0800, 0x0883 (i.e., the first test fails). The lzo1x_decompress.c file is identical to that in Linux, so something is fishy here. Does it work for the rest of you? In our case it doesn't matter very much since the file (an uImage) is compressed anyway and we therefore save work anyway by marking it as using no compression, but it would be nice if this would work anyhow. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (no subject)
Hi Albin, now I tried your rewritten mmc driver. >- Use the updated driver that I rewrote, as seen here: > http://lists.denx.de/pipermail/u-boot/2009-August/059456.html > I have tested this code on my sam9g20/sam9260 boards with a wide range of sd > and mmc cards and it seems to work well. If you test this, I would really > appreciate if you sent an answer to the patch, saying that you tested this. > If you have some extra time, you can try both and try to see if there are > regressions in the new code :) But till now I don't get it working. Here my steps: Downloaded u-boot 2009.08 changed: #if defined(CONFIG_HAS_DATAFLASH) to: #if defined(CONFIG_HAS_DATAFLASH) || defined(CONFIG_ATMEL_SPI) applied Patch: http://lists.denx.de/pipermail/u-boot/2009-September/060053.html then applied Patch V3: from mail added to:include/config/at91sam9260ek.h #define CONFIG_CMD_MMC 1 #define CONFIG_MMC 1 #define CONFIG_GENERIC_MMC added: to: board/atmel/at91sam9260ek/at91sam9260ek.c at91_mci0_hw_init(0,4); // slot 0 and bus width 4 I got the compile error: at91_mci0_hw_init not found. I added: #define CONFIG_ATMEL_MCI to include/config/at91sam9260ek.h because this at91_mci0_hw_init is in a ifdef CONFIG_ATMEL_MCI block I compile okay. I flashed it. now I have no mmc init function. I have mmc list or mmcinfo,... but if I do for example mmc list I get nothing. bye Konrad ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Enable usb ehci support for p2020ds board
Dear Felix Radensky, In message <4aaf46b4.7030...@embedded-sol.com> you wrote: > Hu Mingkai-B21284 wrote: [Full quote deleted] Hey, eveybody on this thread: could you *please* stop full-quoting? Please read http://www.netmeister.org/news/learn2quote.html ... > I've tested another USB stick with this board, and was recognized properly. > Also, the problematic stick works fine with Linux, so I still suspect > there's a > problem in u-boot EHCI driver. Can you test your board with smaller/older > devices, the one that has problems is 512MB Sandisk Cruizer Mini. Is there any chance that this non-working stick is not a high-speed device? Eventually this EHCI driver has problems with full-speed (or low-speed) devices? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What's the sound a name makes when it's dropped? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Enable usb ehci support for p2020ds board
Wolfgang Denk wrote: > Dear Felix Radensky, > > In message <4aaf46b4.7030...@embedded-sol.com> you wrote: > >> Hu Mingkai-B21284 wrote: >> > > [Full quote deleted] > > > Hey, eveybody on this thread: could you *please* stop full-quoting? > Please read http://www.netmeister.org/news/learn2quote.html > > ... > Sorry about that. >> I've tested another USB stick with this board, and was recognized properly. >> Also, the problematic stick works fine with Linux, so I still suspect >> there's a >> problem in u-boot EHCI driver. Can you test your board with smaller/older >> devices, the one that has problems is 512MB Sandisk Cruizer Mini. >> > > Is there any chance that this non-working stick is not a high-speed > device? Eventually this EHCI driver has problems with full-speed (or > low-speed) devices? > No, this is high speed device. linux-2.6.31 running on this board reports this: hub 1-0:1.0: state 7 ports 1 chg evt 0002 fsl-ehci fsl-ehci.0: GetStatus port 1 status 90001803 POWER sig=j CSC CONNECT hub 1-0:1.0: port 1, status 0101, change 0001, 12 Mb/s hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101 usb 1-1: new high speed USB device using fsl-ehci and address 2 usb 1-1: default language 0x0409 usb 1-1: udev 2, busnum 1, minor = 1 usb 1-1: New USB device found, idVendor=0781, idProduct=5150 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: Cruzer Mini usb 1-1: Manufacturer: SanDisk Corporation usb 1-1: SerialNumber: 200435130107dcd07f5f usb 1-1: uevent usb 1-1: usb_probe_device usb 1-1: configuration #1 chosen from 1 choice usb 1-1: adding 1-1:1.0 (config #1, interface 0) usb 1-1:1.0: uevent usb-storage 1-1:1.0: usb_probe_interface usb-storage 1-1:1.0: usb_probe_interface - got id scsi0 : SCSI emulation for USB Mass Storage devices hub 1-0:1.0: state 7 ports 1 chg evt 0002 usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning scsi 0:0:0:0: Direct-Access SanDisk Cruzer Mini 0.3 PQ: 0 ANSI: 2 usb-storage: device scan complete sd 0:0:0:0: [sda] 1000944 512-byte logical blocks: (512 MB/488 MiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 sd 0:0:0:0: [sda] Assuming drive cache: write through sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sd 0:0:0:0: [sda] Assuming drive cache: write through sd 0:0:0:0: [sda] Attached SCSI removable disk Felix. > Best regards, > > Wolfgang Denk > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Enable usb ehci support for p2020ds board
Hu Mingkai-B21284 wrote: > > >> I've tested another USB stick with this board, and was >> recognized properly. >> Also, the problematic stick works fine with Linux, so I still >> suspect there's a problem in u-boot EHCI driver. Can you >> test your board with smaller/older devices, the one that has >> problems is 512MB Sandisk Cruizer Mini. >> >> > > I used the old one - SanDisk Cruzer Micro 256MB :-) > > But sometime, the reset command don't list the device, I had to run > the reset command again. > > This is what happens if I run usb reset twice: => usb reset (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 2 USB Device(s) found scanning bus for storage devices... Device NOT ready Request Sense returned 00 00 00 0 Storage Device(s) found => usb reset (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 2 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found Felix. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kwbimage.c: Fix compile warning when building on 32/64 bit systems
Dear Stefan Roese, In message <1253002223-16773-1-git-send-email...@denx.de> you wrote: > Commit 51003b89 [kwbimage.c: Fix compile warning when building on > 64 bit systems] changed the printf format for "sizeof(uint32_t)" > from "%d" to "%ld". This now generates the following warning on > 32 bit build systems: > > tools/kwbimage.c: In function `kwbimage_checksum32´: > tools/kwbimage.c:135: warning: format `%ld´ expects type `long int´, > but argument 4 has type `unsigned int´ > > The problem is that sizeof(uint32_t) has different types on 32 bit and > 64 bit build systems. This patch now changes the format to "%d" again and > casts sizeof() to uint32_t, fixing the problem on both build systems. Heh. Casts are evil. Now that both of us stabbed at this and failed it's time to remember to use "%zu" (hm... now why does this remind me of dzu? ;-) Will submit a patch ASAP. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I came home the other night and tried to open the door with my car keys...and the building started up. So I took it out for a drive. A cop pulled me over for speeding. He asked me where I live... "Right here".- Steven Wright ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Firmware Upgrade
Hi All, Is it Possible from Linux to set an environment variable of u-Boot.? This is for Firmware up gradation. Currently Linux has 4 mtd partitions in flash mtd0 : U-Boot mtd1: JFFS file system (Golden image) mtd2: JFFS file system (Silver image) mtd3: Configs U boot does an fsload of uImage(Linux image) from Golden JFFS and boots up Linux. Now from Linux I can download a new JFFS(Silver) and flash it to mtd2 partition of Flash. Is there any mechanism that Linux acknowledges the u-boot about the new jffs image that next time it has to do an fsload of uImage(Linux image) from Silver JFFS , not Golden JFFS. I thought of Doing this using some environment variables . But after a successful download of new jffs and writing to mtd2 partition , How will Linux update the environment variable of U-boot? Any better idea for firmware up gradation? Expecting your Suggestions and Help Thanks Rahanesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Firmware Upgrade
Dear Rahanesh, In message <4aaf71e3.7050...@tataelxsi.co.in> you wrote: > > Is it Possible from Linux to set an environment variable of u-Boot.? If your environment is stored in NOR or NAND flash, then you can use the tools from the tools/env/ directory (fw_setenv / fw_printenv). It should be trivial to adapt the code for other storage devices, too. > But after a successful download of new jffs and writing to mtd2 > partition , How will Linux update the environment variable of U-boot? Use fw_setenv. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fsl_i2c: increase I2C timeout values and make them configurable
Joakim Tjernlund wrote: >> Wolfgang Grandegger wrote: >> >>> I did not follow the thread yet, sorry. I implemented AN2819 for Linux >>> (see http://lxr.linux.no/#linux+v2.6.31/drivers/i2c/busses/i2c-mpc.c) >>> some time ago using Timur's table approach. But there is no difference >>> between the table and the algorithm to calculate the value. The table is >>> actually derived from the same algorithm. >> The problem with the table is that it does not allow for flexibility in >> choosing dfsr. When I implemented the table code, I did not think that this >> was a problem, but apparently it is. > > Yes, it is a problem for us as our board is out of spec. The rise time is way > off > spec. By trial and error with the DFSR/FDR I managed to get a stable > connection. > What is less funny though is that I need to program FDR/DFSR differently > in u-boot resp. kernel. to make it work. > I suspect it is due to kernel being IRQ driven and has longer pause > between chars, but it is a guess. > > In any case, the revised AN2819 dictates a different algorithm but I feel > it is a bit incomplete w.r.t Condition 2: > > • Condition 2: B × T ≥ tI2CRM + 3 × C × T. > Given a suitable value of DFSR, chosen to satisfy Condition 1, this > inequality must also be met to guarantee > that the SCL frequency matches the SCL frequency calculated by the divider > equation. It is important to > note that tI2CRM is the measured rise time of the SCL signal, which is > defined as the time for the signal to > rise from 10% to 70% of VCC. > > NOTE >Note that the rise time must not exceed 300 nanoseconds > and that the above >two conditions must both be satisfied to ensure that the > actual SCL >frequency values align with the calculated values. By > meeting these >conditions, the measured SCL frequency will match the > calculated >frequency to within 5 kHz. Ignoring either of these > conditions may result in >larger discrepancies between these frequency values. > > How important is Condition 2 and what to do with rise times > 300 ns? The MAX > rise time > for 100 KHz is 1000 ns so there is a gap here. > > My testing suggests that this is not important. Bigger DFSR, in my case 0x6 > or 0x10, is key > to get a stable I2C bus. > > Jocke > PS. > Wolfgang, I sent a test program to calculate the new DFSR/FDR values in > the thread, you > might find it useful if you are going to try out the new AN2819 Where do I find this test program. I just dig out my program to calculate the table entries for the Linux i2c-mpc.c. It actually reproduced Timur's (old) U-Boot values. Unfortunately, finding *good* dfsr/fdr settings is no trivial and takes time. Till recently, the i2c-mpc driver of Linux did use *fixed* save values as shown here: http://lxr.linux.no/#linux+v2.6.29/drivers/i2c/busses/i2c-mpc.c And also with newer kernels, the table is only used if one of the following I2C DTS properties is defined: - fsl,preserve-clocking; - clock-frequency = <40>; See http://lxr.linux.no/#linux+v2.6.31/Documentation/powerpc/dts-bindings/fsl/i2c.txt Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx27ads: add support for iMX27ADS board from Freescale
ping On 9/9/09, Alan Carvalho de Assis wrote: > This patch adds support to iMX27ADS development board. This board has > 128MB RAM, 32MB NOR Flash and 128MB NAND Flash. Currently only > booting from NOR is supported. > > Signed-off-by: Alan Carvalho de Assis > --- > MAINTAINERS |3 + > MAKEALL |1 + > Makefile|3 + > board/freescale/mx27ads/Makefile| 51 > board/freescale/mx27ads/config.mk |1 + > board/freescale/mx27ads/lowlevel_init.S | 128 +++ > board/freescale/mx27ads/mx27ads.c | 93 ++ > board/freescale/mx27ads/u-boot.lds | 56 + > include/configs/mx27ads.h | 202 > +++ > 9 files changed, 538 insertions(+), 0 deletions(-) > create mode 100644 board/freescale/mx27ads/Makefile > create mode 100644 board/freescale/mx27ads/config.mk > create mode 100644 board/freescale/mx27ads/lowlevel_init.S > create mode 100644 board/freescale/mx27ads/mx27ads.c > create mode 100644 board/freescale/mx27ads/u-boot.lds > create mode 100644 include/configs/mx27ads.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index e9db278..5b25188 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -550,6 +550,9 @@ Thomas Elste > > modnet50ARM720T (NET+50) > > +Alan Carvalho de Assis > + mx27ads i.MX27 > + > Fabio Estevam > > mx31pdk i.MX31 > diff --git a/MAKEALL b/MAKEALL > index f0ed8ea..8411eef 100755 > --- a/MAKEALL > +++ b/MAKEALL > @@ -520,6 +520,7 @@ LIST_ARM9=" \ > cp926ejs\ > cp946es \ > cp966 \ > + mx27ads \ > imx27lite \ > lpd7a400\ > mv88f6281gtw_ge \ > diff --git a/Makefile b/Makefile > index 0449a5b..6fa4b28 100644 > --- a/Makefile > +++ b/Makefile > @@ -2961,6 +2961,9 @@ davinci_dm365evm_config : unconfig > imx27lite_config:unconfig > @$(MKCONFIG) $(@:_config=) arm arm926ejs imx27lite logicpd mx27 > > +mx27ads_config : unconfig > + @$(MKCONFIG) $(@:_config=) arm arm926ejs mx27ads freescale mx27 > + > lpd7a400_config \ > lpd7a404_config: unconfig > @$(MKCONFIG) $(@:_config=) arm lh7a40x lpd7a40x > diff --git a/board/freescale/mx27ads/Makefile > b/board/freescale/mx27ads/Makefile > new file mode 100644 > index 000..d142a9e > --- /dev/null > +++ b/board/freescale/mx27ads/Makefile > @@ -0,0 +1,51 @@ > +# > +# (C) Copyright 2000-2004 > +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. > +# > +# See file CREDITS for list of people who contributed to this > +# project. > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation; either version 2 of > +# the License, or (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, > +# MA 02111-1307 USA > +# > + > +include $(TOPDIR)/config.mk > + > +LIB = $(obj)lib$(BOARD).a > + > +COBJS:= mx27ads.o > +SOBJS:= lowlevel_init.o > + > +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) > +OBJS := $(addprefix $(obj),$(COBJS)) > +SOBJS:= $(addprefix $(obj),$(SOBJS)) > + > +$(LIB): $(obj).depend $(OBJS) $(SOBJS) > + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) > + > +clean: > + rm -f $(SOBJS) $(OBJS) > + > +distclean: clean > + rm -f $(LIB) core *.bak $(obj).depend > + > +# > + > +include $(SRCTREE)/rules.mk > + > +sinclude $(obj).depend > + > +# > + > diff --git a/board/freescale/mx27ads/config.mk > b/board/freescale/mx27ads/config.mk > new file mode 100644 > index 000..a2e7768 > --- /dev/null > +++ b/board/freescale/mx27ads/config.mk > @@ -0,0 +1 @@ > +TEXT_BASE = 0xA7F0 > diff --git a/board/freescale/mx27ads/lowlevel_init.S > b/board/freescale/mx27ads/lowlevel_init.S > new file mode 100644 > index 000..a4e1191 > --- /dev/null > +++ b/board/freescale/mx27ads/lowlevel_init.S > @@ -0,0 +1,128 @@ > +/* > + * Copyright (C) 2008, Guennadi Liakhovetski > + * > + * 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
Re: [U-Boot] fsl_i2c: increase I2C timeout values and make them configurable
Wolfgang Grandegger wrote on 15/09/2009 13:53:13: > > Joakim Tjernlund wrote: > >> Wolfgang Grandegger wrote: > >> > >>> I did not follow the thread yet, sorry. I implemented AN2819 for Linux > >>> (see http://lxr.linux.no/#linux+v2.6.31/drivers/i2c/busses/i2c-mpc.c) > >>> some time ago using Timur's table approach. But there is no difference > >>> between the table and the algorithm to calculate the value. The table is > >>> actually derived from the same algorithm. > >> The problem with the table is that it does not allow for flexibility in > >> choosing dfsr. When I implemented the table code, I did not think that > >> this > >> was a problem, but apparently it is. > > > > Yes, it is a problem for us as our board is out of spec. The rise time is > > way off > > spec. By trial and error with the DFSR/FDR I managed to get a stable > > connection. > > What is less funny though is that I need to program FDR/DFSR differently > > in u-boot resp. kernel. to make it work. > > I suspect it is due to kernel being IRQ driven and has longer pause > > between chars, but it is a guess. > > > > In any case, the revised AN2819 dictates a different algorithm but I feel > > it is a bit incomplete w.r.t Condition 2: > > > > • Condition 2: B × T ≥ tI2CRM + 3 × C × T. > > Given a suitable value of DFSR, chosen to satisfy Condition 1, this > inequality must also be met to guarantee > > that the SCL frequency matches the SCL frequency calculated by the divider > equation. It is important to > > note that tI2CRM is the measured rise time of the SCL signal, which is > defined as the time for the signal to > > rise from 10% to 70% of VCC. > > > > NOTE > >Note that the rise time must not exceed 300 nanoseconds > and that the above > >two conditions must both be satisfied to ensure that the > > actual SCL > >frequency values align with the calculated values. By > > meeting these > >conditions, the measured SCL frequency will match the > > calculated > >frequency to within 5 kHz. Ignoring either of these > conditions may result in > >larger discrepancies between these frequency values. > > > > How important is Condition 2 and what to do with rise times > 300 ns? The > MAX rise time > > for 100 KHz is 1000 ns so there is a gap here. > > > > My testing suggests that this is not important. Bigger DFSR, in my case 0x6 > or 0x10, is key > > to get a stable I2C bus. > > > > Jocke > > PS. > > Wolfgang, I sent a test program to calculate the new DFSR/FDR values in > the thread, you > > might find it useful if you are going to try out the new AN2819 > > Where do I find this test program. In this thread. Attached for you convenience. > I just dig out my program to > calculate the table entries for the Linux i2c-mpc.c. It actually > reproduced Timur's (old) U-Boot values. Unfortunately, finding *good* > dfsr/fdr settings is no trivial and takes time. That was what my program intends to do. Works quite well but isn't perfect(See attached file: fdr.c) > Till recently, the > i2c-mpc driver of Linux did use *fixed* save values as shown here: > > http://lxr.linux.no/#linux+v2.6.29/drivers/i2c/busses/i2c-mpc.c > > And also with newer kernels, the table is only used if one of the > following I2C DTS properties is defined: > > - fsl,preserve-clocking; ehh, I figured preserve-clocking meant use whatever fdr/dfsr is already set to. > - clock-frequency = <40>; > > See > http://lxr.linux.no/#linux+v2.6.31/Documentation/powerpc/dts-bindings/fsl/i2c.txt I am using 2.6.30 and I think it is fairly equal to yours. I am not using either property above so the linux i2c-mpc. driver falls back to fdr=0x31 and dfsr=0x10 and this works well. It is u-boot that isn't working. However, I have found a few driver bugs in the u-boot driver and fixing those makes the fsl-i2c.c driver work well again. You can easily stress test I2C in u-boot by entering date;date;date;date;date and then press and hold Enter for a while. Jocke fdr.c Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx27ads: add support for iMX27ADS board from Freescale
Dear Alan Carvalho de Assis, In message <37367b3a0909150513o76ed5842u4ce717b535f0a...@mail.gmail.com> you wrote: > ping You may (or may not have noticed) that we have reorganized the custodians for ARM systems in the meantime. By now, Tom Rix is the responsible custodian who is supposed to pick up this patch (assuming there are no pending review comments for it). AFAIK, Tom is on vacation this week, and I'm not sure if he has network connectivity and/or time to work on this. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Any sufficiently advanced technology is indistinguishable from a rigged demo. - Andy Finkel, computer guy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx27ads: add support for iMX27ADS board from Freescale
Hi Denk, On 9/15/09, Wolfgang Denk wrote: > Dear Alan Carvalho de Assis, > > In message <37367b3a0909150513o76ed5842u4ce717b535f0a...@mail.gmail.com> you > wrote: >> ping > > You may (or may not have noticed) that we have reorganized the > custodians for ARM systems in the meantime. By now, Tom Rix is the > responsible custodian who is supposed to pick up this patch (assuming > there are no pending review comments for it). > > AFAIK, Tom is on vacation this week, and I'm not sure if he has > network connectivity and/or time to work on this. > Sure, thank you very much. Best Regards, Alan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Firmware Upgrade
Hi Wolfgang Denk, Thank you very much for the reply!!! Few questions: 1) You said " If your environment is stored in NOR or NAND flash, then you can use the tools from the tools/env/ directory (fw_setenv / fw_printenv)." *It is already stored in NOR Flash. This is not in a separate partition. Should it be in a separate partition? Currently uboot.bin and environment variable are in mtd1 partition. Any problem? Should i create another partition forenvironment variables alone? *2) I have downloaded these tools from* http://packages.debian.org/unstable/main/uboot-envtools *. I am not able to make it. I need to cross compile this for MIPS. Can u suggest me an url where i can get the stable and compilable src code. Thanks Rahanesh Wolfgang Denk wrote: > Dear Rahanesh, > > In message <4aaf71e3.7050...@tataelxsi.co.in> you wrote: > >> Is it Possible from Linux to set an environment variable of u-Boot.? >> > > If your environment is stored in NOR or NAND flash, then you can use > the tools from the tools/env/ directory (fw_setenv / fw_printenv). > > It should be trivial to adapt the code for other storage devices, too. > > >> But after a successful download of new jffs and writing to mtd2 >> partition , How will Linux update the environment variable of U-boot? >> > > Use fw_setenv. > > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > Any sufficiently advanced technology is indistinguishable from magic. >- Arthur C. Clarke > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI: DaVinci: Adding GIO addresses to header file
> > From: Sandeep Paulraj > > This patch adds GIO definitions to the hardware.h > header file > > Signed-off-by: Sandeep Paulraj > --- > include/asm-arm/arch-davinci/hardware.h | 23 +++ > 1 files changed, 23 insertions(+), 0 deletions(-) > Pushed to u-boot-ti ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci DM365: Removing header file which does not exist
> > From: Sandeep Paulraj > > The DaVinci DM365 EVM board specific code was including a header file > which does not exist. So removing this header file. > > Signed-off-by: Sandeep Paulraj > --- > board/davinci/dm365evm/dm365evm.c |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > Pushed to u-boot-ti ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI: DaVinci DM365: Minor config cleanup
> > From: Sandeep Paulraj > > The DM365 config was using the 'CONFIG_CMD_SAVEENV' flag. > This is already included when we include the > config_cmd_default.h header file. So this flag is removed. > Also another flag to enable NAND functions was being > enabled incorrectly. > > Signed-off-by: Sandeep Paulraj > --- > include/configs/davinci_dm365evm.h |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > Pushed to u-boot-ti ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3 MMC: Fix warning dereferencing type-punned pointer
> > Fix warning > > dereferencing type-punned pointer will break strict-aliasing rules > > Signed-off-by: Dirk Behme > > --- > > Patch against recent u-boot-ti git > f4f92c81835ccc43f74925737dfd478edb0182f2 > "TI: OMAP3: Overo Tobi ethernet support" > > Compile tested only ./MAKEALL ARM_CORTEX_A8 > > drivers/mmc/omap3_mmc.c | 56 -- > -- > 1 file changed, 29 insertions(+), 27 deletions(-) Pushed to u-boot-ti ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Firmware Upgrade
Dear Rahanesh, In message <4aaf9a1f.1060...@tataelxsi.co.in> you wrote: > > Thank you very much for the reply!!! You are welcome. > Few questions: Hm... please do not top-post / full quote. Please make sure to read http://www.netmeister.org/news/learn2quote.html > 1) You said " If your environment is stored in NOR or NAND flash, then > you can use > > the tools from the tools/env/ directory (fw_setenv / fw_printenv)." > >*It is already stored in NOR Flash. This is not in a separate partition. > Should it be in a separate partition? That's fine. A separate partition is not needed. the fw_*env tools can be easily configured for your setup. >Currently uboot.bin and environment variable are in mtd1 partition. Any > problem? Should i create another partition for environment variables alone? No changes are necessary. > *2) I have downloaded these tools from* > http://packages.debian.org/unstable/main/uboot-envtools *. I am not > able to make it. I need to cross compile this for MIPS. Can u suggest > me an url where i can get the stable and compilable src code. The tools come as part of the U-Boot source code. Please see http://www.denx.de/wiki/U-Boot/SourceCode for details. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, "Errand of Mercy", stardate 3198.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] No NAND device found!!! Freescale MPC8544+SAMSUNG 1GB Nand Flash , please help!
http://www.nabble.com/file/p25455541/nand_error.bmp nand_error.bmp Hi all,
I can't do READID with nand_get_flash_type in the nand_base.c
What I get is an error "No NAND device found!!!"
My board is freescale mpc8544 with samsung K9K8G08U0A, the device is
supposed {NAND 1GiB 3,3V 8-bit", 0xD3, 0, 1024, 0, LP_OPTIONS} .
What I did is copy the nand.c from /board/tqc/tqm85xx/nand.c into
/board/freescale/mpc8544ds
Add #define CONFIG_CMD_NAND into MPC8544DS.h, setup TLB/LAW/BR/OR for nand
flash.
Add RAM array of upm into /board/.../nand.c.
When booting, I can get the chip select signal put low with scope.
Trace the code, it get both dev_id and tmp_id 0x00ff.
Per the /driver/mtd/nand/nand_base.c , /driver/mtd/nand/fsl_upm.c , and
/board/.../nand.c
I break down the upm operation into the upm control(mamr, mar, IO_ADDR_R,
IO_ADDR_W)
And then, I tried the low level register control under CodeWarrior command
window, it's still failed.
As below: (CCSRBR = 0xe000 , nand_flash_base = 0xff00)
change 0xe0005070 0x3008 (OP=11, pattern_offset=8)
change 0xe0005068 0x9000
change 0xff00 0x0
change 0xe0005070 0x0
change 0xe0005070 0x3010
change 0xe0005068 0x
change 0xff00 0x0
change 0xe0005070 0x0
change 0xe0005070 0x3008
change 0xe0005068 0x
change 0xff00 0x0
change 0xe0005070 0x0
display 0xff00
I don't know why?
Any MARCO I should add ?
Or any special operation should I add into nand_base.c ?
Please help, thank you.
--
View this message in context:
http://www.nabble.com/No-NAND-device-found%21%21%21-Freescale-MPC8544%2BSAMSUNG-1GB-Nand-Flash-%2C-please-help%21-tp25455541p25455541.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] TQM85xx: enable partition support, sort commands
>>> Ok. I think we are see two issues interact. >>> >>> I've just sent a pull request w/the RESET_VECTOR_ADDRESS fix that >>> should address the linker script issue. These seems to build >>> cleanly >>> on all 85xx platforms w/ELDK4.2 for me. >>> >>> Now if you apply the TQM85xx.h on top of that you will see that the >>> enabling of new features causes the size to increase beyond what is >>> allocated for TQM8540. >> >> Maybe. But this is just another manifestation of the original >> problem: >> without commit ec79d33 we didn't need the RESET_VECTOR_ADDRESS stuff >> at all, and an image size of 256 kB was sufficient without and with >> the "TQM85xx: enable partition suppor" patch applied. >> >> Now, after commit ec79d33 (which needed to be fixed by the >> RESET_VECTOR_ADDRESS stuff in the first place), we suddenly need more >> than 256 kB. >> >> This obviously means that commit ec79d33 introduced changes to the >> image layout that make it bigger. >> >> I consider this a bug in commit ec79d33. I don't want to waste more >> space than needed. > > I don't agree. If I revert both commits and apply the TQM config.h > update I see build failures. > > I've posted a 'tqm-test' branch of the mpc85xx tree that does just > that. I see the following: > > [ga...@komodo u-boot-85xx]$ ./MAKEALL TQM8540 > ... TQM8540 (MPC8540) > Configuring for TQM85xx board... > /opt/eldk/4.2/ppc-linux-x86/usr/bin/ppc_85xxDP-ld: section .bootpg > [f000 -> f1df] overlaps section .data.rel.local [e964 -> > f6a7] > /opt/eldk/4.2/ppc-linux-x86/usr/bin/ppc_85xxDP-ld: u-boot: > section .bootpg lma 0xf000 overlaps previous sections > /opt/eldk/4.2/ppc-linux-x86/usr/bin/ppc_85xxDP-ld: u-boot: > section .data.rel.ro.local lma 0xf6a8 overlaps previous sections > /opt/eldk/4.2/ppc-linux-x86/usr/bin/ppc_85xxDP-ld: u-boot: > section .data.rel lma 0xf728 overlaps previous sections > make: *** [u-boot] Error 1 > /opt/eldk/4.2/ppc-linux-x86/usr/bin/ppc_85xxDP-size: './u-boot': No > such file Wolfgang, Any update on this? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kwbimage.c: Fix compile warning when building on 32/64 bit systems
On Tuesday 15 September 2009 04:10:23 Stefan Roese wrote:
> Commit 51003b89 [kwbimage.c: Fix compile warning when building on
> 64 bit systems] changed the printf format for "sizeof(uint32_t)"
> from "%d" to "%ld". This now generates the following warning on
> 32 bit build systems:
>
> tools/kwbimage.c: In function ‘kwbimage_checksum32’:
> tools/kwbimage.c:135: warning: format ‘%ld’ expects type ‘long int’,
> but argument 4 has type ‘unsigned int’
>
> The problem is that sizeof(uint32_t) has different types on 32 bit and
> 64 bit build systems. This patch now changes the format to "%d" again and
> casts sizeof() to uint32_t, fixing the problem on both build systems.
>
> if (len % sizeof(uint32_t)) {
> - printf ("Error:%s[%d] - lenght is not in multiple of %ld\n",
> - __FUNCTION__, len, sizeof(uint32_t));
> + printf ("Error:%s[%d] - lenght is not in multiple of %d\n",
> + __FUNCTION__, len, (uint32_t)sizeof(uint32_t));
why not do it right ? use PRIu32 from inttypes.h like POSIX intended. might
as well fix the typo in the message ("length") while you're here, and use the
standardized __func__ ...
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] fsl_i2c: Add CONFIG_FSL_I2C_CUSTOM_DFSR
Joakim Tjernlund wrote: > Some boards need a higher DFSR value than the spec currently > recommends so give these boards the means to define there own. If you're going to do this, then you need to also define CONFIG_FSL_I2C_CUSTOM_FSR and CONFIG_FSL_I2C_CUSTOM_SPEED, and disable the code that lets you change the speed. Otherwise, the code will have no idea what speed the bus is really running at. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] fsl_i2c: Wait for STOP condition to propagate
After issuing a STOP one must wait until the STOP has completed
on the bus before doing something new to the controller.
Also add an extra read of SR as the manual mentions doing that
is a good idea.
Remove surplus write of CR just before a write, isn't required and
could potentially disturb the I2C bus.
Signed-off-by: Joakim Tjernlund
---
drivers/i2c/fsl_i2c.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 47bbf79..59bfab6 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -223,7 +223,7 @@ i2c_init(int speed, int slaveadd)
#endif
}
-static __inline__ int
+static int
i2c_wait4bus(void)
{
unsigned long long timeval = get_ticks();
@@ -248,6 +248,8 @@ i2c_wait(int write)
csr = readb(&i2c_dev[i2c_bus_num]->sr);
if (!(csr & I2C_SR_MIF))
continue;
+ /* Read again to allow register to stabilise */
+ csr = readb(&i2c_dev[i2c_bus_num]->sr);
writeb(0x0, &i2c_dev[i2c_bus_num]->sr);
@@ -293,9 +295,6 @@ __i2c_write(u8 *data, int length)
{
int i;
- writeb(I2C_CR_MEN | I2C_CR_MSTA | I2C_CR_MTX,
- &i2c_dev[i2c_bus_num]->cr);
-
for (i = 0; i < length; i++) {
writeb(data[i], &i2c_dev[i2c_bus_num]->dr);
@@ -351,6 +350,9 @@ i2c_read(u8 dev, uint addr, int alen, u8 *data, int length)
&& i2c_write_addr(dev, I2C_READ_BIT, 1) != 0)
i = __i2c_read(data, length);
+ if (i2c_wait4bus()) /* Wait until STOP */
+ debug("i2c_read: wait4bus timed out\n");
+
writeb(I2C_CR_MEN, &i2c_dev[i2c_bus_num]->cr);
if (i == length)
@@ -372,6 +374,8 @@ i2c_write(u8 dev, uint addr, int alen, u8 *data, int length)
}
writeb(I2C_CR_MEN, &i2c_dev[i2c_bus_num]->cr);
+ if (i2c_wait4bus()) /* Wait until STOP */
+ debug("i2c_write: wait4bus timed out\n");
if (i == length)
return 0;
--
1.6.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] fsl_i2c: Add CONFIG_FSL_I2C_CUSTOM_DFSR
Some boards need a higher DFSR value than the spec currently recommends so give these boards the means to define there own. Signed-off-by: Joakim Tjernlund --- drivers/i2c/fsl_i2c.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c index 59bfab6..ea0146c 100644 --- a/drivers/i2c/fsl_i2c.c +++ b/drivers/i2c/fsl_i2c.c @@ -172,14 +172,17 @@ static unsigned int set_i2c_bus_speed(const struct fsl_i2c *dev, u8 fdr; #ifdef __PPC__ u8 dfsr; +#ifdef CONFIG_FSL_I2C_CUSTOM_DFSR + dfsr = CONFIG_FSL_I2C_CUSTOM_DFSR; +#else dfsr = fsl_i2c_speed_map[i].dfsr; #endif + writeb(dfsr, &dev->dfsrr); /* set default filter */ +#endif fdr = fsl_i2c_speed_map[i].fdr; speed = i2c_clk / fsl_i2c_speed_map[i].divider; writeb(fdr, &dev->fdr); /* set bus speed */ -#ifdef __PPC__ - writeb(dfsr, &dev->dfsrr); /* set default filter */ -#endif + break; } -- 1.6.4.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fsl_i2c: increase I2C timeout values and make them configurable
> > I am using 2.6.30 and I think it is fairly equal to yours. > I am not using either property above so the linux i2c-mpc. driver falls back > to fdr=0x31 and dfsr=0x10 and this works well. It is u-boot that isn't > working. > However, I have found a few driver bugs in the u-boot driver and fixing those > makes the fsl-i2c.c driver work well again. I just sent you two patches that addresses my problems, I hope you can have a look. The kernel driver should also be updated with the "wait for STOP on the bus" patch. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] fsl_i2c: Add CONFIG_FSL_I2C_CUSTOM_DFSR
> > Joakim Tjernlund wrote: > > Some boards need a higher DFSR value than the spec currently > > recommends so give these boards the means to define there own. > Wow, that was fast :) > If you're going to do this, then you need to also define > CONFIG_FSL_I2C_CUSTOM_FSR and CONFIG_FSL_I2C_CUSTOM_SPEED, and disable the > code that lets you change the speed. Otherwise, the code will have no idea > what speed the bus is really running at. No, the impact on speed from DFSR is pretty small so it will be close enough. It will only complicate matters for the user I think. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] fsl_i2c: Add CONFIG_FSL_I2C_CUSTOM_DFSR
Joakim Tjernlund wrote: > No, the impact on speed from DFSR is pretty small so it will > be close enough. How small? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] fsl_i2c: Add CONFIG_FSL_I2C_CUSTOM_DFSR
Timur Tabi wrote on 15/09/2009 21:04:47: > > Joakim Tjernlund wrote: > > > No, the impact on speed from DFSR is pretty small so it will > > be close enough. > > How small? >From the app note: divisor = B * (A + ((3*C)/B)*2); C is dfsr and 10 <= A <= 30, 16 <= B <= 2048 Considering the actual speed may be way lower the requested speed I think this is small enough. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] fsl_i2c: Add CONFIG_FSL_I2C_CUSTOM_DFSR
> > Timur Tabi wrote on 15/09/2009 21:04:47: > > > > Joakim Tjernlund wrote: > > > > > No, the impact on speed from DFSR is pretty small so it will > > > be close enough. > > > > How small? > From the app note: > divisor = B * (A + ((3*C)/B)*2); > > C is dfsr and 10 <= A <= 30, 16 <= B <= 2048 > Considering the actual speed may be way lower the requested speed > I think this is small enough. Once we have the new procedure in place, we can calculate the exact divisor so the need for extra CONFIG_ options goes away. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kwbimage.c: Fix compile warning when building on 64 bit systems (again)
Commit 51003b89 attempted to fix a build problem on 64 bit systems,
but just turned it into a build problem on 32 bit systems (silly me).
Now do the Right Thing (TM) and use a "%zu" printf format.
Signed-off-by: Wolfgang Denk
---
tools/kwbimage.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index ee067cb..b53 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -131,7 +131,7 @@ static uint32_t kwbimage_checksum32 (uint32_t *start,
uint32_t len, uint32_t csu
return 0;
if (len % sizeof(uint32_t)) {
- printf ("Error:%s[%d] - lenght is not in multiple of %ld\n",
+ printf ("Error:%s[%d] - lenght is not in multiple of %zu\n",
__FUNCTION__, len, sizeof(uint32_t));
return 0;
}
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kwbimage.c: Fix compile warning when building on 32/64 bit systems
Dear Mike Frysinger,
In message <200909151213.38895.vap...@gentoo.org> you wrote:
>
> > if (len % sizeof(uint32_t)) {
> > - printf ("Error:%s[%d] - lenght is not in multiple of %ld\n",
> > - __FUNCTION__, len, sizeof(uint32_t));
> > + printf ("Error:%s[%d] - lenght is not in multiple of %d\n",
> > + __FUNCTION__, len, (uint32_t)sizeof(uint32_t));
>
> why not do it right ? use PRIu32 from inttypes.h like POSIX intended. might
I don't think that would fix it, as PRIu32 is just "u", but what we
really need to be compatible with both 32 and 64 bit environments is
"%zu".
> as well fix the typo in the message ("length") while you're here, and use the
Ah, well spotted. Thanks.
> standardized __func__ ...
Well, ok. Next time, maybe ;-)
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
What about WRITING it first and rationalizing it afterwords? :-)
- Larry Wall in <8...@jpl-devvax.jpl.nasa.gov>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] kwbimage.c: Fix compile warning when building on 64 bit systems (again)
Commit 51003b89 attempted to fix a build problem on 64 bit systems,
but just turned it into a build problem on 32 bit systems (silly me).
Now do the Right Thing (TM) and use a "%zu" printf format.
Also fix spelling error.
Signed-off-by: Wolfgang Denk
---
v2: Also fix spelling error; cudos Mike Frysinger
tools/kwbimage.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index ee067cb..7b26920 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -131,7 +131,7 @@ static uint32_t kwbimage_checksum32 (uint32_t *start,
uint32_t len, uint32_t csu
return 0;
if (len % sizeof(uint32_t)) {
- printf ("Error:%s[%d] - lenght is not in multiple of %ld\n",
+ printf ("Error:%s[%d] - length is not in multiple of %zu\n",
__FUNCTION__, len, sizeof(uint32_t));
return 0;
}
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] TQM85xx: enable partition support, sort commands
Dear Kumar Gala, In message you wrote: > > Any update on this? Not yet, got other, more pressing work to do. Sorry. Will look into this ASAP. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Don't hit a man when he's down - kick him; it's easier. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ppc4xx
Dear Stefan Roese, In message <200909111047.27541...@denx.de> you wrote: > The following changes since commit e7963772eb78a6aa1fa65063d64eab3a8626daac: > Marcel Ziswiler (1): > muas3001: remove BRG clock node fixup to use common mpc8260 code. > > are available in the git repository at: > > git://www.denx.de/git/u-boot-ppc4xx.git master > > Dirk Eibach (1): > ppc4xx: Rename compactcenter to intip > > Stefan Roese (1): > ppc4xx: Big cleanup of PPC4xx defines > > MAINTAINERS|2 +- > MAKEALL|2 +- > Makefile | 16 +- > board/amcc/acadia/acadia.c | 12 +- > board/amcc/acadia/memory.c | 18 +- > board/amcc/acadia/pll.c| 52 ++-- > board/amcc/bamboo/bamboo.c | 104 +++--- > board/amcc/bamboo/flash.c |2 +- > board/amcc/bubinga/bubinga.c |4 +- > board/amcc/bubinga/flash.c | 20 +- > board/amcc/canyonlands/canyonlands.c |4 +- > board/amcc/ebony/ebony.c | 32 +- > board/amcc/katmai/katmai.c |6 +- > board/amcc/luan/luan.c | 18 +- > board/amcc/ocotea/ocotea.c | 48 ++-- > board/amcc/redwood/redwood.c | 18 +- > board/amcc/sequoia/sequoia.c | 60 ++-- > board/amcc/taihu/taihu.c |6 +- > board/amcc/taishan/showinfo.c | 70 ++-- > board/amcc/taishan/taishan.c | 44 +- > board/amcc/walnut/flash.c | 20 +- > board/amcc/yosemite/yosemite.c | 58 ++-- > board/amcc/yucca/flash.c |2 +- > board/amcc/yucca/yucca.c | 20 +- > board/cray/L1/L1.c | 38 +- > board/cray/L1/init.S | 24 +- > board/csb272/csb272.c | 18 +- > board/csb272/init.S| 50 ++-- > board/csb472/csb472.c | 18 +- > board/csb472/init.S| 54 ++-- > board/dave/PPChameleonEVB/PPChameleonEVB.c |6 +- > board/dave/PPChameleonEVB/flash.c |8 +- > board/eric/eric.c |2 +- > board/eric/flash.c | 20 +- > board/eric/init.S | 126 +++--- > board/esd/apc405/apc405.c | 26 +- > board/esd/ar405/flash.c|8 +- > board/esd/ash405/ash405.c |2 +- > board/esd/ash405/flash.c |8 +- > board/esd/canbt/canbt.c|8 +- > board/esd/canbt/flash.c| 10 +- > board/esd/cms700/cms700.c |2 +- > board/esd/cms700/flash.c |8 +- > board/esd/cpci2dp/cpci2dp.c| 12 +- > board/esd/cpci2dp/flash.c | 10 +- > board/esd/cpci405/cpci405.c| 22 +- > board/esd/cpci405/flash.c | 20 +- > board/esd/cpciiser4/flash.c| 10 +- > board/esd/dp405/dp405.c|2 +- > board/esd/dp405/flash.c|8 +- > board/esd/du405/du405.c|8 +- > board/esd/du405/flash.c| 20 +- > board/esd/du440/du440.c| 56 ++-- > board/esd/hh405/flash.c|8 +- > board/esd/hh405/hh405.c|2 +- > board/esd/hub405/flash.c |8 +- > board/esd/hub405/hub405.c |2 +- > board/esd/ocrtc/flash.c| 20 +- > board/esd/ocrtc/ocrtc.c|2 +- > board/esd/pci405/flash.c |8 +- > board/esd/pci405/pci405.c | 28 +- > board/esd/plu405/flash.c |8 +- > board/esd/plu405/plu405.c |2 +- > board/esd/pmc405/pmc405.c |6 +- > board/esd/pmc405de/pmc405de.c |2 +- > board/esd/pmc440/pmc440.c | 66 ++-- > board/esd/voh405/flash.c |8 +- > board/esd/voh405/voh405.c |2 +- > board/esd/vom405/flash.c |8 +- > board/esd/vom405/vom405.c |2 +-
Re: [U-Boot] Microblaze Pull Request
Dear Michal Simek, In message <4aae3d42.3020...@monstr.eu> you wrote: > Hi Wolfgang, > > I decided to remove ll_temac driver from master branch. > He has a lot of work and I want to clean other u-boot stuff. > > Ben: LL-temac driver in in net branch please add it to your net branch. > > There are some important patches: > 1. Removing Suzaku board > 2. Remove old emac driver > 3. Cleanup license for emaclite > + some minor patches. > > Thanks for pulling that changes, > Michal > > > The following changes since commit e7963772eb78a6aa1fa65063d64eab3a8626daac: > Marcel Ziswiler (1): > muas3001: remove BRG clock node fixup to use common mpc8260 code. > > are available in the git repository at: > > git://www.denx.de/git/u-boot-microblaze.git master > > Michal Simek (6): > microblaze: Add sbss, scommon and COMMON symbols for clearing > microblaze: Short size of global data and fix malloc size > net: Remove old Xilinx Emac driver > microblaze: Remove AtmarkTechno Suzaku board > microblaze: Enable hush parser > net: emaclite: Cleanup license to be GPL compatible > > MAINTAINERS|4 - > MAKEALL|1 - > Makefile |5 - > board/AtmarkTechno/suzaku/Makefile | 44 --- > board/AtmarkTechno/suzaku/config.mk| 29 -- > board/AtmarkTechno/suzaku/flash.c | 46 --- > board/AtmarkTechno/suzaku/suzaku.c | 32 -- > board/AtmarkTechno/suzaku/u-boot.lds | 68 > board/xilinx/microblaze-generic/u-boot.lds |3 + > drivers/net/Makefile |1 - > drivers/net/xilinx_emac.c | 464 > > drivers/net/xilinx_emaclite.c | 39 ++-- > include/configs/microblaze-generic.h | 17 +- > include/configs/suzaku.h | 110 --- > 14 files changed, 33 insertions(+), 830 deletions(-) > delete mode 100644 board/AtmarkTechno/suzaku/Makefile > delete mode 100644 board/AtmarkTechno/suzaku/config.mk > delete mode 100644 board/AtmarkTechno/suzaku/flash.c > delete mode 100644 board/AtmarkTechno/suzaku/suzaku.c > delete mode 100644 board/AtmarkTechno/suzaku/u-boot.lds > delete mode 100644 drivers/net/xilinx_emac.c > delete mode 100644 include/configs/suzaku.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Any technology distinguishable from magic is insufficiently advanced. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx27ads: add support for iMX27ADS board from Freescale
Hi Some minor below. Alan Carvalho de Assis skrev: > This patch adds support to iMX27ADS development board. This board has > 128MB RAM, 32MB NOR Flash and 128MB NAND Flash. Currently only > booting from NOR is supported. > > Signed-off-by: Alan Carvalho de Assis > --- > MAINTAINERS |3 + > MAKEALL |1 + > Makefile|3 + > board/freescale/mx27ads/Makefile| 51 > board/freescale/mx27ads/config.mk |1 + > board/freescale/mx27ads/lowlevel_init.S | 128 +++ > board/freescale/mx27ads/mx27ads.c | 93 ++ > board/freescale/mx27ads/u-boot.lds | 56 + > include/configs/mx27ads.h | 202 > +++ > 9 files changed, 538 insertions(+), 0 deletions(-) > create mode 100644 board/freescale/mx27ads/Makefile > create mode 100644 board/freescale/mx27ads/config.mk > create mode 100644 board/freescale/mx27ads/lowlevel_init.S > create mode 100644 board/freescale/mx27ads/mx27ads.c > create mode 100644 board/freescale/mx27ads/u-boot.lds > create mode 100644 include/configs/mx27ads.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index e9db278..5b25188 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -550,6 +550,9 @@ Thomas Elste > > modnet50ARM720T (NET+50) > > +Alan Carvalho de Assis > + mx27ads i.MX27 > + The list shall be kept sorted by maintainer name. So the mx27ads shall be moved. > Fabio Estevam > > mx31pdk i.MX31 > diff --git a/MAKEALL b/MAKEALL > index f0ed8ea..8411eef 100755 > --- a/MAKEALL > +++ b/MAKEALL > @@ -520,6 +520,7 @@ LIST_ARM9=" \ > cp926ejs\ > cp946es \ > cp966 \ > + mx27ads \ The list is sorted alphabetically so move this down a bit. > imx27lite \ > lpd7a400\ > mv88f6281gtw_ge \ > diff --git a/Makefile b/Makefile > index 0449a5b..6fa4b28 100644 > --- a/Makefile > +++ b/Makefile > @@ -2961,6 +2961,9 @@ davinci_dm365evm_config : unconfig > imx27lite_config:unconfig > @$(MKCONFIG) $(@:_config=) arm arm926ejs imx27lite logicpd mx27 > > +mx27ads_config : unconfig > + @$(MKCONFIG) $(@:_config=) arm arm926ejs mx27ads freescale mx27 > + > lpd7a400_config \ > lpd7a404_config: unconfig > @$(MKCONFIG) $(@:_config=) arm lh7a40x lpd7a40x > diff --git a/board/freescale/mx27ads/lowlevel_init.S > b/board/freescale/mx27ads/lowlevel_init.S > new file mode 100644 > index 000..a4e1191 > --- /dev/null > +++ b/board/freescale/mx27ads/lowlevel_init.S > @@ -0,0 +1,128 @@ > +/* > + * Copyright (C) 2008, Guennadi Liakhovetski > + * > + * 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 > + */ > + > +/* > + * For clock initialization, see chapter 3 of the "MCIMX27 Multimedia > + * Applications Processor Reference Manual, Rev. 0.2". > + * > + */ > + > +#include > +#include > +#include > +#include > + > +.macro sdram_init > + /* > + * DDR on CSD0 > + */ > + write32 0xD8001010 0x0008 I would insert a comma (,) after the first argument to the macro. Didn't know it worked without. The same comment applies to the rest of this file. Don't know what the U-boot coding standard says about this though. > + write32 0x10027828 0x > + write32 0x10027830 0x > + write32 0x10027834 0x > + write32 0x10027838 0x5005 > + write32 0x1002783C 0x1555 > + write32 0xD8001010 0x0004 > + write32 0xD8001004 0x006ac73a > + write32 0xD8001000 0x9210 > + write32 0xAF00 0x > + write32 0xD8001000 0xA210 > + write32 0xAF00 0x > + write32 0xAF00 0x > + write32 0xAF00 0x > + write32 0xAF00 0x > + write32 0xD8001000 0xA220 > + write32 0xAF00 0x > + write32 0xAF00 0x > + write32 0xAF00 0x > + write32 0xAF00 0x > + write32 0xD8001000 0xb210 > + ldr r0, =0xA033 > + mov r1, #0xda > + strb
Re: [U-Boot] [PATCH v2 1/2] mkconfig: split the board make target to multiple config targets
Dear Mingkai Hu, In message <1252466603-25103-1-git-send-email-mingkai...@freescale.com> you wrote: > To simplify the top level makefile it useful to be able to parse > the top level makefile target to multiple individual target, then > put them to the config.h, leave the board config file to handle > the different targets. > > Note that this method uses the '_'(underline) as the delimiter when > splits the board make target. > > Signed-off-by: Mingkai Hu > --- > > According to the comments from Wolfgang and Scott, I modified > the patch and made some modification over v1: > > - remove the sectence thats puts the splited variables to the >config.mk, we can use the CONFIG_MK_* in the board config file >to override the variable in the board config file. > > - change CONFIG_OPT_* to CONFIG_MK_* > > mkconfig |7 +++ > 1 files changed, 7 insertions(+), 0 deletions(-) Applied, thanks. Thsi also reverts commit 511c02f611cb5afa1b8ca5980cbaa0de377f. Sorry for the confusion I caused by picking the wrong version of this patch. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Hacking's just another word for nothing left to kludge. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3 v2] standalone: convert to kbuild style
Dear Mike Frysinger, In message <1252108485-26641-1-git-send-email-vap...@gentoo.org> you wrote: > Clean up the arch/cpu/board/config checks as well as redundant setting of > srec/bin variables by using the kbuild VAR-$(...) style. > > Signed-off-by: Mike Frysinger > --- > v2 > - update to latest master > > examples/standalone/Makefile | 101 > -- > 1 files changed, 29 insertions(+), 72 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The connection between the language in which we think/program and the problems and solutions we can imagine is very close. For this reason restricting language features with the intent of eliminating pro- grammer errors is at best dangerous. - Bjarne Stroustrup in "The C++ Programming Language" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx27ads: add support for iMX27ADS board from Freescale
Hi Magnus, On 9/15/09, Magnus Lilja wrote: > Hi > > Some minor below. > > Alan Carvalho de Assis skrev: ... >> +#include >> +#include >> +#include >> +#include >> + >> +.macro sdram_init >> +/* >> + * DDR on CSD0 >> + */ >> +write32 0xD8001010 0x0008 > > I would insert a comma (,) after the first argument to the macro. Didn't > know it worked without. > The same comment applies to the rest of this file. Don't know what the > U-boot coding standard says about this though. > Hmm, I think I based on other example. Need I to replace it? >> +/* peripheral clock divider */ >> +write32 PCDR0 0x120470C3/* FIXME*/ >> +write32 PCDR1 0x03030303/* PERDIV1=08 @133 MHz */ >> +/* PERDIV1=04 @266 MHz * >> + * / > > The last line with '* /' looks a bit odd compated to the other comments. > I will remove this extra space >> +/* >> + * Ethernet >> + */ >> +#define CONFIG_FEC_MXC >> +#define CONFIG_FEC_MXC_PHYADDR 0x1f >> +#define CONFIG_MII >> +#define CONFIG_NET_MULTI >> + >> +/*#define CONFIG_DRIVER_CS89001 >> +#define CS8900_BASE 0xD4020300 >> +#define CS8900_BUS161*/ > > Does the board have a CS8900 as well? > Yes, it has. But it is not working correctly, then I just let it commented out. Best Regards, Alan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kwbimage.c: Fix compile warning when building on 32/64 bit systems
On Tuesday 15 September 2009 15:36:54 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > if (len % sizeof(uint32_t)) {
> > > - printf ("Error:%s[%d] - lenght is not in multiple of %ld\n",
> > > - __FUNCTION__, len, sizeof(uint32_t));
> > > + printf ("Error:%s[%d] - lenght is not in multiple of %d\n",
> > > + __FUNCTION__, len, (uint32_t)sizeof(uint32_t));
> >
> > why not do it right ? use PRIu32 from inttypes.h like POSIX intended.
> > might
>
> I don't think that would fix it, as PRIu32 is just "u", but what we
> really need to be compatible with both 32 and 64 bit environments is
> "%zu".
i thought it was printing a u32. a sizeof() is size_t, so use %zu.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/4]: Move __set/clear_bit from ubifs.h to bitops.h
Dear Simon Kagstrom, In message <20090824090950.6e3f9...@marrow.netinsight.se> you wrote: > Move __set/clear_bit from ubifs.h to bitops.h > > __set_bit and __clear_bit are defined in ubifs.h as well as in > asm/include/bitops.h for some architectures. This patch moves > the generic implementation to include/linux/bitops.h and uses > that unless it's defined by the architecture. > > Signed-off-by: Simon Kagstrom > --- > ChangeLog: > v2: Unify code style (newline between __set_bit and __clear_bit) > v3: Move BIT_MASK and BIT_WORD above the include of asm/bitops.h > v4: Move the definition to generic code (Mike Frysinger) > > fs/ubifs/ubifs.h| 32 > include/asm-arm/bitops.h|2 ++ > include/asm-blackfin/bitops.h |1 + > include/asm-microblaze/bitops.h |1 + > include/asm-mips/bitops.h |1 + > include/linux/bitops.h | 38 ++ > 6 files changed, 43 insertions(+), 32 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To live is always desirable. -- Eleen the Capellan, "Friday's Child", stardate 3498.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4]: arm: Make arm bitops endianness-independent
Dear Simon Kagstrom, In message <20090824091003.0b8a6...@marrow.netinsight.se> you wrote: > arm: Make arm bitops endianness-independent > > Bring over the bitop implementations from the Linux > include/asm-generic/bitops/non-atomic.h to provide > endianness-independence. > > Signed-off-by: Simon Kagstrom > --- > ChangeLog: > v2: Use generic __set_bit and __clear_bit for ARM > > include/asm-arm/bitops.h | 47 ++--- > 1 files changed, 19 insertions(+), 28 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de War is never imperative. -- McCoy, "Balance of Terror", stardate 1709.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4]: Define ffs/fls for all architectures
Dear Simon Kagstrom, In message <20090824091012.0df5b...@marrow.netinsight.se> you wrote: > Define ffs/fls for all architectures > > UBIFS requires fls(), which is not defined for arm (and some other > architectures) and this patch adds it. The implementation is taken from > Linux and is generic. ffs() is also defined for those that miss it. > > Signed-off-by: Simon Kagstrom > --- > ChangeLog: > v2: Unify code style (empty line between ffs/fls) > v3: Move the definition to generic code (Mike Frysinger) > > include/asm-i386/bitops.h |1 + > include/asm-m68k/bitops.h |1 + > include/asm-nios/bitops.h |1 + > include/asm-nios2/bitops.h |1 + > include/asm-ppc/bitops.h |2 + > include/asm-sh/bitops.h|2 + > include/linux/bitops.h | 45 > > 7 files changed, 53 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "They that can give up essential liberty to obtain a little temporary saftey deserve neither liberty not saftey." - Benjamin Franklin, 1759 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/4]: arm: Define test_and_set_bit and test_and_clear bit for ARM
Dear Simon Kagstrom, In message <20090824091016.7be37...@marrow.netinsight.se> you wrote: > arm: Define test_and_set_bit and test_and_clear bit for ARM > > Needed for (e.g.) ubifs support to work. > > Signed-off-by: Simon Kagstrom > --- > include/asm-arm/bitops.h | 28 +--- > 1 files changed, 25 insertions(+), 3 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The so-called "desktop metaphor" of today's workstations is instead an "airplane-seat" metaphor. Anyone who has shuffled a lap full of papers while seated between two portly passengers will recognize the difference -- one can see only a very few things at once. - Fred Brooks, Jr. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] still nothing on serial output sa1100
Greetings, Ive been busy trying to get any signs from my generated u-boot.bin. I started thinking it was caused by the memory setup and replicated the one I had used in blob (which works). Still got nothing and now Im looking for suggestions on where to proceed. Can I count on the serial drivers working? What process starts after the memory is setup? Attached my current Setup.S: diff --git a/board/jornada/setup.S b/board/jornada/setup.S new file mode 100644 index 000..1c6e233 --- /dev/null +++ b/board/jornada/setup.S @@ -0,0 +1,226 @@ +/* + * Memory Setup stuff - taken from blob memsetup.S + * + * Copyright (C) 1999 2000 2001 Erik Mouw (j.a.k.m...@its.tudelft.nl) and + *Jan-Derk Bakker (j.d.bak...@its.tudelft.nl) + * 2004 (c) MontaVista Software, Inc. + * + * 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 "config.h" +#include "version.h" + + +/*--- + * Board defines: + */ + +#define MDCNFG 0x00 +#define MDCAS000x04 +#define MDCAS010x08 +#define MDCAS020x0C +#define MSC0 0x10 +#define MSC1 0x14 +#define MECR 0x18 +#define MDREFR 0x1C +#define MDCAS200x20 +#define MDCAS210x24 +#define MDCAS220x28 +#define MSC2 0x2C +#define SMCNFG 0x30 + +#defineMDCNFG_BANK0_ENABLE (1 << 0) +#define MDCNFG_DTIM0_SDRAM (1 << 2) +#define MDCNFG_DWID0_32B (0 << 3) +#define MDCNFG_DRAC0(n_) (((n_) & 7) << 4) +#define MDCNFG_TRP0(n_)(((n_) & 0xF) << 8) +#define MDCNFG_TDL0(n_)(((n_) & 3) << 12) +#define MDCNFG_TWR0(n_)(((n_) & 3) << 14) +#define MSC_RT_ROMFLASH0 +#define MSC_RBW32 (0 << 2) +#define MSC_RDF(n_)(((n_) & 0x1f) << 3) +#define MSC_RDN(n_)(((n_) & 0x1f) << 8) +#define MSC_RRR(n_)(((n_) & 0x07) << 13) +#define MSC_RT_VARLAT_345 1 +#define MDREFR_TRASR(n_) (n_ & (0x000f)) +#define MDREFR_DRI(n_) ((n_ & (0x0fff)) << 4) +#define MDREFR_K0RUN (1 << 17) +#define MDREFR_K0DB2 (1 << 18) +#define MDREFR_K1RUN (1 << 21) +#define MDREFR_K1DB2 (1 << 22) +#define MDREFR_K2RUN (1 << 25) +#define MDREFR_K2DB2 (1 << 26) +#define MDREFR_SLFRSH (1 << 31) +#define MDREFR_E1PIN (1 << 20) +#definePSSR_DH 0x0008 +#define PSSR 0x04 +#definePM_BASE 0x9002 + +#define mdcnfg_1 (MDCNFG_BANK0_ENABLE|MDCNFG_DTIM0_SDRAM|MDCNFG_DWID0_32B|MDCNFG_DRAC0(6)|MDCNFG_TRP0(2)|MDCNFG_TDL0(3)|MDCNFG_TWR0(1)) +#define cs0_1 (MSC_RT_ROMFLASH|MSC_RBW32|MSC_RDF(15)|MSC_RDN(15)|MSC_RRR(2)) +#define cs1_1 (MSC_RT_ROMFLASH|MSC_RBW32|MSC_RDF(30)|MSC_RDN(31)|MSC_RRR(7)) +#define cs2_1 (MSC_RT_ROMFLASH|MSC_RBW32|MSC_RDF(30)|MSC_RDN(31)|MSC_RRR(7)) +#define cs3_1 (MSC_RT_ROMFLASH|MSC_RBW32|MSC_RDF(31)|MSC_RDN(31)|MSC_RRR(7)) +#define cs4_1 (MSC_RT_VARLAT_345|MSC_RBW32|MSC_RDF(11)|MSC_RDN(9)|MSC_RRR(1)) +#define cs5_1 (MSC_RT_VARLAT_345|MSC_RBW32|MSC_RDF(3)|MSC_RDN(0)|MSC_RRR(1)) +#define msc0_1 (cs0_1|(cs1_1 << 16)) +#define msc1_1 (cs2_1|(cs3_1 << 16)) +#define msc2_1 (cs4_1|(cs5_1 << 16)) + + +/*--- + * Setup parameters for the board: + */ + + +MEM_BASE: .long 0xa000 +MEM_START: .long 0xc000 +PWR_BASE: .word PM_BASE + +/* calculated from old blob bootloader */ +MEMORY_CONFIG: + .long mdcnfg_1/* mdcnfg 0x7265 */ + .long 0x557f /* mdcas00 0x557f */ + .long 0x /* mdcas01 0x */ + .long 0x /* mdcas02 0x */ + .long msc0_1 /* msc00xfff04f78 */ + .long msc1_1 /* msc10xfff8fff0 */ + .long 0x98c698c6 /* mecr0x98c698c6 */ + .long 0xdeadbeef /* mdrefr 0x04340327 */ +
Re: [U-Boot] autoscr command failure saveenv dataflash
Dear "Berns", In message you wrote: > > the reason for this problem is the definition of > > #define DATAFLASH_BUSY0x00 > #define DATAFLASH_OK 0x01 > in the file /include/dataflash.h. > > All functions return DATAFLASH_OK and in the file /common/cmd_nvedit.c > > function do_saveenv() > > return (saveenv() ? 1 : 0); > > than cause an error. > > I have modified it to return (saveenv() == 1 ? 0 : 1); > > and this works for my, but i'am not sure if this is the best way of fixing > the problem. Can you please submit this as a patch (including your SoB-Line), so we can chek it? Please see http://www.denx.de/wiki/U-Boot/Patches for details. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "(The Chief Programmer) personally defines the functional and performance specifications, designs the program, codes it, tests it, and writes its documentation... He needs great talent, ten years experience and considerable systems and applications knowledge, whether in applied mathematics, business data handling, or whatever." - Fred P. Brooks, _The Mythical Man Month_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] board/linkstation/ide.c: Fix compile warning
On Tue, 15 Sep 2009, Wolfgang Denk wrote:
> Fix warning: ide.c:60: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
>
> Signed-off-by: Wolfgang Denk
> Cc: Guennadi Liakhovetski
>
> ---
> v2: Better implementation as suggested by Scott Wood in
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/67840/focus=67891
>
> board/linkstation/ide.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/board/linkstation/ide.c b/board/linkstation/ide.c
> index 2c89d62..568fdf5 100644
> --- a/board/linkstation/ide.c
> +++ b/board/linkstation/ide.c
> @@ -54,11 +54,13 @@ int ide_preinit (void)
> if (devbusfn == -1)
> devbusfn =
> pci_find_device(PCI_VENDOR_ID_ITE,PCI_DEVICE_ID_ITE_8212,0);
> if (devbusfn != -1) {
> + u32 ide_bus_offset32;
> +
> status = 0;
>
> pci_read_config_dword (devbusfn, PCI_BASE_ADDRESS_0,
> -(u32 *)
> &ide_bus_offset[0]);
> - ide_bus_offset[0] &= 0xfffe;
> +&ide_bus_offset32);
> + ide_bus_offset[0] = ide_bus_offset32 & 0xfffe;
> ide_bus_offset[0] = pci_hose_bus_to_phys(&hose,
>ide_bus_offset[0] &
> 0xfffe,
>PCI_REGION_IO);
Ok, yes, this looks much better now without casts, but - the double " &
0xfffe" above seems completely redundant to me. I understand, that
that's not the problem you're fixing with this patch, and I will perfectly
understand if you refuse to mix these two fixes, but... Another thing -
why doesn't the compiler complain about exactly identical cast (ok,
almost) a couple of lines down for ide_bus_offset[1]? So, how about this
diff instead (only compile-tested) (not for submission yet, so, no Sob's,
no patch header):
diff --git a/board/linkstation/ide.c b/board/linkstation/ide.c
index 2c89d62..f96af74 100644
--- a/board/linkstation/ide.c
+++ b/board/linkstation/ide.c
@@ -54,20 +54,23 @@ int ide_preinit (void)
if (devbusfn == -1)
devbusfn =
pci_find_device(PCI_VENDOR_ID_ITE,PCI_DEVICE_ID_ITE_8212,0);
if (devbusfn != -1) {
+ u32 ide_bus_offset32;
+
status = 0;
- pci_read_config_dword (devbusfn, PCI_BASE_ADDRESS_0,
- (u32 *)
&ide_bus_offset[0]);
- ide_bus_offset[0] &= 0xfffe;
+ pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_0,
+ &ide_bus_offset32);
+ ide_bus_offset[0] = ide_bus_offset32 & 0xfffe;
ide_bus_offset[0] = pci_hose_bus_to_phys(&hose,
-ide_bus_offset[0] &
0xfffe,
-PCI_REGION_IO);
- pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_2,
- (u32 *) &ide_bus_offset[1]);
- ide_bus_offset[1] &= 0xfffe;
- ide_bus_offset[1] = pci_hose_bus_to_phys(&hose,
-ide_bus_offset[1] &
0xfffe,
-PCI_REGION_IO);
+ ide_bus_offset[0], PCI_REGION_IO);
+
+ if (CONFIG_SYS_IDE_MAXBUS > 1) {
+ pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_2,
+ &ide_bus_offset32);
+ ide_bus_offset[1] = ide_bus_offset32 & 0xfffe;
+ ide_bus_offset[1] = pci_hose_bus_to_phys(&hose,
+ ide_bus_offset[1], PCI_REGION_IO);
+ }
}
if (pci_find_device (PCI_VENDOR_ID_ITE, PCI_DEVICE_ID_ITE_8212, 0) !=
-1) {
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] env: only build env_embedded and envcrc when needed
Dear Mike Frysinger, In message <200909091032.17175.vap...@gentoo.org> you wrote: > > > Hm.. normally we don't add code without users... > > it's already in use, i just need to basically run sed to change it from > current name to the new one. I don't see any users in mainline, though. Or am I missing something? > > > > Also, I see no documentation for it? > > > > > > guessing you want it added to the top level README ? > > > > Indeed. What's the name supposed to mean? "The envrionment is > > embedded custom" sounds strange to me. > > i saw it as "custom embedding of the environment". the only thing it does is > enable the envcrc binary. i thought of using "CONFIG_ENVCRC", but it seemed > a > little too short. CONFIG_ENABLE_ENVCRC ? CONFIG_BUILD_ENVCRC ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To live is always desirable. -- Eleen the Capellan, "Friday's Child", stardate 3498.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v3] env: only build env_embedded and envcrc when needed
Dear Mike Frysinger, In message <1252511443-1638-1-git-send-email-vap...@gentoo.org> you wrote: > The env code is protected by the ENV_IS_EMBEDDED define, so attempting to > compile the code when this isn't defined is pointless. Now that the env > headers have unified around CONFIG_ENV_IS_EMBEDDED, convert the build > system to only build the env objects when this is enabled. And now that > the env code is conditionally compiled, we can drop the source code checks. > > For people who want to extract the environment manually, add a new option > that only enables the envcrc utility (CONFIG_ENV_IS_EMBEDDED_CUSTOM). I see no users, and I hesitate to add dead code. And CONFIG_ENV_IS_EMBEDDED_CUSTOM is an ugly and misleading name. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de All a hacker needs is a tight PUSHJ, a loose pair of UUOs, and a warm place to shift. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] Blackfin: tweak embedded env config option
Dear Mike Frysinger, In message <1252661962-16105-1-git-send-email-vap...@gentoo.org> you wrote: > Use the common config option for extracting the environment for embedding > into LDR files. ... > $(obj)u-boot.ldr:$(obj)u-boot > - $(obj)tools/envcrc --binary > $(obj)env-ldr.o > + $(CREATE_LDR_ENV) > $(LDR) -T $(CONFIG_BFIN_CPU) -c $@ $< $(LDR_FLAGS) This is all BF specific stuff, right? Maybe we should move this into some BF Makefile, then, instead of adding more and more references to magic variables that have no meaning anywhere except for BF. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Q: How do you play religious roulette? A: You stand around in a circle and blaspheme and see who gets struck by lightning first. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 答复: [PATCH 01/10] mkconfig: par se top level makefile target to multipl e config targets
Dear "Hu Mingkai-B21284",
In message
<73839b4a0818e747864426270ac332c303b8b...@zmy16exm20.fsl.freescale.net> you
wrote:
>
> About this question, now we have two interim methods until we have kconfig:
...
> 2. Add a '-t'option in mkconfig to split board config name to individual >
> targets,
> then put them to board config file.
This is what we have now, after the other approach didn't work well.
> BTW, when can we get kconfig in U-Boot? :-)
Of course we can - as soon as someone posts clean patches.
Jean-Christophe claimed several times before he had this nearly
complete resp. ready for posting, but at the moment it seems he just
beamed himself off this planet.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If you want strict real-time behavior, run in the real time schedu-
ling class. But there are no seatbelts or airbags; main(){for(;;);}
can hard hang your system. -- Bart Smaalders
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] tools/netconsole: make a bit more robust
Dear Mike Frysinger, In message <1252513221-2524-1-git-send-email-vap...@gentoo.org> you wrote: > The netcat utility likes to exit when it receives an empty packet (as it > thinks this means EOF). This can easily occur when working with command > line editing as this behavior will be triggered when using backspace. Or > with tabs and command line completion. So create two netcat processes - > one to only listen (and put it into a loop), and one to do the sending. > Once the user quits the transmitting netcat, the listening one will be > killed automatically. > > Signed-off-by: Mike Frysinger > --- > v2 > - split the changes (robust and ncb) > > tools/netconsole | 12 +--- > 1 files changed, 9 insertions(+), 3 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Presidency: The greased pig in the field game of American politics. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] tools/netconsole: use ncb automatically if available
Dear Mike Frysinger, In message <1252513221-2524-2-git-send-email-vap...@gentoo.org> you wrote: > The standard netcat, while ubiquitous, doesn't handle broadcast udp packets > properly. The local ncb util does however. So if ncb can be located in > the standard locations, automatically use that instead. > > Signed-off-by: Mike Frysinger > --- > v2 > - split the changes > - search PATH rather than CWD > - update docs > > doc/README.NetConsole | 24 +++- > tools/netconsole | 17 ++--- > 2 files changed, 17 insertions(+), 24 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Our way is peace. -- Septimus, the Son Worshiper, "Bread and Circuses", stardate 4040.7. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] I found an error
Dear Minkyu Kang, In message <3fa5fd300909100724x18b2a8bdve0bd6e9fb7194...@mail.gmail.com> Sun Peng wrote: > > Recently I'm playing with u-boot and want it be able to boot from nand. > When I config u-boot to smdk6400, I found I can't get nand_spl with proper > size. It need to be pad to 4k to fit into the steping stone. > The final size of nand_spl is depend on the variable "PAD_TO": > > # PAD_TO used to generate a 4kByte binary needed for the > combined image > # -> PAD_TO = TEXT_BASE + 4096 > PAD_TO := $(shell expr $$[$(TEXT_BASE) + 4096]) > The lines above is in file: > u-boot-xxx/nand_spl//board/samsung/smdk6400/config.mk > Unfortunately the PAD_TO can not evaluate to the proper value when I run the > makefile. > I change the the line to below: >PAD_TO:= $(shell expr $(TEXT_BASE) + 4096) > then the whole build works OK. > > Is there any body think this is an issue ? Could you please be so kind and have a look at this? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "IBM uses what I like to call the 'hole-in-the-ground technique' to destroy the competition. IBM digs a big HOLE in the ground and covers it with leaves. It then puts a big POT OF GOLD nearby. Then it gives the call, 'Hey, look at all this gold, get over here fast.' As soon as the competitor approaches the pot, he falls into the pit" - John C. Dvorak ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v3] mpc8260: remove Ethernet node fixup to use generic FDT code.
Dear Marcel Ziswiler, In message <14622923.97201252669833688.javamail.serv...@perfora> you wrote: > Remove Ethernet node fixup from mgcoge and muas3001 boards and modify its > configs for the common mpc8260 code to use generic Ethernet fixup. > > Signed-off-by: Marcel Ziswiler > Tested-by: Heiko Schocher > --- > Changes since v1: > - Added Heiko's tested-by > Changes since v2: > - Re-based to origin/master > > board/keymile/mgcoge/mgcoge.c |5 - > board/muas3001/muas3001.c | 15 --- > include/configs/mgcoge.h |1 + > include/configs/muas3001.h|1 + > 4 files changed, 2 insertions(+), 20 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "The X11 source code style is ATROCIOUS and should not be used as a model." - Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx27ads: add support for iMX27ADS board from Freescale
Dear Alan Carvalho de Assis, In message <37367b3a0909151307x25a0d57dt9d708ac785ff2...@mail.gmail.com> you wrote: > > >> + write32 0xD8001010 0x0008 > > > > I would insert a comma (,) after the first argument to the macro. Didn't > > know it worked without. > > The same comment applies to the rest of this file. Don't know what the > > U-boot coding standard says about this though. > > Hmm, I think I based on other example. Need I to replace it? Yes, please. > >> + /* peripheral clock divider */ > >> + write32 PCDR0 0x120470C3/* FIXME*/ > >> + write32 PCDR1 0x03030303/* PERDIV1=08 @133 MHz */ > >> + /* PERDIV1=04 @266 MHz * > >> + * / > > > > The last line with '* /' looks a bit odd compated to the other comments. > > > > I will remove this extra space In this case it will be an incorrct multi-line comment that needs to 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: w...@denx.de Actual war is a very messy business. Very, very messy business. -- Kirk, "A Taste of Armageddon", stardate 3193.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] board/linkstation/ide.c: Fix compile warning
Dear Guennadi Liakhovetski, In message you wrote: > > > pci_read_config_dword (devbusfn, PCI_BASE_ADDRESS_0, > > - (u32 *) > > &ide_bus_offset[0]); > > - ide_bus_offset[0] &= 0xfffe; > > + &ide_bus_offset32); > > + ide_bus_offset[0] = ide_bus_offset32 & 0xfffe; > > ide_bus_offset[0] = pci_hose_bus_to_phys(&hose, > > ide_bus_offset[0] & > > 0xfffe, > > PCI_REGION_IO); > > Ok, yes, this looks much better now without casts, but - the double " & > 0xfffe" above seems completely redundant to me. I understand, that > that's not the problem you're fixing with this patch, and I will perfectly > understand if you refuse to mix these two fixes, but... Another thing - Ah, I see. Sorry I missed that. It's easy to fix. > why doesn't the compiler complain about exactly identical cast (ok, > almost) a couple of lines down for ide_bus_offset[1]? So, how about this Good question. Please post it on a gcc mailing ist and report back the results you get. > diff instead (only compile-tested) (not for submission yet, so, no Sob's, > no patch header): Hm, this is much more intrusive - do you have a way to test in on real hardware? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If God wanted me to touch my toes, he'd have put them on my knees. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Subject: [PATCH v3] mx27ads: add support for iMX27ADS board from Freescale
This patch adds support to iMX27ADS development board. This board has 128MB RAM, 32MB NOR Flash and 128MB NAND Flash. Currently only booting from NOR is supported. Signed-off-by: Alan Carvalho de Assis --- MAINTAINERS |3 + MAKEALL |1 + Makefile|3 + board/freescale/mx27ads/Makefile| 51 board/freescale/mx27ads/config.mk |1 + board/freescale/mx27ads/lowlevel_init.S | 127 +++ board/freescale/mx27ads/mx27ads.c | 93 ++ board/freescale/mx27ads/u-boot.lds | 56 + include/configs/mx27ads.h | 202 +++ 9 files changed, 537 insertions(+), 0 deletions(-) create mode 100644 board/freescale/mx27ads/Makefile create mode 100644 board/freescale/mx27ads/config.mk create mode 100644 board/freescale/mx27ads/lowlevel_init.S create mode 100644 board/freescale/mx27ads/mx27ads.c create mode 100644 board/freescale/mx27ads/u-boot.lds create mode 100644 include/configs/mx27ads.h diff --git a/MAINTAINERS b/MAINTAINERS index e9db278..7ff3160 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -512,6 +512,9 @@ Unknown / orphaned boards: # Board CPU # # +Alan Carvalho de Assis + mx27ads i.MX27 + Rowel Atienza armadillo ARM720T diff --git a/MAKEALL b/MAKEALL index f0ed8ea..56b4446 100755 --- a/MAKEALL +++ b/MAKEALL @@ -525,6 +525,7 @@ LIST_ARM9=" \ mv88f6281gtw_ge \ mx1ads \ mx1fs2 \ + mx27ads \ netstar \ nhk8815 \ nhk8815_onenand \ diff --git a/Makefile b/Makefile index 9764cea..4f2dcef 100644 --- a/Makefile +++ b/Makefile @@ -2965,6 +2965,9 @@ davinci_dm365evm_config : unconfig imx27lite_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs imx27lite logicpd mx27 +mx27ads_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs mx27ads freescale mx27 + lpd7a400_config \ lpd7a404_config: unconfig @$(MKCONFIG) $(@:_config=) arm lh7a40x lpd7a40x diff --git a/board/freescale/mx27ads/Makefile b/board/freescale/mx27ads/Makefile new file mode 100644 index 000..d142a9e --- /dev/null +++ b/board/freescale/mx27ads/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2000-2004 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := mx27ads.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# + diff --git a/board/freescale/mx27ads/config.mk b/board/freescale/mx27ads/config.mk new file mode 100644 index 000..a2e7768 --- /dev/null +++ b/board/freescale/mx27ads/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0xA7F0 diff --git a/board/freescale/mx27ads/lowlevel_init.S b/board/freescale/mx27ads/lowlevel_init.S new file mode 100644 index 000..dc62a93 --- /dev/null +++ b/board/freescale/mx27ads/lowlevel_init.S @@ -0,0 +1,127 @@ +/* + * Copyright (C) 2008, Guennadi Liakhovetski + * + * 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 + * MERCHAN
Re: [U-Boot] [PATCH 2/2 v2] Blackfin: tweak embedded env config option
On Tuesday 15 September 2009 16:49:42 Wolfgang Denk wrote: > Mike Frysinger wrote: > > Use the common config option for extracting the environment for embedding > > into LDR files. > ... > > $(obj)u-boot.ldr: $(obj)u-boot > > - $(obj)tools/envcrc --binary > $(obj)env-ldr.o > > + $(CREATE_LDR_ENV) > > $(LDR) -T $(CONFIG_BFIN_CPU) -c $@ $< $(LDR_FLAGS) > > This is all BF specific stuff, right? Maybe we should move this into > some BF Makefile, then, instead of adding more and more references to > magic variables that have no meaning anywhere except for BF. if you're talking about the %.ldr target, then yes, it is only for Blackfin systems. it isnt the only target-specific top level which is why it's there now, but that doesnt mean it has to stay there (as well as the other cruft). ive already looked at moving this to the Blackfin specific config.mk, but it would require adding dummy "all" targets early on in the top level Makefile and one or two subdir Makefiles. i didnt feel like dealing with people complaining about this. although if we created a new lib_$(ARCH)/targets.mk, we could push all arch-specific crap there (like all the boards config targets), and only the top level Makefile would include it. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] env: only build env_embedded and envcrc when needed
On Tuesday 15 September 2009 16:44:23 Wolfgang Denk wrote: > Mike Frysinger wrote: > > > > > Also, I see no documentation for it? > > > > > > > > guessing you want it added to the top level README ? > > > > > > Indeed. What's the name supposed to mean? "The envrionment is > > > embedded custom" sounds strange to me. > > > > i saw it as "custom embedding of the environment". the only thing it > > does is enable the envcrc binary. i thought of using "CONFIG_ENVCRC", > > but it seemed a little too short. > > CONFIG_ENABLE_ENVCRC ? CONFIG_BUILD_ENVCRC ? the name doesnt really matter to me. if you're fine with CONFIG_BUILD_ENVCRC, i'll use that in common code and keep the CONFIG_ENV_IS_EMBEDDED_CUSTOM in the Blackfin specific code. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] No NAND device found!!! Freescale MPC8544+SAMSUNG 1GB Nand Flash , please help!
Hi all,
Correction, the nand flash is K9F8G08U0M.
Please help
duckycool wrote:
>
> http://www.nabble.com/file/p25455541/nand_error.bmp nand_error.bmp Hi
> all,
> I can't do READID with nand_get_flash_type in the nand_base.c
> What I get is an error "No NAND device found!!!"
> My board is freescale mpc8544 with samsung K9K8G08U0A, the device is
> supposed {NAND 1GiB 3,3V 8-bit", 0xD3, 0, 1024, 0, LP_OPTIONS} .
>
> What I did is copy the nand.c from /board/tqc/tqm85xx/nand.c into
> /board/freescale/mpc8544ds
> Add #define CONFIG_CMD_NAND into MPC8544DS.h, setup TLB/LAW/BR/OR for
> nand flash.
> Add RAM array of upm into /board/.../nand.c.
>
> When booting, I can get the chip select signal put low with scope.
> Trace the code, it get both dev_id and tmp_id 0x00ff.
>
> Per the /driver/mtd/nand/nand_base.c , /driver/mtd/nand/fsl_upm.c , and
> /board/.../nand.c
> I break down the upm operation into the upm control(mamr, mar,
> IO_ADDR_R, IO_ADDR_W)
> And then, I tried the low level register control under CodeWarrior
> command window, it's still failed.
>
> As below: (CCSRBR = 0xe000 , nand_flash_base = 0xff00)
> change 0xe0005070 0x3008 (OP=11, pattern_offset=8)
> change 0xe0005068 0x9000
> change 0xff00 0x0
> change 0xe0005070 0x0
> change 0xe0005070 0x3010
> change 0xe0005068 0x
> change 0xff00 0x0
> change 0xe0005070 0x0
> change 0xe0005070 0x3008
> change 0xe0005068 0x
> change 0xff00 0x0
> change 0xe0005070 0x0
> display 0xff00
>
> I don't know why?
> Any MARCO I should add ?
> Or any special operation should I add into nand_base.c ?
> Please help, thank you.
>
--
View this message in context:
http://www.nabble.com/No-NAND-device-found%21%21%21-Freescale-MPC8544%2BSAMSUNG-1GB-Nand-Flash-%2C-please-help%21-tp25455541p25462282.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Streamlined mpc512x fixed_sdram init sequence allowing for
Dear Martha M Stan,
In message <12526727172732-git-send-email-mm...@silicontkx.com> you wrote:
> Signed-off-by: Martha M Stan
> ---
> board/davedenx/aria/aria.c |2 +-
> board/esd/mecp5123/mecp5123.c |2 +-
> board/freescale/mpc5121ads/mpc5121ads.c |2 +-
> cpu/mpc512x/fixed_sdram.c | 94
> ---
> include/asm-ppc/immap_512x.h|5 +-
> include/asm-ppc/mpc512x.h |2 +-
> include/configs/aria.h |6 +--
> include/configs/mecp5123.h |5 +-
> include/configs/mpc5121ads.h|6 +--
> 9 files changed, 72 insertions(+), 52 deletions(-)
...
> diff --git a/cpu/mpc512x/fixed_sdram.c b/cpu/mpc512x/fixed_sdram.c
> index d906903..eb0811c 100644
> --- a/cpu/mpc512x/fixed_sdram.c
> +++ b/cpu/mpc512x/fixed_sdram.c
> @@ -20,23 +20,73 @@
> * MA 02111-1307 USA
> *
> */
> -
> +#define DEBUG 0xff
Please don't do this in released code.
> #include
> #include
> #include
>
> +/* config settings in order of the 4 mddrc cfg registers */
> +u32 default_mddrc_config[4] = {
> + CONFIG_SYS_MDDRC_SYS_CFG,
> + CONFIG_SYS_MDDRC_TIME_CFG0,
> + CONFIG_SYS_MDDRC_TIME_CFG1,
> + CONFIG_SYS_MDDRC_TIME_CFG2
> +};
As you are playing tricks with the Refresh and Run bits below, this
needs a comment that explains what the values mean, and how to set up
this list.
> +u32 default_init_sequence[] = {
Please add a comment what all this means.
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
...
> + CONFIG_SYS_MICRON_PCHG_ALL,
> + CONFIG_SYS_MICRON_NOP
> +};
> +
> /*
> * fixed sdram init:
> * The board doesn't use memory modules that have serial presence
> * detect or similar mechanism for discovery of the DRAM settings
> */
> -long int fixed_sdram(void)
> +long int fixed_sdram(u32 *mddrc_config, u32 *dram_init_sequence, int
> seq_table_size)
Line too long.
> @@ -46,7 +96,7 @@ long int fixed_sdram(void)
> sync_law(&im->sysconf.ddrlaw.ar);
>
> /* Enable DDR */
> - out_be32(&im->mddrc.ddr_sys_config, CONFIG_SYS_MDDRC_SYS_CFG_EN);
> + out_be32(&im->mddrc.ddr_sys_config, MDDRC_SYS_CFG_EN);
Please stick with the CONFIG_SYS_ name.
> /* Initialize DDR Priority Manager */
> out_be32(&im->mddrc.prioman_config1, CONFIG_SYS_MDDRCGRP_PM_CFG1);
> @@ -74,40 +124,18 @@ long int fixed_sdram(void)
> out_be32(&im->mddrc.lut_table4_alternate_lower,
> CONFIG_SYS_MDDRCGRP_LUT4_AL);
>
> /* Initialize MDDRC */
> - out_be32(&im->mddrc.ddr_sys_config, CONFIG_SYS_MDDRC_SYS_CFG);
> - out_be32(&im->mddrc.ddr_time_config0, CONFIG_SYS_MDDRC_TIME_CFG0);
> - out_be32(&im->mddrc.ddr_time_config1, CONFIG_SYS_MDDRC_TIME_CFG1);
> - out_be32(&im->mddrc.ddr_time_config2, CONFIG_SYS_MDDRC_TIME_CFG2);
> + out_be32(&im->mddrc.ddr_sys_config, mddrc_config[0]);
> + out_be32(&im->mddrc.ddr_time_config0, mddrc_config[1] &
> MDDRC_TIME_CFG0_RFRSH0);
> + out_be32(&im->mddrc.ddr_time_config1, mddrc_config[2]);
> + out_be32(&im->mddrc.ddr_time_config2, mddrc_config[3]);
Why is the " & MDDRC_TIME_CFG0_RFRSH0" needed? Please comment.
> /* Initialize DDR */
...
> + for (i = 0; i < seq_table_size; i++)
> + out_be32(&im->mddrc.ddr_command, dram_init_sequence[i]);
>
> /* Start MDDRC */
> - out_be32(&im->mddrc.ddr_time_config0, CONFIG_SYS_MDDRC_TIME_CFG0_RUN);
> - out_be32(&im->mddrc.ddr_sys_config, CONFIG_SYS_MDDRC_SYS_CFG_RUN);
> + out_be32(&im->mddrc.ddr_time_config0, mddrc_config[1]);
> + out_be32(&im->mddrc.ddr_sys_config, mddrc_config[0] &
> MDDRC_SYS_CFG_RUN);
Please add comment that explains the "& MDDRC_SYS_CFG_RUN" part.
> diff --git a/include/asm-ppc/immap_512x.h b/include/asm-ppc/immap_512x.h
> index 24e6c69..13d3d0e 100644
> --- a/include/asm-ppc/immap_512x.h
> +++ b/include/asm-ppc/immap_512x.h
> @@ -45,7 +45,6 @@
> #define IMMRBAR_BASE_ADDR0xFFF0 /* Base address mask */
> #define IMMRBAR_RES ~(IMMRBAR_BASE_ADDR)
>
> -
> #ifndef __ASSEMBLY__
> typedef struct law512x {
> u32 bar;/* Base Addr Register */
> @@ -341,6 +340,10 @@ typedef struct ddr512x {
> u32 res2[0x3AD];
> } ddr512x_t;
>
> +/* MDDRC SYS CFG and Timing CFG0 Registers */
> +#define MDDRC_SYS_CFG_EN 0xF000
> +#define MDDRC_SYS_CFG_RUN~(0x01 << 28)
> +#define MDDRC_TIME_CFG0_RFRSH0 0x
I find this inverse logic confusing. I recommend to use direct values
here, and "& ~FOO" above, then everybody sees what that means.
> diff --git a/include/asm-ppc/mpc512x.h b/include/asm-ppc/mpc512x.h
> index 20456f5..6a65492 100644
> --- a/include/asm-ppc/mpc512x.h
> +++ b/include/asm-ppc/mpc512x.h
> @@ -50,7 +50,7 @@ static inline void sync_law(volatile void *addr)
> /*
> * Prototypes
> */
> -extern long int fixed_sdram(void);
> +extern long int fixed_sdram(u32 *mddrc_config, u32 *dram_init_sequence, int
> se
[U-Boot] Flashing images bigger than ram
Is there a standard way to have U-Boot flash really large images? I want to setup rootfs flashing from U-Boot but this requires flashing an image that is bigger than the ram of my system. I thought about breaking the image into chunks, but when flashing to NAND with bad blocks it is difficult to handle skipping the bad blocks. I know I could make this happen with a custom command added to U-Boot but I was wondering if someone else had solved the problem already. My hardware: OMAP3530, 128MB Ram, 256MB NAND. Trying to flash from MMC (fat, or ext2) to NAND. Thanks for any help. Ben Goska gos...@onid.oregonstate.edu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add Elpida Memory Configuration to mpc5121ads Boards
Dear Martha M Stan,
In message <1252706807954-git-send-email-mm...@silicontkx.com> you wrote:
> Signed-off-by: Martha M Stan
> ---
> board/freescale/mpc5121ads/mpc5121ads.c | 97
> ++-
> include/configs/mpc5121ads.h| 39 -
> 2 files changed, 132 insertions(+), 4 deletions(-)
...
> + u32 elpida_init_sequence[] = {
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_PCHG_ALL,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_RFSH,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_RFSH,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_EM2,
> + CONFIG_SYS_MICRON_EM3,
> + CONFIG_SYS_MICRON_EN_DLL,
> + CONFIG_SYS_ELPIDA_RES_DLL,
> + CONFIG_SYS_MICRON_PCHG_ALL,
> + CONFIG_SYS_MICRON_RFSH,
> + CONFIG_SYS_MICRON_RFSH,
> + CONFIG_SYS_MICRON_RFSH,
> + CONFIG_SYS_ELPIDA_INIT_DEV_OP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_OCD_DEFAULT,
> + CONFIG_SYS_ELPIDA_OCD_EXIT,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP,
> + CONFIG_SYS_MICRON_NOP
> + };
This seems wrong to me. Elpida settings should use CONFIG_SYS_ELPIDA_*
variables only, should't it?
> - msize = fixed_sdram(NULL, NULL, 0);
> + u32 msize = 0;
> + if (is_micron())
> + msize = fixed_sdram(NULL, NULL, 0);
> + else
> + msize = fixed_sdram(elpida_mddrc_config,
> + elpida_init_sequence,
> + sizeof(elpida_init_sequence)/sizeof(u32));
Braces needed for multiline statement.
> diff --git a/include/configs/mpc5121ads.h b/include/configs/mpc5121ads.h
> index d96e7f5..fda63dd 100644
> --- a/include/configs/mpc5121ads.h
> +++ b/include/configs/mpc5121ads.h
> @@ -141,14 +141,49 @@
> #endif
> #define CONFIG_SYS_MDDRC_TIME_CFG0 0x06183D2E
>
> +#define CONFIG_SYS_MDDRC_SYS_CFG_ELPIDA 0xFA802B00
> +#define CONFIG_SYS_MDDRC_TIME_CFG1_ELPIDA0x690e1189
> +#define CONFIG_SYS_MDDRC_TIME_CFG2_ELPIDA0x35310864
> +
> +/* MICRON Configuration and Commands
> + * These also work for Elpida unless explicitly overwritten
> + */
Incorrect multiline comment style.
For clearness, I'd prefer to see separate settings.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
There is a time in the tides of men, Which, taken at its flood, leads
on to success. On the other hand, don't count on it. - T. K. Lawson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] LCRR setting on XPEDITE5370 & XPEDITE5200
Peter, I see you guys set LCRR in the config.h. You are using LCRR_CLKDIV_4. Do you think this means clk/4? (I ask because the defines aren't correct, and wasn't sure about your expectation). - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Flashing images bigger than ram
Ben Goska wrote: > Is there a standard way to have U-Boot flash really large images? I > want to setup rootfs flashing from U-Boot but this requires flashing > an image that is bigger than the ram of my system. I thought about > breaking the image into chunks, but when flashing to NAND with bad > blocks it is difficult to handle skipping the bad blocks. Have you looked into ubi? I'm not too familiar with it, but my understanding is that it has a better way of dealing with bad blocks. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Flashing images bigger than ram
Hi, On Wed, Sep 16, 2009 at 6:39 AM, Ben Goska wrote: > Is there a standard way to have U-Boot flash really large images? I > want to setup rootfs flashing from U-Boot but this requires flashing > an image that is bigger than the ram of my system. I thought about > breaking the image into chunks, but when flashing to NAND with bad > blocks it is difficult to handle skipping the bad blocks. > > I know I could make this happen with a custom command added to U-Boot > but I was wondering if someone else had solved the problem already. > > My hardware: OMAP3530, 128MB Ram, 256MB NAND. > Trying to flash from MMC (fat, or ext2) to NAND. > Please see the common/cmd_onenand.c First it got the 32MiB data from USB or others. and then write it's data to OneNAND. Of course if it meets the bad blocks, just skip it and write again. I called it skip write method. Next time it adjust the start offset. of course upper layer don't know it. Upper layer assume it write it exactly it sent. In read side it's similar. If it encounters the bad block. it also skip and read again. (skip read). With this method. we can program flash even though we can't enough memory. you can see the code. it's better to understand. Thank you, Kyungmin Park ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc512x. Micron nand flash needs a reset before a read command is issued.
Micron nand flash needs a reset before a read command is issued. The current mpc5121_nfc driver ignores the reset command. --- drivers/mtd/nand/mpc5121_nfc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/mpc5121_nfc.c b/drivers/mtd/nand/mpc5121_nfc.c index 856cb36..7fd8a35 100644 --- a/drivers/mtd/nand/mpc5121_nfc.c +++ b/drivers/mtd/nand/mpc5121_nfc.c @@ -334,6 +334,7 @@ static void mpc5121_nfc_command(struct mtd_info *mtd, unsigned command, case NAND_CMD_ERASE2: case NAND_CMD_READID: case NAND_CMD_STATUS: + case NAND_CMD_RESET: break; default: -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] I found an error
Dear sun peng 2009/9/16 Wolfgang Denk : > Dear Minkyu Kang, > > In message <3fa5fd300909100724x18b2a8bdve0bd6e9fb7194...@mail.gmail.com> Sun > Peng wrote: >> >> Recently I'm playing with u-boot and want it be able to boot from nand. >> When I config u-boot to smdk6400, I found I can't get nand_spl with proper >> size. It need to be pad to 4k to fit into the steping stone. >> The final size of nand_spl is depend on the variable "PAD_TO": >> >> # PAD_TO used to generate a 4kByte binary needed for the >> combined image >> # -> PAD_TO = TEXT_BASE + 4096 >> PAD_TO := $(shell expr $$[$(TEXT_BASE) + 4096]) >> The lines above is in file: >> u-boot-xxx/nand_spl//board/samsung/smdk6400/config.mk >> Unfortunately the PAD_TO can not evaluate to the proper value when I run the >> makefile. >> I change the the line to below: >> PAD_TO := $(shell expr $(TEXT_BASE) + 4096) >> then the whole build works OK. >> >> Is there any body think this is an issue ? > > Could you please be so kind and have a look at this? > > Thanks in advance. > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > "IBM uses what I like to call the 'hole-in-the-ground technique' to > destroy the competition. IBM digs a big HOLE in the ground and > covers it with leaves. It then puts a big POT OF GOLD nearby. Then it > gives the call, 'Hey, look at all this gold, get over here fast.' As > soon as the competitor approaches the pot, he falls into the pit" > - John C. Dvorak > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > I saw correct PAD_TO value without modification. ccache /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-objcopy --gap-fill=0xff --pad-to=4096 -O binary /home/share/Work/u-boot-work/nand_spl/u-boot-spl /home/share/Work/u-boot-work/nand_spl/u-boot-spl-16k.bin and I've got 4Kbyte binary also. -rwxr-xr-x 1 prom prom 4096 2009-09-16 10:21 u-boot-spl-16k.bin I think there have no problem. If it's not your problem, please explain in more detail. Thanks. Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] smc91111_eeprom: get working with net multi conversion
This should be squashed into the pending:
Convert SMC9 Ethernet driver to CONFIG_NET_MULTI API
The changes to the eeprom were incomplete, and the new version needs
slightly different handling on the BF533 boards that share flash.
Signed-off-by: Mike Frysinger
---
examples/standalone/smc9_eeprom.c |4 +++-
include/configs/bf533-ezkit.h |5 +++--
include/configs/bf533-stamp.h |5 +++--
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/examples/standalone/smc9_eeprom.c
b/examples/standalone/smc9_eeprom.c
index a38cc4d..89afc87 100644
--- a/examples/standalone/smc9_eeprom.c
+++ b/examples/standalone/smc9_eeprom.c
@@ -29,9 +29,11 @@
#include
#include
+/* the smc9.h gets base addr through eth_device' iobase */
+struct eth_device { unsigned long iobase; };
#include "../drivers/net/smc9.h"
-#ifdef CONFIG_DRIVER_SMC9
+#ifdef CONFIG_SMC9
#ifndef SMC9_EEPROM_INIT
# define SMC9_EEPROM_INIT()
diff --git a/include/configs/bf533-ezkit.h b/include/configs/bf533-ezkit.h
index 8f23f1d..cee33f2 100644
--- a/include/configs/bf533-ezkit.h
+++ b/include/configs/bf533-ezkit.h
@@ -70,8 +70,9 @@
#define CONFIG_SMC9_BASE 0x20310300
#define SMC9_EEPROM_INIT() \
do { \
- *pFIO_DIR |= PF1; \
- *pFIO_FLAG_S = PF1; \
+ bfin_write_FIO_DIR(bfin_read_FIO_DIR() | PF1 | PF0); \
+ bfin_write_FIO_FLAG_C(PF1); \
+ bfin_write_FIO_FLAG_S(PF0); \
SSYNC(); \
} while (0)
#define CONFIG_HOSTNAMEbf533-ezkit
diff --git a/include/configs/bf533-stamp.h b/include/configs/bf533-stamp.h
index 56fec53..573d4e5 100644
--- a/include/configs/bf533-stamp.h
+++ b/include/configs/bf533-stamp.h
@@ -65,8 +65,9 @@
#define CONFIG_SMC9_BASE 0x20300300
#define SMC9_EEPROM_INIT() \
do { \
- *pFIO_DIR |= PF1; \
- *pFIO_FLAG_S = PF1; \
+ bfin_write_FIO_DIR(bfin_read_FIO_DIR() | PF1 | PF0); \
+ bfin_write_FIO_FLAG_C(PF1); \
+ bfin_write_FIO_FLAG_S(PF0); \
SSYNC(); \
} while (0)
#define CONFIG_HOSTNAMEbf533-stamp
--
1.6.5.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] LCRR setting on XPEDITE5370 & XPEDITE5200
Hi Kumar, > I see you guys set LCRR in the config.h. You are using > LCRR_CLKDIV_4. Do you think this means clk/4? (I ask because the > defines aren't correct, and wasn't sure about your expectation). I faintly remember punching the numbers for LCRR a while back, then blindly replacing the calculated LCRR value with the LCRR_* defines from fsl_lbc.h. So clk/8 is intended, but I didn't register that LCRR_CLKDIV_4 was a misnomer at the time. Thanks for checking, I'll send a patch when I have some free time unless someone beats me to it. Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] LCRR setting on XPEDITE5370 & XPEDITE5200
On Sep 15, 2009, at 10:04 PM, Peter Tyser wrote: > Hi Kumar, > >> I see you guys set LCRR in the config.h. You are using >> LCRR_CLKDIV_4. Do you think this means clk/4? (I ask because the >> defines aren't correct, and wasn't sure about your expectation). > > I faintly remember punching the numbers for LCRR a while back, then > blindly replacing the calculated LCRR value with the LCRR_* defines > from > fsl_lbc.h. So clk/8 is intended, but I didn't register that > LCRR_CLKDIV_4 was a misnomer at the time. > > Thanks for checking, I'll send a patch when I have some free time > unless > someone beats me to it. I'll fix it up, just wanted to make sure which way you expected things. (Will expect your ack :) - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Disable all async interrupt sources when we boot
On Sep 11, 2009, at 3:29 PM, Kumar Gala wrote: > We should make sure to clear MSR[ME, CE, DE] when we boot an OS image > since we have changed the exception vectors and the OSes vectors might > not be setup we should avoid async interrupts at all costs. > > Signed-off-by: Kumar Gala > --- > cpu/mpc85xx/cpu_init.c | 11 +++ > 1 files changed, 11 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ppc/85xx: Change cpu_init_early_f so we can use with NAND SPL
On Sep 11, 2009, at 2:55 PM, Kumar Gala wrote: > Use write_tlb and don't use memset so we can use the same code for > cpu_init_early_f between NAND SPL and not. > > Signed-off-by: Kumar Gala > --- > cpu/mpc85xx/cpu_init.c | 34 +- > 1 files changed, 25 insertions(+), 9 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ppc/85xx: Split out cpu_init_early into its own file for NAND_SPL
On Sep 11, 2009, at 2:55 PM, Kumar Gala wrote: > By pulling out cpu_init_early we can build just it and not all of > cpu_init for NAND_SPL. > > Signed-off-by: Kumar Gala > --- > cpu/mpc85xx/Makefile |1 + > cpu/mpc85xx/cpu_init.c | 51 > cpu/mpc85xx/cpu_init_early.c | 76 + > + > 3 files changed, 77 insertions(+), 51 deletions(-) > create mode 100644 cpu/mpc85xx/cpu_init_early.c applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] ppc/85xx: add boot from NAND/eSDHC/eSPI support
On Sep 11, 2009, at 1:02 PM, Kumar Gala wrote: > From: Mingkai Hu > > The MPC8536E is capable of booting form NAND/eSDHC/eSPI, this patch > implements these three bootup methods in a unified way - all of these > use the general cpu/mpc85xx/start.S, and load the main image to L2SRAM > which lets us use the SPD to initialize the SDRAM. > > For all three bootup methods, the bootup process can be divided into > two > stages: the first stage will initialize the corresponding controller, > configure the L2SRAM, then copy the second stage image to L2SRAM and > jump to it. The second stage image is just like the general U-Boot > image > to configure all the hardware and boot up to U-Boot command line. > > When boot from NAND, the eLBC controller will first load the first > stage > image to internal 4K RAM buffer because it's also stored on the NAND > flash. The first stage image, also call 4K NADN loader, will > initialize > the L2SRAM, load the second stage image to L2SRAM and jump to it. > The 4K > NAND loader's code comes from the corresponding nand_spl directory, > along > with the code twisted by CONFIG_NAND_SPL. > > When boot from eSDHC/eSPI, there's no such a first stage image because > the CPU ROM code does the same work. It will initialize the L2SRAM > according to the config addr/word pairs on the fixed address and > initialize the eSDHC/eSPI controller, then load the second stage image > to L2SRAM and jump to it. > > The macro CONFIG_SYS_RAMBOOT is used to control the code to produce > the > second stage image for all different bootup methods. It's set in the > board config file when one of the bootup methods above is selected. > > Signed-off-by: Mingkai Hu > Signed-off-by: Kumar Gala > --- > * Merged in changes from other patch into u-boot-nand.lds > * Fixed up and simplified tlb.c changes > > - k applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Move code around to prep for NAND_SPL
On Sep 11, 2009, at 12:54 PM, Kumar Gala wrote: > If we move some of the functions in tlb.c around we need less > ifdefs. The first stage loader just needs invalidate_tlb and > init_tlbs. > > Signed-off-by: Kumar Gala > --- > cpu/mpc85xx/tlb.c | 46 ++ > +--- > 1 files changed, 23 insertions(+), 23 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] ppc/85xx: Repack tlb_table to save space
On Sep 11, 2009, at 12:27 PM, Kumar Gala wrote: > We can pack the initial tlb_table in MAS register format and use > write_tlb to set things up. This savings can be helpful for NAND > style first stage boot loaders. > > Signed-off-by: Kumar Gala > --- > * Use new FSL_BOOKE_MAS7 macro applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Disable all async interrupt sources when we boot
On Sep 11, 2009, at 3:29 PM, Kumar Gala wrote: > We should make sure to clear MSR[ME, CE, DE] when we boot an OS image > since we have changed the exception vectors and the OSes vectors might > not be setup we should avoid async interrupts at all costs. > > Signed-off-by: Kumar Gala > --- > cpu/mpc85xx/cpu_init.c | 11 +++ > 1 files changed, 11 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] ppc/85xx: Introduce low level write_tlb function
On Sep 11, 2009, at 12:27 PM, Kumar Gala wrote: > Factor out the code we use to actually write a tlb entry. > > set_tlb is a logical view of the TLB while write_tlb is a low level > matching the MAS registers. > > Signed-off-by: Kumar Gala > --- > * Added update to copyright > * introduced FSL_BOOKE_MAS7 macro applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx
The following changes since commit 3ca55bce9c8bf00df06a20487fafc16fa2f8084b: Marcel Ziswiler (1): mpc8260: remove Ethernet node fixup to use generic FDT code. are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Kumar Gala (7): ppc/8xxx: Misc DDR related fixes ppc/85xx: Introduce low level write_tlb function ppc/85xx: Repack tlb_table to save space ppc/85xx: Move code around to prep for NAND_SPL ppc/85xx: Change cpu_init_early_f so we can use with NAND SPL ppc/85xx: Split out cpu_init_early into its own file for NAND_SPL ppc/85xx: Disable all async interrupt sources when we boot Mingkai Hu (2): ppc/85xx: add boot from NAND/eSDHC/eSPI support NAND boot: change NAND loader's relocate SP to CONFIG param Roy Zang (1): ppc/85xx: Enable usb ehci support for p2020ds board Scott Wood (3): ppc/85xx: Don't enable interrupts before we're ready ppc/85xx: Ensure that MAS8 is zero when writing TLB entries. ppc/85xx: Remove some bogus code from external interrupt handler. board/freescale/mpc8313erdb/mpc8313erdb.c |2 +- board/sheldon/simpc8313/simpc8313.c |2 +- cpu/mpc85xx/Makefile |1 + cpu/mpc85xx/cpu_init.c| 67 +++ cpu/mpc85xx/cpu_init_early.c | 76 cpu/mpc85xx/start.S | 55 +++- cpu/mpc85xx/tlb.c | 60 ++--- cpu/mpc85xx/traps.c |9 +-- cpu/mpc85xx/u-boot-nand.lds | 138 + cpu/mpc8xxx/ddr/ctrl_regs.c | 10 +- cpu/mpc8xxx/ddr/ddr3_dimm_params.c|4 +- drivers/misc/fsl_law.c|2 + include/asm-ppc/mmu.h | 25 +++--- include/asm-ppc/processor.h |2 + include/configs/MPC8313ERDB.h |1 + include/configs/P2020DS.h |9 ++ include/configs/SIMPC8313.h |1 + 17 files changed, 364 insertions(+), 100 deletions(-) create mode 100644 cpu/mpc85xx/cpu_init_early.c create mode 100644 cpu/mpc85xx/u-boot-nand.lds ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc/85xx: Fix LCRR_CLKDIV defines
For some reason the CLKDIV field varies between SoC in how it interprets the bit values. All 83xx and early (e500v1) PQ3 devices support: clk/2: CLKDIV = 2 clk/4: CLKDIV = 4 clk/8: CLKDIV = 8 Newer PQ3 (e500v2) and MPC86xx support: clk/4: CLKDIV = 2 clk/8: CLKDIV = 4 clk/16: CLKDIV = 8 Ensure that the MPC86xx and MPC85xx still get the same behavior and make the the defines reflect their logical view (not the value of the field). Signed-off-by: Kumar Gala --- include/asm-ppc/fsl_lbc.h |8 include/configs/XPEDITE5170.h |2 +- include/configs/XPEDITE5200.h |2 +- include/configs/XPEDITE5370.h |2 +- 4 files changed, 11 insertions(+), 3 deletions(-) diff --git a/include/asm-ppc/fsl_lbc.h b/include/asm-ppc/fsl_lbc.h index a28082e..08d31e1 100644 --- a/include/asm-ppc/fsl_lbc.h +++ b/include/asm-ppc/fsl_lbc.h @@ -311,9 +311,17 @@ */ #define LCRR_CLKDIV0x001F #define LCRR_CLKDIV_SHIFT 0 +#if defined(CONFIG_MPC83xx) || defined (CONFIG_MPC8540) || \ +defined(CONFIG_MPC8541) || defined (CONFIG_MPC8555) || \ +defined(CONFIG_MPC8560) #define LCRR_CLKDIV_2 0x0002 #define LCRR_CLKDIV_4 0x0004 #define LCRR_CLKDIV_8 0x0008 +#else +#define LCRR_CLKDIV_4 0x0002 +#define LCRR_CLKDIV_8 0x0004 +#define LCRR_CLKDIV_16 0x0008 +#endif /* LTEDR - Transfer Error Check Disable Register */ diff --git a/include/configs/XPEDITE5170.h b/include/configs/XPEDITE5170.h index 242466a..30642cd 100644 --- a/include/configs/XPEDITE5170.h +++ b/include/configs/XPEDITE5170.h @@ -122,7 +122,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); * 0xf800_ 0x_ NOR Flash 1 128M non-cacheable */ -#define CONFIG_SYS_LBC_LCRR(LCRR_CLKDIV_2 | LCRR_EADC_3) +#define CONFIG_SYS_LBC_LCRR(LCRR_CLKDIV_4 | LCRR_EADC_3) /* * NAND flash configuration diff --git a/include/configs/XPEDITE5200.h b/include/configs/XPEDITE5200.h index deda208..d79231b 100644 --- a/include/configs/XPEDITE5200.h +++ b/include/configs/XPEDITE5200.h @@ -103,7 +103,7 @@ * 0xfc00_ 0x_ NOR Flash 1 64M non-cacheable */ -#define CONFIG_SYS_LBC_LCRR(LCRR_CLKDIV_4 | LCRR_EADC_3) +#define CONFIG_SYS_LBC_LCRR(LCRR_CLKDIV_8 | LCRR_EADC_3) /* * NAND flash configuration diff --git a/include/configs/XPEDITE5370.h b/include/configs/XPEDITE5370.h index 3c58ebe..65e1afd 100644 --- a/include/configs/XPEDITE5370.h +++ b/include/configs/XPEDITE5370.h @@ -116,7 +116,7 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy); * 0xf800_ 0x_ NOR Flash 1 128M non-cacheable */ -#define CONFIG_SYS_LBC_LCRR(LCRR_CLKDIV_4 | LCRR_EADC_3) +#define CONFIG_SYS_LBC_LCRR(LCRR_CLKDIV_8 | LCRR_EADC_3) /* * NAND flash configuration -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx
Hello Kumar, On Tue, Sep 15, 2009 at 10:20:01PM -0500, Kumar Gala wrote: > The following changes since commit 3ca55bce9c8bf00df06a20487fafc16fa2f8084b: > Marcel Ziswiler (1): > mpc8260: remove Ethernet node fixup to use generic FDT code. > > are available in the git repository at: > > git://git.denx.de/u-boot-mpc85xx.git master What about these patches (MPC8569)? http://lists.denx.de/pipermail/u-boot/2009-August/thread.html#58930 Thanks! -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Fix LCRR_CLKDIV defines
On Tue, 2009-09-15 at 22:26 -0500, Kumar Gala wrote: > For some reason the CLKDIV field varies between SoC in how it interprets > the bit values. > > All 83xx and early (e500v1) PQ3 devices support: > clk/2: CLKDIV = 2 > clk/4: CLKDIV = 4 > clk/8: CLKDIV = 8 > > Newer PQ3 (e500v2) and MPC86xx support: > clk/4: CLKDIV = 2 > clk/8: CLKDIV = 4 > clk/16: CLKDIV = 8 > > Ensure that the MPC86xx and MPC85xx still get the same behavior and make > the the defines reflect their logical view (not the value of the field). > > Signed-off-by: Kumar Gala Acked-by: Peter Tyser Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Fix LCRR_CLKDIV defines
On Sep 15, 2009, at 10:32 PM, Peter Tyser wrote: > On Tue, 2009-09-15 at 22:26 -0500, Kumar Gala wrote: >> For some reason the CLKDIV field varies between SoC in how it >> interprets >> the bit values. >> >> All 83xx and early (e500v1) PQ3 devices support: >> clk/2: CLKDIV = 2 >> clk/4: CLKDIV = 4 >> clk/8: CLKDIV = 8 >> >> Newer PQ3 (e500v2) and MPC86xx support: >> clk/4: CLKDIV = 2 >> clk/8: CLKDIV = 4 >> clk/16: CLKDIV = 8 >> >> Ensure that the MPC86xx and MPC85xx still get the same behavior and >> make >> the the defines reflect their logical view (not the value of the >> field). >> >> Signed-off-by: Kumar Gala > > Acked-by: Peter Tyser Peter, I did notice that we dont actually set LCRR anywhere :) - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] mpc85xx: Add eSDHC support for MPC8569E-MDS boards
On Aug 19, 2009, at 1:37 PM, Anton Vorontsov wrote:
> eSDHC is mutually exlusive with UART0* and I2C2. When eSDHC is
> used, we should switch u-boot console to UART1, and make the
> proper device-tree fixups.
>
> * Actually, according to User's Guide we can use eSDHC in serial
> (1-bit) mode without disabling UART0, but for me it doesn't work
> on prototype boards.
>
> Signed-off-by: Anton Vorontsov
> ---
> board/freescale/mpc8569mds/mpc8569mds.c | 85 ++
> +
> cpu/mpc85xx/speed.c |2 +
> include/asm-ppc/global_data.h |3 +-
> include/configs/MPC8569MDS.h| 16 ++
> 4 files changed, 105 insertions(+), 1 deletions(-)
>
> diff --git a/board/freescale/mpc8569mds/mpc8569mds.c b/board/
> freescale/mpc8569mds/mpc8569mds.c
> index 1e7526a..7c1aaa5 100644
> --- a/board/freescale/mpc8569mds/mpc8569mds.c
> +++ b/board/freescale/mpc8569mds/mpc8569mds.c
> @@ -23,6 +23,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -35,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include "bcsr.h"
>
> @@ -303,6 +305,87 @@ local_bus_init(void)
> out_be32(&lbc->lcrr, (u32)in_be32(&lbc->lcrr)| 0x0003);
> }
>
> +#ifdef CONFIG_FSL_ESDHC
> +int board_mmc_init(bd_t *bd)
> +{
> + struct ccsr_gur *gur = (struct ccsr_gur *)
> CONFIG_SYS_MPC85xx_GUTS_ADDR;
> + u8 *bcsr = (u8 *)CONFIG_SYS_BCSR_BASE;
> +
> + if (!hwconfig("esdhc"))
> + return 0;
> +
> + printf("Enabling eSDHC...\n"
> +" For eSDHC to function, UART0 and I2C2 should be disabled.
> \n"
> +" Redirecting stderr, stdout and stdin to UART1...\n");
> + console_assign(stderr, "eserial1");
> + console_assign(stdout, "eserial1");
> + console_assign(stdin, "eserial1");
> + printf("Switched to UART1 (initial log has been printed to UART0).
> \n");
> +
> + /* Assign I2C2 signals to eSDHC. */
> + clrsetbits_be32(&gur->plppar1, PLPPAR1_I2C_BIT_MASK,
> +PLPPAR1_ESDHC_VAL);
> + clrsetbits_be32(&gur->plpdir1, PLPDIR1_I2C_BIT_MASK,
> +PLPDIR1_ESDHC_VAL);
> +
> + /* Mux UART0 & I2C2 signals to eSDHC. */
> + setbits_8(&bcsr[6], BCSR6_SD_ENABLE);
> +
> + return fsl_esdhc_mmc_init(bd);
> +}
> +
> +static void fdt_board_fixup_esdhc(void *blob, bd_t *bd)
> +{
> + const char *status = "disabled";
> + int off;
> + int err;
> +
> + /*
> + * In case of enabled eSDHC, we should disable UART0 and I2C2
> + * in the device tree, otherwise nothing to do.
> + */
> + if (!hwconfig("esdhc"))
> + return;
> +
> + off = fdt_path_offset(blob, "serial0");
> + if (off < 0) {
> + printf("WARNING: could not find serial0 alias: %s.\n",
> + fdt_strerror(off));
> + goto disable_i2c2;
> + }
> +
> + err = fdt_setprop(blob, off, "status", status, strlen(status) + 1);
> + if (err) {
> + printf("WARNING: could not set status for serial0: %s.\n",
> + fdt_strerror(err));
> + return;
> + }
> +
> +disable_i2c2:
> + off = -1;
> + while (1) {
> + const u32 *idx;
> + int len;
> +
> + off = fdt_node_offset_by_compatible(blob, off, "fsl-i2c");
> + if (off < 0)
> + break;
> +
> + idx = fdt_getprop(blob, off, "cell-index", &len);
> + if (!idx || len != sizeof(*idx))
> + continue;
> +
> + if (*idx == 1) {
> + fdt_setprop(blob, off, "status", status,
> + strlen(status) + 1);
> + break;
> + }
> + }
> +}
> +#else
> +static inline void fdt_board_fixup_esdhc(void *blob, bd_t *bd) {}
> +#endif
> +
> #ifdef CONFIG_PCIE1
> static struct pci_controller pcie1_hose;
> #endif /* CONFIG_PCIE1 */
> @@ -449,5 +532,7 @@ void ft_board_setup(void *blob, bd_t *bd)
> #ifdef CONFIG_PCIE1
> ft_fsl_pci_setup(blob, "pci1", &pcie1_hose);
> #endif
> + fdt_fixup_esdhc(blob, bd);
ft_cpu_setup() calls fdt_fixup_esdhc() for us now.
> + fdt_board_fixup_esdhc(blob, bd);
> }
> #endif
> diff --git a/cpu/mpc85xx/speed.c b/cpu/mpc85xx/speed.c
> index 286b6b2..73ecb76 100644
> --- a/cpu/mpc85xx/speed.c
> +++ b/cpu/mpc85xx/speed.c
> @@ -155,6 +155,8 @@ int get_clocks (void)
>
> #if defined(CONFIG_MPC8536)
> gd->sdhc_clk = gd->bus_clk / 2;
> +#elif defined(CONFIG_MPC8569)
> + gd->sdhc_clk = gd->bus_clk;
> #endif
This shouldn't be needed, replaced with CONFIG_FSL_ESDHC
>
> #if defined(CONFIG_CPM2)
> diff --git a/include/asm-ppc/global_data.h b/include/asm-ppc/
> global_data.h
> index 244c161..7cbcdb7 100644
> --- a/include/asm-ppc/global_data.h
> +++ b/include/asm-ppc/global_data.h
> @@ -86,7 +86,8 @@ typedef struct global_data {
> u32 mem_sec_clk;
> #endif /*
Re: [U-Boot] [PATCH 3/7] mpc85xx: Add eLBC NAND support for MPC8569E-MDS boards
On Aug 19, 2009, at 1:37 PM, Anton Vorontsov wrote:
> Simply add some defines, and adjust TLBe setup to include some
> space for eLBC NAND.
>
> Signed-off-by: Anton Vorontsov
> ---
> board/freescale/mpc8569mds/tlb.c | 30 +++---
> include/configs/MPC8569MDS.h | 23 +++
> 2 files changed, 34 insertions(+), 19 deletions(-)
>
> diff --git a/board/freescale/mpc8569mds/tlb.c b/board/freescale/
> mpc8569mds/tlb.c
> index d3b251e..3b8ee05 100644
> --- a/board/freescale/mpc8569mds/tlb.c
> +++ b/board/freescale/mpc8569mds/tlb.c
> @@ -46,22 +46,24 @@ struct fsl_e_tlb_entry tlb_table[] = {
>
> /* TLB 1 Initializations */
> /*
> - * TLBe 0: 16M Non-cacheable, guarded
> - * 0xff00 16M FLASH (upper half)
> + * TLBe 0: 64M Non-cacheable, guarded
>* Out of reset this entry is only 4K.
> + * 0xfc00 256KNAND FLASH (CS3)
> + * 0xfe00 32M NOR FLASH (CS0)
>*/
> - SET_TLB_ENTRY(1, CONFIG_SYS_FLASH_BASE + 0x100,
> - CONFIG_SYS_FLASH_BASE_PHYS + 0x100,
> + SET_TLB_ENTRY(1, CONFIG_SYS_NAND_BASE, CONFIG_SYS_NAND_BASE,
> MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> - 0, 0, BOOKE_PAGESZ_16M, 1),
> + 0, 0, BOOKE_PAGESZ_64M, 1),
>
> /*
> - * TLBe 1: 16M Non-cacheable, guarded
> - * 0xfe00 16M FLASH (lower half)
> + * TLBe 1: 256KB Non-cacheable, guarded
> + * 0xf800 32K BCSR
> + * 0xf8008000 32K PIB (CS4)
> + * 0xf801 32K PIB (CS5)
>*/
> - SET_TLB_ENTRY(1, CONFIG_SYS_FLASH_BASE, CONFIG_SYS_FLASH_BASE_PHYS,
> + SET_TLB_ENTRY(1, CONFIG_SYS_BCSR_BASE, CONFIG_SYS_BCSR_BASE_PHYS,
> MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> - 0, 1, BOOKE_PAGESZ_16M, 1),
> + 0, 1, BOOKE_PAGESZ_256K, 1),
>
> /*
>* TLBe 2: 256MNon-cacheable, guarded
> @@ -88,16 +90,6 @@ struct fsl_e_tlb_entry tlb_table[] = {
> SET_TLB_ENTRY(1, CONFIG_SYS_CCSRBAR, CONFIG_SYS_CCSRBAR_PHYS,
> MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> 0, 4, BOOKE_PAGESZ_64M, 1),
> -
> - /*
> - * TLBe 5: 256KNon-cacheable, guarded
> - * 0xf800 32K BCSR
> - * 0xf8008000 32K PIB (CS4)
> - * 0xf801 32K PIB (CS5)
> - */
> - SET_TLB_ENTRY(1, CONFIG_SYS_BCSR_BASE, CONFIG_SYS_BCSR_BASE_PHYS,
> - MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> - 0, 5, BOOKE_PAGESZ_256K, 1),
> };
>
> int num_tlb_entries = ARRAY_SIZE(tlb_table);
> diff --git a/include/configs/MPC8569MDS.h b/include/configs/
> MPC8569MDS.h
> index 3d07a5b..17ea3bb 100644
> --- a/include/configs/MPC8569MDS.h
> +++ b/include/configs/MPC8569MDS.h
> @@ -181,6 +181,29 @@ extern unsigned long get_clock_freq(void);
> #define CONFIG_SYS_FLASH_CFI
> #define CONFIG_SYS_FLASH_EMPTY_INFO
>
> +/* Chip select 3 - NAND */
> +#define CONFIG_SYS_NAND_BASE 0xFC00
Is it possible to have it at 0xffa0 so we match other FSL boards?
> +#define CONFIG_SYS_NAND_BASE_PHYSCONFIG_SYS_NAND_BASE
> +#define CONFIG_SYS_NAND_BASE_LIST{ CONFIG_SYS_NAND_BASE, }
> +#define CONFIG_SYS_MAX_NAND_DEVICE 1
> +#define CONFIG_MTD_NAND_VERIFY_WRITE 1
> +#define CONFIG_CMD_NAND 1
> +#define CONFIG_NAND_FSL_ELBC 1
> +#define CONFIG_SYS_NAND_BLOCK_SIZE (128 * 1024)
> +#define CONFIG_NAND_BR_PRELIM(CONFIG_SYS_NAND_BASE_PHYS \
> + | (2< + | BR_PS_8/* Port Size = 8 bit */ \
> + | BR_MS_FCM /* MSEL = FCM */ \
> + | BR_V) /* valid */
> +#define CONFIG_NAND_OR_PRELIM(0xFFFC /* length 256K */ \
> + | OR_FCM_CSCT \
> + | OR_FCM_CST \
> + | OR_FCM_CHT \
> + | OR_FCM_SCY_1 \
> + | OR_FCM_TRLX \
> + | OR_FCM_EHTR)
> +#define CONFIG_SYS_BR3_PRELIMCONFIG_NAND_BR_PRELIM /* NAND Base
> Address */
> +#define CONFIG_SYS_OR3_PRELIMCONFIG_NAND_OR_PRELIM /* NAND Options
> */
>
> /*
> * SDRAM on the LocalBus
> --
> 1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] mpc85xx: Setup SRIO memory region LAW for MPC8569E-MDS boards
On Aug 19, 2009, at 1:37 PM, Anton Vorontsov wrote:
> This patch sets memory window for Serial RapidIO on MPC8569E-MDS
> boards.
>
> Signed-off-by: Anton Vorontsov
> ---
> board/freescale/mpc8569mds/law.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/board/freescale/mpc8569mds/law.c b/board/freescale/
> mpc8569mds/law.c
> index e7381aa..60eea45 100644
> --- a/board/freescale/mpc8569mds/law.c
> +++ b/board/freescale/mpc8569mds/law.c
> @@ -54,6 +54,7 @@ struct law_entry law_table[] = {
> SET_LAW(CONFIG_SYS_PCIE1_MEM_PHYS, LAW_SIZE_256M,
> LAW_TRGT_IF_PCIE_1),
> SET_LAW(CONFIG_SYS_PCIE1_IO_PHYS, LAW_SIZE_8M, LAW_TRGT_IF_PCIE_1),
> SET_LAW(CONFIG_SYS_BCSR_BASE_PHYS, LAW_SIZE_128M, LAW_TRGT_IF_LBC),
> + SET_LAW(CONFIG_SYS_SRIO_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_RIO),
> };
Did I miss where we set CONFIG_SYS_SRIO_MEM_PHYS?
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] fdt_support: Add multi-serial support for stdout fixup
On Aug 19, 2009, at 1:37 PM, Anton Vorontsov wrote: > Currently fdt_fixup_stdout() is using hard-coded CONFIG_CONS_INDEX > constant. With multi-serial support, the CONS_INDEX may no longer > represent actual console, so we should try to extract port number > from the current stdio device name instead of always hard-coding the > constant value. > > Signed-off-by: Anton Vorontsov > --- > common/fdt_support.c | 22 +- > 1 files changed, 21 insertions(+), 1 deletions(-) Should get some Ack from Jerry. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx
On Sep 15, 2009, at 10:27 PM, Anton Vorontsov wrote: > Hello Kumar, > > On Tue, Sep 15, 2009 at 10:20:01PM -0500, Kumar Gala wrote: >> The following changes since commit >> 3ca55bce9c8bf00df06a20487fafc16fa2f8084b: >> Marcel Ziswiler (1): >>mpc8260: remove Ethernet node fixup to use generic FDT code. >> >> are available in the git repository at: >> >> git://git.denx.de/u-boot-mpc85xx.git master > > What about these patches (MPC8569)? > > http://lists.denx.de/pipermail/u-boot/2009-August/thread.html#58930 Reviewed, see my comments. (Please rebase, sorry for taking so long to get to them). - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc512x. Micron nand flash needs a reset before a read command is issued
Micron nand flash needs a reset before a read command is issued. The current mpc5121_nfc driver ignores the reset command. Signed-off-by: Paul Gibson --- drivers/mtd/nand/mpc5121_nfc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/mpc5121_nfc.c b/drivers/mtd/nand/mpc5121_nfc.c index 856cb36..7fd8a35 100644 --- a/drivers/mtd/nand/mpc5121_nfc.c +++ b/drivers/mtd/nand/mpc5121_nfc.c @@ -334,6 +334,7 @@ static void mpc5121_nfc_command(struct mtd_info *mtd, unsigned command, case NAND_CMD_ERASE2: case NAND_CMD_READID: case NAND_CMD_STATUS: + case NAND_CMD_RESET: break; default: -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Fix LCRR_CLKDIV defines
Peter Tyser a écrit : > On Tue, 2009-09-15 at 22:26 -0500, Kumar Gala wrote: > >> For some reason the CLKDIV field varies between SoC in how it interprets >> the bit values. >> >> [snip] >> >> Ensure that the MPC86xx and MPC85xx still get the same behavior and make >> the the defines reflect their logical view (not the value of the field). >> >> Nit picking: I just noticed that there is a duplicate "the" here. Also I prefer "behaviour" but this is a US/UK issue :-( Why can't Americans write English ;-) ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Fix LCRR_CLKDIV defines
On Tue, 2009-09-15 at 23:11 -0500, Kumar Gala wrote: > On Sep 15, 2009, at 10:32 PM, Peter Tyser wrote: > > > On Tue, 2009-09-15 at 22:26 -0500, Kumar Gala wrote: > >> For some reason the CLKDIV field varies between SoC in how it > >> interprets > >> the bit values. > >> > >> All 83xx and early (e500v1) PQ3 devices support: > >> clk/2: CLKDIV = 2 > >> clk/4: CLKDIV = 4 > >> clk/8: CLKDIV = 8 > >> > >> Newer PQ3 (e500v2) and MPC86xx support: > >> clk/4: CLKDIV = 2 > >> clk/8: CLKDIV = 4 > >> clk/16: CLKDIV = 8 > >> > >> Ensure that the MPC86xx and MPC85xx still get the same behavior and > >> make > >> the the defines reflect their logical view (not the value of the > >> field). > >> > >> Signed-off-by: Kumar Gala > > > > Acked-by: Peter Tyser > > Peter, > > I did notice that we dont actually set LCRR anywhere :) Lol, that's great:) CONFIG_SYS_LBC_LCRR does affect the value of sysinfo.freqLocalBus and thus gd->lbc_clk. And sysinfo.freqLocalBus is used to print the LBC frequency on bootup which added to the delusion that I was speeding it up:) A few other boards seem to define CONFIG_SYS_LBC_LCRR, but don't implement a board-specific modification of the LBCC register, so they should have the same "bug". I'll take a closer look tomorrow. Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] mpc83xx: update LCRR register handling
On Aug 27, 2009, at 3:53 PM, Kim Phillips wrote: > On Thu, 27 Aug 2009 08:20:35 +0200 > Heiko Schocher wrote: > >> MPC8379E RM says (10-34): >> Once LCRR[CLKDIV] is written, the register should be read, and then >> an isync should be executed. >> So update this in code. >> Also define a LCRR mask for processors, which uses not all bits >> in the LCRR register (as for example mpc832x did). >> >> Signed-off-by: Heiko Schocher >> --- >> changes since v1: >> - added comment from DaveLiu. moved LCRR setting to >> cpu_init_r() >> >> changes since v2: >> - added comment from Kim Phillips >>changed LCRR_MASK to 0x7fff >>use clrsetbits() > > Heiko - let's go with the SCCR approach of setting bits in the LCRR, > and have board config files only specify values for fields they're > modifying from the reset value for their processor (this can be > extended to 85xx-world). Did you guys ever come to resolution on this? Realizing we have same issue on 85xx & 86xx (we dont actually set LCRR at all in cpu/ code for 85xx or 86xx.) - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
