* Re: mtd mount problem
From: Jörn Engel @ 2005-04-22 1:31 UTC (permalink / raw)
To: Marco Schramel; +Cc: PPC_LINUX
In-Reply-To: <200504211502.48761.Schramel.Linux@go.bartec.de>
On Thu, 21 April 2005 15:02:48 +0200, Marco Schramel wrote:
>
> > > /dev # date > /dev/mtd1
> > > MTD_open
> > > MTD_ioctl
> > > MTD_write
> > > MTD do_write_buffer(): software timeout
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > ERROR ERROR ERROR ERROR ERROR ERROR ERROR
>
> This only occurs if i write the second time to the flash memory without erasing it before.
That's harmless. Flash is a write-once medium between erases.
Your setup appears sane in principle, so there must me a subtle
mistake you made (bugs are out of the question of course ;). Missing
a real howto, let me run through the sequence:
1. Erase the flash partition. Either
o eraseall /dev/mtdX or
o cat file_filled_with_0xff > /dev/mtdblockX
2. Do *not* write anything to it afterwards. Jffs2 would just error
out.
3. Mount jffs2. Either
o mount mtdX -t jffs2 <mount_point> or
o mount /dev/mtdblockX -t jffs2 <mount_point>
Jörn
--
The grand essentials of happiness are: something to do, something to
love, and something to hope for.
-- Allan K. Chalmers
^ permalink raw reply
* Re: TODC on ppc440
From: Eugene Surovegin @ 2005-04-22 0:48 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b05042117321cd86686@mail.gmail.com>
On Thu, Apr 21, 2005 at 05:32:43PM -0700, Shawn Jin wrote:
> Our SoC using ppc440 core will run on an emulator first. It doesn't
> have an external RTC. Hence time_init, set_rtc_time, get_rtc_time of
> ppc_md are all set to NULL. No TODC_ALLOC() is defined.
>
> I'm wondering if todc is vital to make OS run correctly. Is there any
> other choice?
No, RTC isn't required for Linux to run, but usually is useful to
have.
--
Eugene
^ permalink raw reply
* TODC on ppc440
From: Shawn Jin @ 2005-04-22 0:32 UTC (permalink / raw)
To: ppcembed
Hi,
Our SoC using ppc440 core will run on an emulator first. It doesn't
have an external RTC. Hence time_init, set_rtc_time, get_rtc_time of
ppc_md are all set to NULL. No TODC_ALLOC() is defined.
I'm wondering if todc is vital to make OS run correctly. Is there any
other choice?
I grepped ppc_md.time_init in the kernel source. It seems that linux
can run without ppc_md.time_init.
Any ideas?
-Shawn.
^ permalink raw reply
* Re: [PATCH 2.6.12-rc3] pmac: save master volume on sleep
From: Benjamin Herrenschmidt @ 2005-04-22 0:17 UTC (permalink / raw)
To: Colin Leroy
Cc: Takashi Iwai, linuxppc-dev list, debian-powerpc@lists.debian.org,
Andrew Morton
In-Reply-To: <20050421200408.5361a5b3@jack.colino.net>
On Thu, 2005-04-21 at 20:04 +0200, Colin Leroy wrote:
> Hi,
>
> Ben's patch that shutdowns master switch and restores it after
> resume ("pmac: Improve sleep code of tumbler driver") isn't enough here
> on an iBook (snapper chip).
>
> The master switch is correctly saved and restored, but somehow
> tumbler_put_master_volume() gets called just after
> tumbler_set_master_volume() and sets mix->master_vol[*] to 0. So, on
> resuming, the master switch is reenabled, but the volume is set to 0.
>
> Here's a patch that also saves and restores master_vol.
> Thanks,
Looks good.
Ben.
^ permalink raw reply
* Re: [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
From: Marcelo Tosatti @ 2005-04-21 18:50 UTC (permalink / raw)
To: 26-devel, linux-ppc-embedded
In-Reply-To: <20050421183239.GJ6525@logos.cnet>
[-- Attachment #1: Type: text/plain, Size: 175 bytes --]
On Thu, Apr 21, 2005 at 03:32:39PM -0300, Marcelo Tosatti wrote:
> Capture session of /proc/tlbmiss with 1 second interval:
Forgot to attach /proc/tlbmiss patch, here it is.
[-- Attachment #2: tlbmiss-count-2.4.patch --]
[-- Type: text/plain, Size: 4835 bytes --]
--- linux-216.orig/arch/ppc/kernel/head_8xx.S 2005-01-19 10:37:12.000000000 -0200
+++ linux-216/arch/ppc/kernel/head_8xx.S 2005-03-04 18:56:38.351004576 -0300
@@ -331,10 +331,21 @@
* kernel page tables.
*/
andi. r21, r20, 0x0800 /* Address >= 0x80000000 */
- beq 3f
+ beq 4f
lis r21, swapper_pg_dir@h
ori r21, r21, swapper_pg_dir@l
rlwimi r20, r21, 0, 2, 19
+
+ lis r3,(itlbkernel_miss-KERNELBASE)@ha
+ lwz r11,(itlbkernel_miss-KERNELBASE)@l(r3)
+ addi r11,r11,1
+ stw r11,(itlbkernel_miss-KERNELBASE)@l(r3)
+ beq 3f
+4:
+ lis r3,(itlbuser_miss-KERNELBASE)@ha
+ lwz r11,(itlbuser_miss-KERNELBASE)@l(r3)
+ addi r11,r11,1
+ stw r11,(itlbuser_miss-KERNELBASE)@l(r3)
3:
lwz r21, 0(r20) /* Get the level 1 entry */
rlwinm. r20, r21,0,0,19 /* Extract page descriptor page address */
@@ -414,10 +425,23 @@
* kernel page tables.
*/
andi. r21, r20, 0x0800
- beq 3f
+ beq 4f
lis r21, swapper_pg_dir@h
ori r21, r21, swapper_pg_dir@l
rlwimi r20, r21, 0, 2, 19
+
+ lis r3,(dtlbkernel_miss-KERNELBASE)@ha
+ lwz r11,(dtlbkernel_miss-KERNELBASE)@l(r3)
+ addi r11,r11,1
+ stw r11,(dtlbkernel_miss-KERNELBASE)@l(r3)
+ beq 3f
+
+4:
+ lis r3,(dtlbuser_miss-KERNELBASE)@ha
+ lwz r11,(dtlbuser_miss-KERNELBASE)@l(r3)
+ addi r11,r11,1
+ stw r11,(dtlbuser_miss-KERNELBASE)@l(r3)
+
3:
lwz r21, 0(r20) /* Get the level 1 entry */
rlwinm. r20, r21,0,0,19 /* Extract page descriptor page address */
@@ -989,3 +1013,14 @@
.space 16
#endif
+_GLOBAL(itlbuser_miss)
+ .space 4
+
+_GLOBAL(itlbkernel_miss)
+ .space 4
+
+_GLOBAL(dtlbuser_miss)
+ .long 0
+
+_GLOBAL(dtlbkernel_miss)
+ .long 0
--- linux-216.orig/fs/proc/proc_misc.c 2005-01-19 10:37:12.000000000 -0200
+++ linux-216/fs/proc/proc_misc.c 2005-03-04 18:57:37.241051928 -0300
@@ -621,6 +621,12 @@
if (entry)
entry->proc_fops = &ppc_htab_operations;
}
+ {
+ extern struct file_operations ppc_tlbmiss_operations;
+ entry = create_proc_entry("tlbmiss", S_IRUGO|S_IWUSR, NULL);
+ if (entry)
+ entry->proc_fops = &ppc_tlbmiss_operations;
+ }
#endif
entry = create_proc_read_entry("slabinfo", S_IWUSR | S_IRUGO, NULL,
slabinfo_read_proc, NULL);
--- linux-216.orig/arch/ppc/kernel/ppc_htab.c 2005-01-19 10:37:12.000000000 -0200
+++ linux-216/arch/ppc/kernel/ppc_htab.c 2005-03-04 19:04:05.276061640 -0300
@@ -21,6 +21,7 @@
#include <linux/sysctl.h>
#include <linux/ctype.h>
#include <linux/threads.h>
+#include <linux/seq_file.h>
#include <asm/uaccess.h>
#include <asm/bitops.h>
@@ -32,6 +33,51 @@
#include <asm/cputable.h>
#include <asm/system.h>
+#if 1
+
+extern unsigned long itlbuser_miss, itlbkernel_miss;
+extern unsigned long dtlbuser_miss, dtlbkernel_miss;
+
+static ssize_t ppc_tlbmiss_write(struct file *file, const char * buffer,
+ size_t count, loff_t *ppos);
+static int ppc_tlbmiss_show(struct seq_file *m, void *v);
+static int ppc_tlbmiss_open(struct inode *inode, struct file *file);
+
+struct file_operations ppc_tlbmiss_operations = {
+ .open = ppc_tlbmiss_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .write = ppc_tlbmiss_write,
+ .release = seq_release,
+};
+
+static int ppc_tlbmiss_open(struct inode *inode, struct file *file)
+{
+ return seq_open(file, &ppc_tlbmiss_show);
+}
+
+static int ppc_tlbmiss_show(struct seq_file *m, void *v)
+{
+ seq_printf(m, "I-TLB userspace misses: %lu\n"
+ "I-TLB kernel misses: %lu\n"
+ "D-TLB userspace misses: %lu\n"
+ "D-TLB kernel misses: %lu\n",
+ itlbuser_miss, itlbkernel_miss,
+ dtlbuser_miss, dtlbkernel_miss);
+ return 0;
+}
+
+static ssize_t ppc_tlbmiss_write(struct file *file, const char * buffer,
+ size_t count, loff_t *ppos)
+{
+ itlbuser_miss = 0;
+ itlbkernel_miss = 0;
+ dtlbuser_miss = 0;
+ dtlbkernel_miss = 0;
+}
+#endif
+
+
static ssize_t ppc_htab_read(struct file * file, char * buf,
size_t count, loff_t *ppos);
static ssize_t ppc_htab_write(struct file * file, const char * buffer,
^ permalink raw reply
* v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
From: Marcelo Tosatti @ 2005-04-21 18:32 UTC (permalink / raw)
To: 26-devel, linux-ppc-embedded
Hi everyone,
I found out that the previous TLB counter numbers were wrong, two
of the values were switched!
CPU is a 48Mhz 855T with 32 TLB entries, and 128Mb of RAM.
Now I've got valid results. With an idle machine, this are the results
of /proc/tlbmiss capture session with 1 second interval. Note that
idle actually means about 4/5 processes (AcsWeb, cy_pmd, cy_alarm, cy_wdt
kernel's keventd) running and switching over, but CPU is about 96-97%
idle.
As you can see, the ratio which TLB misses happen in v2.6 is
significantly higher, for both I/D caches, even with an almost idle machine.
The v2.6 kernel has grown in size relative to TLB usage (cache footprint),
which is, I start to believe, the major cause for this issue. If that
is the case other platforms will also suffer.
As one example, the number of page addresses which the "sys_read()"
system call needs to fetch to the I-cache in order to execute the task
(the calltree) is about twice in size as in v2.4.
Pantelis Antoniou informed that that 64 TLB-entry versions of MPC8xx
processors do not suffer such significant performance slowdown.
One point in reading these numbers is that v2.6 will count twice for
page fault misses which result in pte creation (DataTLBMiss->DataTLBError),
but I hope to change that for better precision. In this specific
case I guess it should not be significant given that no processes are
being created, mostly already mapped (periodic) routines are running.
I hope that capturing the TLB miss difference between v2.4 and v2.6
on a simple CPU intense benchmark such as the "dd" I've been using before
and multiplying that by translation cache miss penalty (20-23 clocks
on a miss versus 1 clock on a hit) should give us a good estimate
the real cost of these misses).
And I wonder, no other arches have been noticed this?
Comments are appreciated.
Capture session of /proc/tlbmiss with 1 second interval:
v2.6: v2.4:
I-TLB userspace misses: 2577 I-TLB userspace misses: 2192
I-TLB kernel misses: 1557 I-TLB kernel misses: 1328
D-TLB userspace misses: 7173 D-TLB userspace misses: 6801
D-TLB kernel misses: 4442 D-TLB kernel misses: 4260
* *
I-TLB userspace misses: 5324 I-TLB userspace misses: 4557
I-TLB kernel misses: 3277 I-TLB kernel misses: 2821
D-TLB userspace misses: 14399 D-TLB userspace misses: 13816
D-TLB kernel misses: 9069 D-TLB kernel misses: 8734
* *
I-TLB userspace misses: 8078 I-TLB userspace misses: 7003
I-TLB kernel misses: 4960 I-TLB kernel misses: 4360
D-TLB userspace misses: 22038 D-TLB userspace misses: 20952
D-TLB kernel misses: 13929 D-TLB kernel misses: 13299
* *
I-TLB userspace misses: 10791 I-TLB userspace misses: 9404
I-TLB kernel misses: 6643 I-TLB kernel misses: 5874
D-TLB userspace misses: 29350 D-TLB userspace misses: 27963
D-TLB kernel misses: 18555 D-TLB kernel misses: 17768
* *
I-TLB userspace misses: 13531 I-TLB userspace misses: 11801
I-TLB kernel misses: 8311 I-TLB kernel misses: 7390
D-TLB userspace misses: 36750 D-TLB userspace misses: 35123
D-TLB kernel misses: 23271 D-TLB kernel misses: 22416
* *
I-TLB userspace misses: 16434 I-TLB userspace misses: 14229
I-TLB kernel misses: 10172 I-TLB kernel misses: 8925
D-TLB userspace misses: 51096 D-TLB userspace misses: 42241
D-TLB kernel misses: 34982 D-TLB kernel misses: 26995
* *
I-TLB userspace misses: 19183 I-TLB userspace misses: 16646
I-TLB kernel misses: 11890 I-TLB kernel misses: 10445
D-TLB userspace misses: 58557 D-TLB userspace misses: 49291
D-TLB kernel misses: 39726 D-TLB kernel misses: 31479
* *
I-TLB userspace misses: 21973 I-TLB userspace misses: 19125
I-TLB kernel misses: 13596 I-TLB kernel misses: 12011
D-TLB userspace misses: 65933 D-TLB userspace misses: 56376
D-TLB kernel misses: 44401 D-TLB kernel misses: 36025
* *
I-TLB userspace misses: 24644 I-TLB userspace misses: 21509
I-TLB kernel misses: 15231 I-TLB kernel misses: 13526
D-TLB userspace misses: 73345 D-TLB userspace misses: 63431
D-TLB kernel misses: 49083 D-TLB kernel misses: 40567
* *
I-TLB userspace misses: 27451 I-TLB userspace misses: 23894
I-TLB kernel misses: 16974 I-TLB kernel misses: 15031
D-TLB userspace misses: 80652 D-TLB userspace misses: 70467
D-TLB kernel misses: 53739 D-TLB kernel misses: 45089
^ permalink raw reply
* Re: MPC8245 custom board, Linux 2.4 kernel hangs after uncompressing
From: Kishore Devireddy @ 2005-04-21 22:53 UTC (permalink / raw)
To: Atit_Shah; +Cc: linuxppc-embedded
In-Reply-To: <D8595042F3765A4285B848A78A2C2ED1027752@bsdmsg002.corp.satyam.ad>
Hi
As you mentioned I checked my System.map file and found
c0199614 b log_buf
and checked the location 0x00199614 using BDI2000
BDI>md 0x000199600
00199600 : 00000000 00000000 00000000 00000000 ................
00199610 : 00000000 3c363e4d 656d6f72 79204241 ....<6>Memory BA
00199620 : 54206d61 7070696e 673a2042 4154323d T mapping: BAT2=3D
00199630 : 31364d62 2c204241 54333d30 4d622c20 16Mb, BAT3=3D0Mb,
00199640 : 72657369 6475616c 3a20304d 620a3c34 residual: 0Mb.<4
00199650 : 3e4c696e 75782076 65727369 6f6e2032 >Linux version 2
00199660 : 2e342e32 35202872 6f6f7440 4d616e64 .4.25 (root@Mand
00199670 : 72616b65 29202867 63632076 65727369 rake) (gcc versi
00199680 : 6f6e2033 2e332e33 20284445 4e582045 on 3.3.3 (DENX E
00199690 : 4c444b20 332e3120 332e332e 332d3829 LDK 3.1 3.3.3-8)
001996a0 : 29202337 20576564 20417072 20323020 ) #7 Wed Apr 20
001996b0 : 30313a33 393a3437 20504454 20323030 01:39:47 PDT 200
001996c0 : 350a3c36 3e4d6f74 6f726f6c 61205350 5.<6>Motorola SP
001996d0 : 53205361 6e64706f 696e7420 54657374 S Sandpoint Test
001996e0 : 20506c61 74666f72 6d0a3c36 3e506f72 Platform.<6>Por
001996f0 : 74206279 204d6f6e 74615669 73746120 t by MontaVista
BDI>md
00199700 : 536f6674 77617265 2c20496e 632e2028 Software, Inc. (
00199710 : 736f7572 6365406d 76697374 612e636f source@mvista.co
00199720 : 6d290a3c 343e4f6e 206e6f64 65203020 m).<4>On node 0
00199730 : 746f7461 6c706167 65733a20 34303936 totalpages: 4096
00199740 : 0a3c343e 7a6f6e65 2830293a 20343039 .<4>zone(0): 409
00199750 : 36207061 6765732e 0a000000 00000000 6 pages.........
00199760 : 00000000 00000000 00000000 00000000 ................
00199770 : 00000000 00000000 00000000 00000000 ................
00199780 : 00000000 00000000 00000000 00000000 ................
00199790 : 00000000 00000000 00000000 00000000 ................
001997a0 : 70656e50 49432056 65727369 6f6e2031 penPIC Version 1
001997b0 : 2e322028 31204350 55732061 6e642031 .2 (1 CPUs and 1
001997c0 : 31204952 5120736f 75726365 73292061 1 IRQ sources) a
001997d0 : 74206664 66643030 30300a00 00000000 t fdfd0000......
001997e0 : 00000000 00000000 00000000 00000000 ................
001997f0 : 00000000 00000000 00000000 00000000 ................
But it does not say much here. Any help on this???????????
I also enabled CONFIG_SERIAL_TEXT_DEBUG, but I did not see any text
after uncompressing the linux.
As mentioned in your 3rd point "some flag in the U-Boot code for RAM
in burst mode.". What is that flag actually? Coulnd you let me know?
Thanks
Kishore
On 4/20/05, Atit_Shah <Atit_Shah@satyam.com> wrote:
>=20
> Hi Kishore,
>=20
> There are various things you can try.
>=20
> 1. Check your log buffer...your console may not be initialized yet so
> all your printk are logged at a particular memory location. Checkout the
> System.map file in the Linux folder for "log_buf". The address that you
> have there subtract it with the kernel base address. Then in view your
> memory at that location. We used U-Boot so we gave the command
>=20
> md <log_buff address>
>=20
> 2. We used a tool called Code Warrior which helped us single step debug
> the code, it didn't help us much though.
>=20
> 3. We had a problem with the RAM in burst mode. WolfGang would suggest
> you check out if your RAM is operational. In our case we had to set some
> flag in the U-Boot code for RAM in burst mode. We changed this flag and
> it boots fine. Well almost.
>=20
> Atit
>=20
>=20
> Message: 5
> Date: Wed, 20 Apr 2005 18:00:46 -0700
> From: Kishore Devireddy <kishorekrd@gmail.com>
> Subject: MPC8245 custom board, Linux 2.4 kernel hangs after
> uncompressing
> To: linuxppc-embedded@ozlabs.org
> Message-ID: <2cf2641f0504201800556805d2@mail.gmail.com>
> Content-Type: text/plain; charset=3DISO-8859-1
>=20
> Hi
>=20
> I am trying to run Embedded linux (ELDK) (2.4 kerenl) on a custom
> powerpc board,
> which is similar to Artis A3000 board. This board has
> mpc8245(XPC8245LZY266B), natsemi 83815 ethernet, 4MB intel e28f320
> flash, 16MB winbond w986432DH-6 SDRAM. So I configured and compiled
> U-boot for A3000 borad. U-boot worked on my board also. Next I
> compiled ELDK 3.0 for Sandpoint 8245 board and copied to flash. But
> linux hangs after uncompressing
>=20
> U-Boot 1.1.2 (Apr 14 2005 - 00:02:29)
>=20
> CPU: MPC8245 Revision 1.2 at 249.999 MHz: 16 kB I-Cache 16 kB D-Cache
> Board: A3000 Local Bus at 99.999 MHz
> I2C: ready
> DRAM: 16 MB
> FLASH: Get flash bank 0 @ 0xffc00000
> Manuf. ID @ 0xff800000: 0x00000089
> Device ID @ 0xff800001: 0x00000016
> ## Flash bank 0 at 0xffc00000 sizes: 0x00400000
> protect monitor fff00000 @ 40000
> protect environtment fffc0000 @ 20000
> ## Final Flash bank sizes: 00400000
> 4 MB
> 00 13 100b 0020 0200 ff
> In: serial
> Out: serial
> Err: serial
> Net: natsemi: EEPROM contents:
> ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
> dp83815#0
> Warning: dp83815#0 MAC addresses don't match:
> Address in SROM is FF:FF:FF:FF:FF:FF
> Address in environment is 00:40:05:B0:F1:BA
>=20
> A3000> tftpboot 400000 uImage.eldk
> Using dp83815#0 device
> TFTP from server 192.168.1.124; our IP address is 192.168.1.54
> Filename 'uImage.eldk'.
> Load address: 0x400000
> Loading:
> #################################################################
> #################################################################
> ###################
> done
> Bytes transferred =3D 757926 (b90a6 hex)
> A3000> bootm
> ## Booting image at 00400000 ...
> Image Name: Linux-2.4.25
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 757862 Bytes =3D 740.1 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
>=20
> nothing happens after this until I reboot the board. I read u-boot FAQ
> and configured bd_info structure same for both u-boot and Linux. I
> found that CFG_IMMR is not applicable to MPC8245. I also used
> clocks_in_mhz variable also before loading Linux. I am stuck here.
> Could you please let me know what should I do next?
>=20
> Thanks
> Kishore
>=20
> ------------------------------
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
> End of Linuxppc-embedded Digest, Vol 8, Issue 56
> ************************************************
>=20
> DISCLAIMER:
> This email (including any attachments) is intended for the sole use of th=
e intended recipient/s and may contain material that is CONFIDENTIAL AND PR=
IVATE COMPANY INFORMATION. Any review or reliance by others or copying or d=
istribution or forwarding of any or all of the contents in this message is =
STRICTLY PROHIBITED. If you are not the intended recipient, please contact =
the sender by email and delete all copies; your cooperation in this regard =
is appreciated.
>
^ permalink raw reply
* [DBG SRC] Re: DMA Problem
From: Roger Larsson @ 2005-04-21 20:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <42669370.90706@tsi-telsys.com>
On Wednesday 20 April 2005 19.37, Sanjay Bajaj wrote:
> I am having a setup issue with the DMA channel 0 with the DMA Controller
> on PPC440GX. The code I wrote is:
>
> #if defined(CONFIG_PPC4xx_DMA)
> /* Setup the DMA */
> DPRINTK("PPC4xx pwidth: %d\n", ppc4xx_get_peripheral_width(DMA_CH0));
> ppc4xx_set_dma_mode(DMA_CH0, DMA_MODE_READ);
> ppc4xx_set_src_addr(DMA_CH0, (phys_addr_t)(pdev->x2mem_phys_addr +
> src_addr));
> ppc4xx_set_dst_addr(DMA_CH0, (phys_addr_t)dst_addr);
> ppc4xx_set_dma_count(DMA_CH0, count);
> ppc4xx_enable_dma(DMA_CH0);
> DPRINTK("PPC4xx DMA Status: %d\n", ppc4xx_get_dma_status());
> #endif
>
> The DMA never completes and leaves a residue of 'count'. What am I missing?
>
Request irq and dma?
if ((ret = request_irq(dma_irq, dma_irq_handler, SA_SHIRQ, "NAME")))
- - -
/* reserve a DMA channel */
if (DBG_DMA(request_dma(DMA_CH0, const char *device_id))
BTW you should check return values, try this:
int fgrabber_report_dma_error(const char *call, int ret)
{
switch (ret)
{
case DMA_STATUS_GOOD:
// printk(KERN_DEBUG "dma: %s STATUS_GOOD\n", call);
break;
case DMA_STATUS_BAD_CHANNEL:
printk(KERN_DEBUG "dma: %s STATUS_BAD_CHANNEL\n", call);
break;
case DMA_STATUS_BAD_HANDLE:
printk(KERN_DEBUG "dma: %s STATUS_BAD_HANDLE", call);
break;
case DMA_STATUS_BAD_MODE:
printk(KERN_DEBUG "dma: %s STATUS_BAD_MODE", call);
break;
case DMA_STATUS_NULL_POINTER:
printk(KERN_DEBUG "dma: %s STATUS_NULL_POINTER", call);
break;
case DMA_STATUS_OUT_OF_MEMORY:
printk(KERN_DEBUG "dma: %s STATUS_OUT_OF_MEMORY", call);
break;
case DMA_STATUS_SGL_LIST_EMPTY:
printk(KERN_DEBUG "dma: %s STATUS_SGL_LIST_EMPTY", call);
break;
case DMA_STATUS_GENERAL_ERROR:
printk(KERN_DEBUG "dma: %s STATUS_GENERAL_ERROR", call);
break;
case DMA_STATUS_CHANNEL_NOTFREE:
printk(KERN_DEBUG "dma: %s STATUS_CHANNEL_NOTFREE", call);
break;
default:
printk(KERN_DEBUG "dma: %s STATUS(0x%x)", call, ret);
break;
}
return ret;
}
#ifdef DEBUG_DMA
#define DBG_DMA(call) fgrabber_report_dma_error(#call, call)
#else
#define DBG_DMA(call) call
#endif
/RogerL
^ permalink raw reply
* Re: Preemption patch problem
From: Roger Larsson @ 2005-04-21 20:29 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <004B1D7A5257174C9044A1B7BD0E60ED0178CC05@ratatosk.combitechsystems.com>
On Thursday 21 April 2005 12.08, Bj=F6rn =D6stby wrote:
> Greetings.
>
> I have been struggling with the famous preemption patch (from Robert Love)
> the past few days. Im using mpc823e and tried with kernels
> 2.4.{18,21,22,23}. The patch applies flawless and so on, but when the
> kernel is up and running strange memory problems start to appear like:
>
> _alloc_pages: 0-order allocation failed (gfp=3D0x1d2/0)
[
#define __GFP_DMA 0x01
* #define __GFP_HIGHMEM 0x02
* #define __GFP_WAIT 0x10 /* Can wait and reschedule? */
#define __GFP_HIGH 0x20 /* Should access emergency pools? */
* #define __GFP_IO 0x40 /* Can start low memory physical IO? */
* #define __GFP_HIGHIO 0x80 /* Can start high mem physical IO? */
* #define __GFP_FS 0x100 /* Can call down to low-level FS? */
=2D - -
#define GFP_HIGHUSER ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO =
|=20
__GFP_FS | __GFP_HIGHMEM)
=2D - -
]
So page_alloc is called with GFP_HIGHUSER, from where and why?
Try to find out what is causing this, set the 'vm_gfp_debug'
see 'linux/mm/page_alloc.c'
>
> Right, so... It seems like a giant memory leak of some sort, cause when I
> run programs the kernel goes ballistic and starts reaping processes:
>
> "VM: Killing process <name>"
Well the problem is that it actually is not getting any memory. It might be
code that retries to allocate memory when there really are none (you probab=
ly
do not use swap)
>
> Eventually it comes down to "VM: killing init" and then it's curtains.
>
> I know that these problems is caused by the patch since the kernel runs
> smooth without the patch applied. Does anyone have a clue what to do here
> (beside let go of the patch)?
Analyze memory usage on the working non patched kernel.
/RogerL
^ permalink raw reply
* Re: 824x Sandpoint with 2.6.x
From: Mark A. Greer @ 2005-04-21 19:57 UTC (permalink / raw)
To: Sam Song; +Cc: linuxppc-embedded
In-Reply-To: <20050421024005.32847.qmail@web15805.mail.cnb.yahoo.com>
Sam Song wrote:
>>You can even use the
>>progress facility to dump the __log_buf.
>>
>>
>
>I don't have such experience. If possible, could u
>give me a linkage or doc for me to have a look?
>
The "doc" is the source code.
>BTW, Could I use KGDB to try it?
>
>
It may help but it depends on how far you're getting and what your
problem is.
Mark
^ permalink raw reply
* TCP issues
From: warrier @ 2005-04-21 19:06 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I've got a peculiar problem with TCP on the kernel that I am running.
It's version 2.4.25 and the CPU is MPC5200. I'm using the linux kernel
distribution that came with the DENX distribution.
Anyway it prints out Yellow Dog Linux 3.0
While doing a file transfer especially with files that are larger than 7K
(using ftp) the card hangs.
Using a combination of tcpdump and some printk's I've noticed that the tcp
checksum is wrong in these cases. The IP header checksum is fine. The
corruption seems to occur before tcp_tansmit_skb is called. The
corruption is obviously in the tcp buffer as the partial checksums are not
altered as the the packet progresses. It seems that the corruption occurs
after the partial checksum has been calculated.
I'm using the same kernel on an 8270 based card without any problems.
Alternately if I use "printk" at some locations the problem disappears. It
seems as if there is some race condition that causes the corruption.
Has anybody come across this buffer corruption before? I'm not sure where
to post this problem.
Thanks
S
^ permalink raw reply
* [PATCH 2.6.12-rc3] pmac: save master volume on sleep
From: Colin Leroy @ 2005-04-21 18:04 UTC (permalink / raw)
To: debian-powerpc@lists.debian.org, linuxppc-dev,
Benjamin Herrenschmidt
Cc: Takashi Iwai, Andrew Morton
Hi,
Ben's patch that shutdowns master switch and restores it after
resume ("pmac: Improve sleep code of tumbler driver") isn't enough here
on an iBook (snapper chip).
The master switch is correctly saved and restored, but somehow
tumbler_put_master_volume() gets called just after
tumbler_set_master_volume() and sets mix->master_vol[*] to 0. So, on
resuming, the master switch is reenabled, but the volume is set to 0.
Here's a patch that also saves and restores master_vol.
Thanks,
Signed-off-by: Colin Leroy <colin@colino.net>
--- a/sound/ppc/tumbler.c 2005-04-21 19:56:06.000000000 +0200
+++ b/sound/ppc/tumbler.c 2005-04-21 19:55:43.000000000 +0200
@@ -99,6 +99,7 @@
pmac_gpio_t hp_detect;
int headphone_irq;
int lineout_irq;
+ unsigned int save_master_vol[2];
unsigned int master_vol[2];
unsigned int save_master_switch[2];
unsigned int master_switch[2];
@@ -1128,6 +1129,8 @@
disable_irq(mix->lineout_irq);
mix->save_master_switch[0] = mix->master_switch[0];
mix->save_master_switch[1] = mix->master_switch[1];
+ mix->save_master_vol[0] = mix->master_vol[0];
+ mix->save_master_vol[1] = mix->master_vol[1];
mix->master_switch[0] = mix->master_switch[1] = 0;
tumbler_set_master_volume(mix);
@@ -1156,6 +1159,8 @@
mix->acs &= ~1;
mix->master_switch[0] = mix->save_master_switch[0];
mix->master_switch[1] = mix->save_master_switch[1];
+ mix->master_vol[0] = mix->save_master_vol[0];
+ mix->master_vol[1] = mix->save_master_vol[1];
tumbler_reset_audio(chip);
if (mix->i2c.client && mix->i2c.init_client) {
if (mix->i2c.init_client(&mix->i2c) < 0)
^ permalink raw reply
* Re: [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge support to thestock linux-2.5 (updated)
From: Kumar Gala @ 2005-04-21 18:03 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Tom Rini, linuxppc-embedded list
In-Reply-To: <4267E391.5040006@ru.mvista.com>
On Apr 21, 2005, at 12:32 PM, Vitaly Bordug wrote:
> Rune Torgersen wrote:
> From: Vitaly Bordug [ mailto:vbordug@ru.mvista.com ]
> Sent: Thursday, April 21, 2005 10:29
>
>
> This is all right. The only thing I still don't understand -
> how this stuff work without PCI IRQ (don't know much about 8266
>
> though).
>
> On my 8272 only one IRQ is produced and it should be demux'ed in order
> for PCI devices to work. I agree that the siumcr stuff would better
>
> reside
>
> in the firmware, and I have submitted related patch to the =
u-boot-users
>
>
> list, but I have no idea whether it would be accepted or not
>
> (Wolfgang?).
>
> Ah.. That. I have that in a board specific file. Looks excactly like=20=
> the
> implementation you have (for the 8266 port) For our internal board, it
> is quite different, so it should probably be in a board specific file
> (eg platforms/board_pci_setup.h)
>
>
> The main point I actually dislike in the current m8260
>
> implementation
>
> is that it adds defines for the PCI memory map while it exists
> (and already included) in platforms/pq2ads.h. The memory maps are
> nearly the same so we should decide which one will remain.
>
> I think I like the _LOWER/_UPPER/OFFSET variant. And it need to be
> possible to override it in board-files.
> I'll work in getting the 8266 PCI support I have to be integrated into
> the PQ2[F]ADS board support.
>
>
> Great. Than I'll replace PCI_MSTR_* with _LOWER/_UPPER/OFFSET stuff=20=
> in the board-specific file so that it override m8260_pci.h defines.=A0=20=
> Another issue - I want to keep the setup of the second outbound PCI=20
> window (pcimask1/pcibr1) - since continuous mem/mmio/io is not=20
> flexible enough - and to keep potarx/pobarx/pocmrx assignments as they=20=
> are in pq_... version (changing of course all relative constants to=20
> _LOWER/... stuff).
>
> Maybe the m8260.[c,h] should be renamed since this suites not only=20
> 826x series?
>
> Comments/objections?
Renaming is fine by me, however I think currently there is an=20
understanding that all *8260* is applicable to all PQ2 family products.
- kumar
^ permalink raw reply
* RE: [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge support to thestock linux-2.5 (updated)
From: Rune Torgersen @ 2005-04-21 17:42 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Tom Rini, linuxppc-embedded list
> Another issue - I want to keep the setup of the second outbound PCI
window=20
> (pcimask1/pcibr1) - since continuous mem/mmio/io is not flexible
enough -=20
> and to keep potarx/pobarx/pocmrx assignments as they are in pq_...
version=20
> (changing of course all relative constants to _LOWER/... stuff).=20
How about initializing pcimsk1 if needed, eg have=20
#define M82XX_PCI_PRIMARY_WINDOW_SIZE
#define M82XX_PCI_PRIMARY_WINDOW_ADDR
#define M82XX_PCI_SECONDARY_WINDOW_SIZE
#define M82XX_PCI_SECONDARY_WINDOW_ADDR
And depend pcimsk1/br1 on the *_SECONDARY_WONDOW* ones
> Maybe the m8260.[c,h] should be renamed since this suites not only
826x series?
Probably to m82xx.[ch] because it is 82xx specific (I think)
Comments/objections?
^ permalink raw reply
* Re: [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge support to thestock linux-2.5 (updated)
From: Vitaly Bordug @ 2005-04-21 17:32 UTC (permalink / raw)
To: Rune Torgersen; +Cc: Tom Rini, linuxppc-embedded list
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B85936A@ismail.innsys.innovsys.com>
[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]
Rune Torgersen wrote:
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> Sent: Thursday, April 21, 2005 10:29
>
>
>
>> This is all right. The only thing I still don't understand -
>>how this stuff work without PCI IRQ (don't know much about 8266
>>
>>
>though).
>
>
>>On my 8272 only one IRQ is produced and it should be demux'ed in order
>>for PCI devices to work. I agree that the siumcr stuff would better
>>
>>
>reside
>
>
>>in the firmware, and I have submitted related patch to the u-boot-users
>>
>>
>
>
>
>>list, but I have no idea whether it would be accepted or not
>>
>>
>(Wolfgang?).
>
>Ah.. That. I have that in a board specific file. Looks excactly like the
>implementation you have (for the 8266 port) For our internal board, it
>is quite different, so it should probably be in a board specific file
>(eg platforms/board_pci_setup.h)
>
>
>
>> The main point I actually dislike in the current m8260
>>
>>
>implementation
>
>
>>is that it adds defines for the PCI memory map while it exists
>>(and already included) in platforms/pq2ads.h. The memory maps are
>>nearly the same so we should decide which one will remain.
>>
>>
>
>I think I like the _LOWER/_UPPER/OFFSET variant. And it need to be
>possible to override it in board-files.
>I'll work in getting the 8266 PCI support I have to be integrated into
>the PQ2[F]ADS board support.
>
>
>
Great. Than I'll replace PCI_MSTR_* with _LOWER/_UPPER/OFFSET stuff in
the board-specific file so that it override m8260_pci.h defines.
Another issue - I want to keep the setup of the second outbound PCI
window (pcimask1/pcibr1) - since continuous mem/mmio/io is not flexible
enough - and to keep potarx/pobarx/pocmrx assignments as they are in
pq_... version (changing of course all relative constants to _LOWER/...
stuff).
Maybe the m8260.[c,h] should be renamed since this suites not only 826x
series?
Comments/objections?
--
Sincerely,
Vitaly
[-- Attachment #2: Type: text/html, Size: 3008 bytes --]
^ permalink raw reply
* Re: 2.6.x with TQM860L
From: Karim Yaghmour @ 2005-04-21 17:17 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050411072406.CF0F5C108D@atlas.denx.de>
Wolfgang Denk wrote:
> No, in this case it is not a SDRAM issue. I understand that you're
> using U-Boot on the board, and this is one of our reference platforms
> and among the best tested systems with U-Boot.
>
> Did you apply Marcelo's patch?
... Karim returns to mailing list with brown bag on his head ...
hmm... I keep telling newbies to read the archives ... lucky for me
I actually got intelligent replies.
I figured the TQM board ought to not have that type of problem, but
I just couldn't nail down the real problem. So yes, after having
tried Marcelo's patch, things work fine. However, noe that 2.6.11.6
doesn't work out of the box for the board (i.e. doing "make
TQM860L_defconfig" doesn't yield a functional config.) I had to
manually hack a config together for it to actually work.
Thanks,
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546
^ permalink raw reply
* Re: 2.6.x with TQM860L
From: Karim Yaghmour @ 2005-04-21 17:13 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <425A1456.7020104@intracom.gr>
Pantelis Antoniou wrote:
> You need the following small patch.
>
> For all the gory details follow the thread
> "8xx v2.6 TLB problems and suggested workaround"
Thanks. I haven't tried the actual patch you sent, but Marcelo's patch
does work with the TQM860L.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546
^ permalink raw reply
* RE: [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge support to thestock linux-2.5 (updated)
From: Rune Torgersen @ 2005-04-21 16:32 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Tom Rini, linuxppc-embedded list
From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]=20
Sent: Thursday, April 21, 2005 10:29
> This is all right. The only thing I still don't understand -=20
>how this stuff work without PCI IRQ (don't know much about 8266
though).=20
>On my 8272 only one IRQ is produced and it should be demux'ed in order=20
>for PCI devices to work. I agree that the siumcr stuff would better
reside=20
>in the firmware, and I have submitted related patch to the u-boot-users
>list, but I have no idea whether it would be accepted or not
(Wolfgang?).
Ah.. That. I have that in a board specific file. Looks excactly like the
implementation you have (for the 8266 port) For our internal board, it
is quite different, so it should probably be in a board specific file
(eg platforms/board_pci_setup.h)
=09
> The main point I actually dislike in the current m8260
implementation=20
>is that it adds defines for the PCI memory map while it exists=20
>(and already included) in platforms/pq2ads.h. The memory maps are=20
>nearly the same so we should decide which one will remain.=09
I think I like the _LOWER/_UPPER/OFFSET variant. And it need to be
possible to override it in board-files.
I'll work in getting the 8266 PCI support I have to be integrated into
the PQ2[F]ADS board support.
=09
--=20
Sincerely,=20
Vitaly
=09
^ permalink raw reply
* Re: mtd mount problem
From: Eugene Surovegin @ 2005-04-21 15:47 UTC (permalink / raw)
To: Marco Schramel; +Cc: PPC_LINUX
In-Reply-To: <200504211144.28584.Schramel.Linux@go.bartec.de>
On Thu, Apr 21, 2005 at 11:44:28AM +0200, Marco Schramel wrote:
> Hi Eugene,
>
> thanks for your answer
>
> > Check that you have CONFIG_MTD_BLOCK enabled in your .config.
> #
> # Memory Technology Devices (MTD)
> #
> CONFIG_MTD=y
> CONFIG_MTD_DEBUG=y
> CONFIG_MTD_DEBUG_VERBOSE=0
> CONFIG_MTD_PARTITIONS=y
> # CONFIG_MTD_CONCAT is not set
> # CONFIG_MTD_REDBOOT_PARTS is not set
> # CONFIG_MTD_CMDLINE_PARTS is not set
> CONFIG_MTD_CHAR=y
> CONFIG_MTD_BLOCK=y
> # CONFIG_FTL is not set
> # CONFIG_NFTL is not set
> # CONFIG_INFTL is not set
>
> >
> > Also, check that you have /dev/mtdblock1 node in /dev directory on the
> > target.
> >
>
> This is what i meant before with ramdisk.
>
> /dev # ls -al mtdblock1
> brw-rw-r-- 1 root root 31, 1 Mar 17 2005 mtdblock1
>
> It should be ok. Isn't it ??
Hmm, yes, provided you have also jffs2 enabled, but I'd expect
different error message if not.
Could you show us dmesg output, and also `cat /proc/devices`?
--
Eugene
^ permalink raw reply
* Re: [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge support to thestock linux-2.5 (updated)
From: Vitaly Bordug @ 2005-04-21 15:29 UTC (permalink / raw)
To: Rune Torgersen; +Cc: Tom Rini, linuxppc-embedded list
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859369@ismail.innsys.innovsys.com>
[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]
Rune Torgersen wrote:
>
>
>
>
>>Not 100% sure. Maybe Wolfgang or someone else know what the existing
>>m8260 pci functionality is suppose to work with. It seems
>>odd that it
>>did not have some of the bits you added for the 8272ads. Its
>>not clear
>>to me if it actually worked on any systems or not. Let see
>>if Wolfgang
>>has any insight as a first step.
>>
>>
>
>The current one works on 8266/8265 based boards. It requires u-boot to
>partiallyt set up PCI first.
>I have a patch tat enables 8266ADS support, but have never posted it
>(also because it has been superceded by PQ2ADS patches)
>
>The missing pieces are the siumcr setup, which is done in U-Boot (almost
>better to do it there as it is highly board dependant, and you would
>have an afoul lot of #ifdefs to support all variants)
>
>The other missing part is setup of the second outbound PCI wondow
>(pcimask1/pcibr1). This is not used, bacqause the whole outbound window
>is set up to be contiguous, and is covered by pcimsk0/pcibr0
>
>I am running a slightly modified version of m8260_setup_pci on an
>internal board port, and it works just fine.
>
>Only change I'v had to do (to m8260_find bridges) is to add a bit on the
>IORESOURCE_IO part, so that IO memory is detected correctly.
>
> pci_init_resource(&hose->io_resource,
> MPC826x_PCI_LOWER_IO,
> MPC826x_PCI_UPPER_IO,
> IORESOURCE_IO | 1, "PCI I/O"); // the 1 added
>so IO areas work. :FIXME: find real source
>
>
>
>
This is all right. The only thing I still don't understand - how this
stuff work without PCI IRQ (don't know much about 8266 though). On my
8272 only one IRQ is produced and it should be demux'ed in order for PCI
devices to work. I agree that the siumcr stuff would better reside in
the firmware, and I have submitted related patch to the u-boot-users
list, but I have no idea whether it would be accepted or not (Wolfgang?).
The main point I actually dislike in the current m8260 implementation is
that it adds defines for the PCI memory map while it exists (and already
included) in platforms/pq2ads.h. The memory maps are nearly the same so
we should decide which one will remain.
--
Sincerely,
Vitaly
[-- Attachment #2: Type: text/html, Size: 2670 bytes --]
^ permalink raw reply
* Re: Virtex2pro OPB frequency 10/100Mbs ethernet link related problem
From: Pierre Kestener @ 2005-04-21 15:17 UTC (permalink / raw)
To: Pierre Kestener; +Cc: linuxppc-embedded
In-Reply-To: <42662502.5060108@cea.fr>
Hello,
i made a mistake by downloading the wrong bitstream into the virtex,
so the linux kernel was ok but not the FPGA.
My previous message must not be taken into account.
sorry
Pierre Kestener.
Pierre Kestener wrote:
> Hello,
>
> I have noticed a strange behavior regarding NFS on my target
> (Virtex2pro ff1152 from Memec) when increasing OPB/PLB bus frequency
> from 50 MHz to 66.666667MHz to be able to use a 100 Mbs ethernet link
> (it is mentionned in the OPB/EMAC IP doc
> that Bus clock should be more than 65 MHz to have 100Mbs).
>
> I use U-boot (ML300 port with small modifications) for the bootloader
> step (download linux kernel via tftp) and kernel 2.4.20. The root
> filesytem is mounted via NFS.
>
> At 50MHz, everything works fine. Ethernet link speed is 10 Mbs. I can
> check that on my Ethernet switch.
>
> When using 66.666667MHz OPB frequency, ethernet Link speed is indeed
> 100Mbs. U-boot works perfectly but linux boot fails trying to get nfs
> server port !!!
>
> Using "tcpdump" on my linux host, i can see that target sends ARP
> packets and the server replies but nothing happends...
>
> 09:04:28.848228 arp who-has myHost.extra.cea.fr tell 132.166.xxx.yyy
> 09:04:28.848265 arp reply myHost.extra.cea.fr is-at 00:06:5b:xx:yy:zz
>
> Has anyone seen such a behavior, using a 100Mbs ethernet link with a
> Virtex2pro target ?
> Any idea regarding this problem (hardware or software) ?
>
> Thanks a lost.
> Best Regards.
>
> Pierre Kestener.
>
--
+-------------------------------------------+
CEA Saclay -- DSM/DAPNIA/SEDI
91191 Gif-sur-Yvette - FRANCE
tel : +33 (0)1 69 08 57 09
http://pierre.kestener.free.fr/
+-------------------------------------------+
^ permalink raw reply
* RE: [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge support to thestock linux-2.5 (updated)
From: Rune Torgersen @ 2005-04-21 14:54 UTC (permalink / raw)
To: Kumar Gala, Vitaly Bordug, Wolfgang Denk; +Cc: Tom Rini, linuxppc-embedded list
=20
> Not 100% sure. Maybe Wolfgang or someone else know what the existing=20
> m8260 pci functionality is suppose to work with. It seems=20
> odd that it=20
> did not have some of the bits you added for the 8272ads. Its=20
> not clear=20
> to me if it actually worked on any systems or not. Let see=20
> if Wolfgang=20
> has any insight as a first step.
The current one works on 8266/8265 based boards. It requires u-boot to
partiallyt set up PCI first.
I have a patch tat enables 8266ADS support, but have never posted it
(also because it has been superceded by PQ2ADS patches)
The missing pieces are the siumcr setup, which is done in U-Boot (almost
better to do it there as it is highly board dependant, and you would
have an afoul lot of #ifdefs to support all variants)
The other missing part is setup of the second outbound PCI wondow
(pcimask1/pcibr1). This is not used, bacqause the whole outbound window
is set up to be contiguous, and is covered by pcimsk0/pcibr0
I am running a slightly modified version of m8260_setup_pci on an
internal board port, and it works just fine.
Only change I'v had to do (to m8260_find bridges) is to add a bit on the
IORESOURCE_IO part, so that IO memory is detected correctly.
pci_init_resource(&hose->io_resource,
MPC826x_PCI_LOWER_IO,
MPC826x_PCI_UPPER_IO,
IORESOURCE_IO | 1, "PCI I/O"); // the 1 added
so IO areas work. :FIXME: find real source
^ permalink raw reply
* Re: mtd mount problem
From: Kylo Ginsberg @ 2005-04-21 14:44 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: PPC_LINUX
In-Reply-To: <20050421103234.ED367C1510@atlas.denx.de>
On 4/21/05, Wolfgang Denk <wd@denx.de> wrote:
> > dev # mount -t jffs2 /dev/mtdblock1 /mnt/Flash1
> > mount: Mounting /dev/mtdblock1 on /mnt/Flash1 failed: No such device
>=20
> Assuming that this is a mount builtin to the busybox, this message
> means that there is no such file as "/dev/mtdblock1" in your root
> file system - exactly as the error message says.
I believe you can also get "No such device" if you haven't configured
linux for JFFS2 support; another thing to double check in your
.config.
Cheers,
Kylo
^ permalink raw reply
* Re: [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge support to the stock linux-2.5 (updated)
From: Kumar Gala @ 2005-04-21 14:00 UTC (permalink / raw)
To: Vitaly Bordug, Wolfgang Denk; +Cc: Tom Rini, linuxppc-embedded list
In-Reply-To: <426796C7.3090501@ru.mvista.com>
On Apr 21, 2005, at 7:04 AM, Vitaly Bordug wrote:
> Kumar Gala wrote:
>
> >On Wed, 13 Apr 2005, Vitaly Bordug wrote:
> >
> >Finally, had some time to really look at this patch, comments are=20
> inline.
> >Look for (galak).=A0 A few high level comments:
> >
> >Can we fold pq2ads_setup_hose into pq2ads_setup_pci?
> >
> No problem, I think...
cool.
> > Also, is there
> >anything to be done to unify m8260_setup_pci &
> >pq2ads_setup_pci..
> >
> Well, in my opinion, m8260_setup_pci should be replaced with
> pq2ads_setup_pci, as far as they are intended to do the same (as I
> mentioned in my very first PCI patch marked as RFC). But I actually
> cannot test this stuff on anything other than 8272ads, so this way I'm
> trying not to break existing code. The latter, BTW, currently has
> limited functionality and I _guess_ I will not break anything if only
> pq2ads_setup_pci remain. What do you think?
Not 100% sure. Maybe Wolfgang or someone else know what the existing=20
m8260 pci functionality is suppose to work with. It seems odd that it=20=
did not have some of the bits you added for the 8272ads. Its not clear=20=
to me if it actually worked on any systems or not. Let see if Wolfgang=20=
has any insight as a first step.
> Other issues will be fixed shortly.
Great.
- kumar
^ permalink raw reply
* Re: mtd mount problem
From: Marco Schramel @ 2005-04-21 13:02 UTC (permalink / raw)
To: PPC_LINUX
In-Reply-To: <20050421103234.ED367C1510@atlas.denx.de>
Hi,
> >
> > /dev # date > /dev/mtd1
> > MTD_open
> > MTD_ioctl
> > MTD_write
> > MTD do_write_buffer(): software timeout
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ERROR ERROR ERROR ERROR ERROR ERROR ERROR
This only occurs if i write the second time to the flash memory without erasing it before.
> What has a ramdisk to do with this?
I wrote in a message later, that i meant the /dev nodes in this case.
> What does "cat /proc/mtd" show? What are the kernel boot messages
> look like?
>
mtd0: 01000000 00020000 "JFFS2 partition 1"
mtd1: 00800000 00020000 "JFFS2 partition 2"
mtd2: 00400000 00020000 "RAMDISK "
mtd3: 00300000 00020000 "kernel image 2_4"
mtd4: 00100000 00020000 "Das U-Boot "
Best regards
Marco
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox