[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] Microblaze with MMU, loadable module printk problems
An update on this problem. I tried running
with v0.30 of the Petalinux distro uclinux (non-MMU microblaze) and got
the same problem. I also modified the rng-core.ko module (random number
driver) included in the Petalinux Microblaze with MMU v0.10 to include
some printks, then used make "menuconfig" to turn the build of
the module on. I then loaded the resulting module using insmod. The output
of the printks was incorrect.
So, what I am seeing so far is that
I am unable to get reliable output from loadable modules running on Microblaze.
This includes modules that I didn't write and that I didn't compile (i.e.
makefiles for the rng-core.ko module were part of the distro). Has anyone
else actually seen valid printk or /proc output from a loadable module
running on Microblaze? My next step might be to compile my driver into
the kernel and see if printks work then.
Thanks in advance,
Jeff
Jeff Fuller
Software Engineer
EI WW SOFTWARE SYSTEMS ENGINEERING
Eastman Kodak Company
2400 Mt Read Blvd.
Rochester, NY 14650-3019
jeffrey.fuller@xxxxxxxxx
Office: (585)726-6908
www.kodak.com
jeffrey.fuller@xxxxxxxxx
Sent by: owner-microblaze-uclinux@xxxxxxxxxxxxxx
05/09/2008 09:16 AM
|
Please respond to
microblaze-uclinux@xxxxxxxxxxxxxx |
|
|
To
| microblaze-uclinux@xxxxxxxxxxxxxx
|
|
cc
| microblaze-uclinux@xxxxxxxxxxxxxx, owner-microblaze-uclinux@xxxxxxxxxxxxxx
|
|
Subject
| Re: [microblaze-uclinux] Microblaze
with MMU, loadable module printk problems |
|
Thanks for the response, Jim. Unfortunately, I have tried this and similar
things. Any sort of string, no matter how it's declared or how it's fed
to the printk or sprintf seems to be messed up.
Regards,
Jeff
Jeff Fuller
Software Engineer
EI WW SOFTWARE SYSTEMS ENGINEERING
Eastman Kodak Company
2400 Mt Read Blvd.
Rochester, NY 14650-3019
jeffrey.fuller@xxxxxxxxx
Office: (585)726-6908
www.kodak.com

Jim Van Vorst <jvanvorst@xxxxxxxxx>
Sent by: owner-microblaze-uclinux@xxxxxxxxxxxxxx
05/08/2008 05:30 PM
|
Please respond to
microblaze-uclinux@xxxxxxxxxxxxxx |
|
|
To
| microblaze-uclinux@xxxxxxxxxxxxxx
|
|
cc
|
|
|
Subject
| Re: [microblaze-uclinux] Microblaze
with MMU, loadable module printk problems |
|
That reminds me of a bug I found with declaring strings const, which probably
puts them in the same section as your #define does.
Have you tried changing your
#define STRING1 "blah"
to
char *string1 = "blah";
I know it sounds odd, but it fixed my problem.
jeffrey.fuller@xxxxxxxxx
wrote:
Hi All,,
We're working on bringing up Petalinux Microblaze with MMU v0.10 distro
on a custom board. Part of this is the development of a loadable module
device driver. So far, we've been able to insmod and rmmod the .ko file,
as well as create a /proc entry. We haven't gotten much farther because
of a serious issue we're seeing.
It appears that strings are not being handled correctly in the module.
I don't have any strong ideas about what's going on, but I do have a simple
program that demonstrates this problem:
================================================================================
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <asm/uaccess.h>
#include <linux/fs.h>
#include <linux/proc_fs.h>
#define STRING1 "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20\n"
#define STRING2 "a b c d e f g h i j k l m n
o p q r s t \n"
int
NspbProc(char *page,
char **start,
off_t offset,
int count,
int *eof,
void *data)
{
int length = 0;
length += sprintf(page + length, "%s", STRING1);
length += sprintf(page + length, "%s", STRING2);
*eof = 1;
return length;
}
static int __init
NspbInit(void)
{
create_proc_read_entry("nspb", 0, NULL, NspbProc, NULL);
printk("%s", STRING1);
printk("%s", STRING2);
return 0;
}
module_init(NspbInit);
static void __exit
NspbCleanup(void)
{
remove_proc_entry("nspb", NULL);
}
module_exit(NspbCleanup);
================================================================================
Here's what happens when we load the above module (using busybox insmod
- we also have syslogd and klogd running):
#insmod nspb.ko
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
#
Here is what was expected:
#insmod nspb.ko
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
a b c d e f g h i j k l m n o p q
r s t
#
Further, doing a cat of the driver's proc file (cat /proc/nspb) produces
the exact same output as the printks do. This seems to eliminate the printk
function as the cause of the problem.
I didn't choose the values of STRING1 and STRING2 for any special reason.
You can mess around with the values and get varying results, none of which
are correct. You can also try printing string literals directly (e.g. print("some
string\n") or printing a string in any way you can think of, and get
incorrect results. In the above code, if I comment out the printk and sprintf
of STRING1, I get this:
c d e f g h i j k l m n o p q
r s t
Again, incorrect, and I'm not sure if you'd get the same thing, but whatever
you got, it would likely be wrong. Bottom line is that I've tried printing
all sorts of different strings in all sorts of different ways and very
few of them seem to come out correct. Here is one more example of incorrect
behavior:
1. Comment out the #define STRING 1 and STRING2 macros.
2. Comment out the 2 printk and sprintf calls.
3. Add this to the proc function:
length += sprintf(page + length, "somestring1\n");
length += sprintf(page + length, "somestring2\n");
length += sprintf(page + length, "somestring3\n");
length += sprintf(page + length, "somestring4\n");
4. Add this to the NspbInit fucntion:
printk("somestring1\n");
printk("somestring2\n");
printk("somestring3\n");
printk("somestring4\n");
5. Load the module.
I get this output from the NspbInit function's printks:
ng1
ng3
I get the same output from /proc/nspb. So, two of the strings are not printed
at all, and the two that are appear truncated. I had some luck in printing
integers (e.g. printk("%d", someInt)) but upon trying to do this
again when preparing these examples, I got incorrect results, so I am not
sure what might be going on with that.
Two other notes as a general FYI to anyone who might be working on the
next petalinux distro. Our actual driver will use the ioremap, iounmap,
copy_from_user, and copy_to_user functions. Those functions, however, are
not exported, causing compile warnings and load errors. We had to add the
following to software/linux-2.6.x-petalogix/arch/microblaze/kernel/microblaze_ksyms.c
to get things working:
EXPORT_SYMBOL(__copy_user);
EXPORT_SYMBOL(ioremap);
EXPORT_SYMBOL(iounmap);
I expect there might be more symbols missing, as well.
Finally, we also had to fix a syntax error in software/linux-2.6.x-petalogix/arch/microblaze/kernel/module.c,
line 99, where there was an extra parenthesis.
Thanks in advance for any help!
Jeff
Jeff Fuller
Software Engineer
EI WW SOFTWARE SYSTEMS ENGINEERING
Eastman Kodak Company
2400 Mt Read Blvd.
Rochester, NY 14650-3019
jeffrey.fuller@xxxxxxxxx
Office: (585)726-6908
www.kodak.com