/dev/flash and MTD
In message <3D540B52.8080709 at redswitch.com> you wrote: > To enable MTD on a board, do we still need /dev/flash? In other words, No, this is not needed for MTD. It's an alternative interface to access flash memory; we mostly keep it for compatibility with older projects, and because it provides some nice features like allowing to mmap() the flash (RO). > is there any relationship between /dev/flash and MTD? I found that only > on Denx distribution of 2.4.4 there is such a device '/dev/flash'. Thanks. These are two independend solutions to the task of providing access to flash memory; MTD is superior when you also need a block device interface. Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de When you say "I wrote a program that crashed Windows", people just stare at you blankly and say "Hey, I got those with the system, *for free*".- Linus Torvalds in <3itc77$9lj at ninurta.fer.uni-lj.si> ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
platform support for a bk version?
You need to choose the revision where 2.4.19 has been merged into the main tree. Chosing the tag in theory gives you the official tree. Use bk revtool to find the revision (find the first 1.xxx number vs 1.xxx.x.xx). milton ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MTD/JFFS2 on Intel 28F160F3
> > The basic problem is what the physical start address of flash mapping > is? While on PPCBoot, I got flash information using command 'flinfo'. > The start address is FFE0. Is this address the one used to configure > CFI flash device in physical memeory map? I tried using this address but > 'physmap' couldn't find flash device. It is not a must that the address mapping in PPCBoot is the same as in the kernel. What board are you using ? ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
/dev/flash and MTD
> To enable MTD on a board, do we still need /dev/flash? No. > In other words, is there any relationship between /dev/flash and > MTD? I found that only on Denx distribution of 2.4.4 there is such a > device '/dev/flash'. Thanks. The /dev/flash device entries use a stand alone flash driver that isn't part of MTD. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
First steps to OCP device model integration
THe patch below implements the first steps in transitioning the
handling of 4xx OCP devices to the unfied device model (in 2.5). So
far the code just registers an ocp bus and registers each device
described in core_ocp on that bus. The next step is to convert the
actual device drivers so that that they register with the unified
driver tree rather than through the old ocp_register() mechanism.
I will commit this shortly unless there are serious objections.
diff -urN /home/dgibson/kernel/linuxppc-2.5/drivers/ocp/ocp.c
linux-bluefish/drivers/ocp/ocp.c
--- /home/dgibson/kernel/linuxppc-2.5/drivers/ocp/ocp.c 2002-08-09
11:28:27.0 +1000
+++ linux-bluefish/drivers/ocp/ocp.c2002-08-09 13:55:08.0 +1000
@@ -69,6 +69,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -388,3 +390,58 @@
EXPORT_SYMBOL(ocp_free_dev);
EXPORT_SYMBOL(ocp_register);
EXPORT_SYMBOL(ocp_unregister);
+
+/* Unified device model OCP interface */
+
+static int ocp_bus_match(struct device * dev, struct device_driver * drv)
+{
+ struct ocp_device *odev = to_ocp_dev(dev);
+ struct ocp_driver *odrv = to_ocp_driver(drv);
+
+ return (odrv->type == odev->def.type);
+}
+
+struct bus_type ocp_bus_type = {
+ name: "ocp",
+ match: ocp_bus_match,
+};
+
+static struct device ocp_bus = {
+ name: "IBM4xx On-Chip Peripheral Bus",
+ bus_id: "ocp",
+};
+
+static int __init ocp_bus_init(void)
+{
+ int i;
+
+ printk(KERN_DEBUG "OCP: Registering OCP bus and devices\n");
+
+ if (bus_register(&ocp_bus_type) != 0)
+ panic("Couldn't register OCP bus type\n");
+ if (device_register(&ocp_bus) != 0)
+ panic("Couldn't register OCP bus\n");
+
+ for (i = 0; core_ocp[i].type != OCP_NULL_TYPE; i++) {
+ enum ocp_type type = core_ocp[i].type;
+ struct ocp_device *odev;
+
+ odev = kmalloc(sizeof(*odev), GFP_KERNEL);
+ if (! odev)
+ panic("unable to allocate memory for ocp_device\n");
+ memset(odev, 0, sizeof(*odev));
+
+ memcpy(&odev->def, &core_ocp[i], sizeof(struct ocp_def));
+
+ odev->dev.bus = &ocp_bus_type;
+ odev->dev.parent = &ocp_bus;
+ strcpy(odev->dev.name, ocp_type_info[type].desc);
+ sprintf(odev->dev.bus_id, "%d:%s", i, ocp_type_info[type].name);
+
+ device_register(&odev->dev);
+ }
+
+ return 0;
+}
+
+postcore_initcall(ocp_bus_init);
diff -urN /home/dgibson/kernel/linuxppc-2.5/include/asm-ppc/ocp.h
linux-bluefish/include/asm-ppc/ocp.h
--- /home/dgibson/kernel/linuxppc-2.5/include/asm-ppc/ocp.h 2002-08-08
11:20:50.0 +1000
+++ linux-bluefish/include/asm-ppc/ocp.h2002-08-09 14:00:46.0
+1000
@@ -51,6 +51,7 @@
#include
#include
+#include
#include/* For phys_addr_t */
@@ -158,5 +159,21 @@
extern int ocp_get_irq(int type, int dev_num);
extern int ocp_get_pm(int type, int dev_num);
+/* Unified device model OCP interface */
+
+struct ocp_device {
+ struct ocp_def def;
+ struct device dev;
+};
+
+struct ocp_driver {
+ enum ocp_type type;
+ struct device_driver driver;
+};
+
+#defineto_ocp_dev(n) container_of(n, struct ocp_device, dev)
+#defineto_ocp_driver(n) container_of(n, struct ocp_driver, driver)
+
+
#endif /* __OCP_H__ */
#endif /* __KERNEL__ */
--
David Gibson| For every complex problem there is a
david at gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
platform support for a bk version?
I have noticed if you 'bk clone' a specific revision from the linuxppc_2_4_devel tree, you do not get all the arch/ppc/platform support. How do you retrieve a specific revision, such as tag v2.4.19 and get all the platform support too? TIA Allen Curtis | All good things come to those Ones and Zeros, Inc. | who wait. Some of us have to mailto:acurtis at onz.com| wait a little longer. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
platform support for a bk revision?
I have noticed if you 'bk clone' a specific revision from the linuxppc_2_4_devel tree, you do not get all the arch/ppc/platform support. How do you retrieve a specific revision, such as tag v2.4.19 and get all the platform support too? TIA Allen Curtis | All good things come to those Ones and Zeros, Inc. | who wait. Some of us have to mailto:acurtis at onz.com| wait a little longer. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
First steps to OCP device model integration
David Gibson wrote: > THe patch below implements the first steps in transitioning the > handling of 4xx OCP devices to the unfied device model (in 2.5). So > far the code just registers an ocp bus and registers each device > described in core_ocp on that bus. The next step is to convert the > actual device drivers so that that they register with the unified > driver tree rather than through the old ocp_register() mechanism. > > I will commit this shortly unless there are serious objections. > I object seriously. Some of what you have might be useful.:) OCP is not just for 4xx. In fact the name may need to change. I have been working on overhalling this interface and testing the ideas before having a review of the changes. I am on the hook to Paul and others to get this out in the open to discuss and am not ready. So if you could just relax and wait I would appriciate it. I would rather see the 2.5 kernel boot on a few 4xx boards Armin ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Tigon3 driver, broadcom 5307, 440GP, working? (solved)
I wrote: > > I've been playing around with the tigon3 driver and a broadcom > > 5307 [5703, I meant] gigabit NIC in my IBM ebony... No luck so far. and > Ok, I have determined that my problem lies in user-land, not > the kernel. Heh. The reason it couldn't ping it's own IP address? I forgot to ifconfig the loopback interface, duh. ifconfig lo 127.0.0.1 makes it all work. (Sometimes the easy ones are the hardest.) Thanks, -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
debugging kernel modules
In message <20020809010652.6470.qmail at web40201.mail.yahoo.com> you wrote: > > With GDB-5.2, after adding symbols, GDB can't find > line numbers for my module source code. However > 'powerpc-linux-objdump -S -l fs/fat/fat.o' shows line > numbers just fine. Wolfgang, on your page you used > GDB-5.1.1. Ever see this problem? We saw, and fixed, this, and other problems. The GDB that comes with our ELDK contains a couple of bug fixes and extensions: - module debugging: there were some issues, including the problem you mentioned - thread support: you can use our GDB / gdbserver to debug multi-threaded applications - gdbserver with "remote shell" extension: you can use our GDB / gdbserver to execute commands on the target, for example in cases where you don;t have a login or other shell running - gdbserver in "server mode": you can start our gdbserver as a "real" server, i. e. without a process to debug, and use it later to attach to _any_ running process(es) onthe target For example, on a couple of systems we start a gdbserver from the inittab, and if we suspect a process goes haywire we use "rsh ps" to run the "ps" command on the target to get the PIDs of the running processes, and then we use "attach " to attach to the suspect process Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de "If you can, help others. If you can't, at least don't hurt others." - the Dalai Lama ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
