[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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