[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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