ixdp4xx restart. watchdog enable value

ixdp4xx restart. watchdog enable value

[Ara Avanesyan]

in file: include/asm-arm/arch-ixp4x//system.h
function: arch_reset

code snap --
/* disable watchdog interrupt, enable reset, enable count */
*IXP4XX_OSWE = 0x3;
--

according to intel's documentation the appropriate bits are in the
following order:
bit 2: wdog_cnt_ena
bit 1: wdog_int_ena
bit 0: wdog_rst_ena

so the above assigned value should be 101b == 0x5.
I do not know why 0x3 works at all. Btw, u-boot assigns 0x5.

This is for all kernels I had a chance to look at (2.4.20-2.6.10).

__
Thanks,
Ara

Re: ixdp4xx restart. watchdog enable value

[Ben Dooks]

On Thu, Jan 27, 2005 at 06:40:17PM +0400, Ara Avanesyan wrote:
> in file: include/asm-arm/arch-ixp4x//system.h
> function: arch_reset
> 
> code snap --
> /* disable watchdog interrupt, enable reset, enable count */
> *IXP4XX_OSWE = 0x3;
> --
> 
> according to intel's documentation the appropriate bits are in the
> following order:
> bit 2: wdog_cnt_ena
> bit 1: wdog_int_ena
> bit 0: wdog_rst_ena
> 
> so the above assigned value should be 101b == 0x5.
> I do not know why 0x3 works at all. Btw, u-boot assigns 0x5.
> 
> This is for all kernels I had a chance to look at (2.4.20-2.6.10).

Best place to air this is linux-arm-kernel@lists.arm.linux.org.uk
where all ARM kernel related discussions go on.

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: ixdp4xx restart. watchdog enable value

[David Vrabel]

Ara Avanesyan wrote:
> in file: include/asm-arm/arch-ixp4x//system.h
> function: arch_reset
> 
> code snap --
> /* disable watchdog interrupt, enable reset, enable count */
> *IXP4XX_OSWE = 0x3;
> --

See:

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=2437

> I do not know why 0x3 works at all. Btw, u-boot assigns 0x5.

The count enable bit is irrelevant as the counter is initialized to
zero.

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

Strange memory problem with Linux booted from U-Boot

[Ara Avanesyan]

Hi,

I need some help on solving this strange problem.
Here is what I have,
I have a loadable module (linux.2.4.20) which contains a 2 mb static gloabal
array.
When I load it from linux booted via U-Boot the system crashes.
Everything works ok if I do the same thing with the same linux booted with
RedBoot.
Before loading the module I check the current meminfo and get the same
result both times.

Additional information:
The same error occurs if I just run depmod -a.

system: Avila board 64 MB RAM, ixdp425 architecture, U-Boot: 1.1.2.
Linux is MontaVista(R) Linux(R) Professional Edition 3.1.

Ok, now an amazing reproduction of the same problem from user mode:
the code below works for val = (~0), but not for 0, or even (~ff).
Again, it works fine for linux booted from RedBoot.

Some glue or something where and what to look?
Any ideas of what potentially could cause this problem?

Please CC me on reply.

Thanks!
Ara

Several days ago I posted this question to U-boot mailing list but got not
much help there:)

____
error message:
Unable to handle kernel paging request at virtual address e59f30f8
mm = c000a320 pgd = c3e60000
*pgd = 00000000, *pmd = 00000000
Internal error: Oops: 0
CPU: 0
pc 2 [<c0054f64>]    lr : [<00000000>]    Tainted: GF
sp : c3e45e94  ip : c3e45eb4  fp : c3e45eb0
r10: 00000000  r9 : c3e45f04  r8 : 00000004
r7 : 00000004  r6 : c016a000  r5 : c3e44000  r4 : e59f3054
r3 : e91ba870  r2 : c019cc70  r1 : 00000000  r0 : 00000000
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32 Control: 39FF  Table: 03E60000
DAC: 00000015
Process klogd (pid: 89, stack limit = 0xc3e443a0)
Stack: (0xc3e45e94 to 0xc3e46000)

___
Now the (user level) code:

#include <iostream>

using namespace std;

const int pass = 64;
const int size = 2 * 1024 * 1024;
const int val = 0xffffff00;
int main()
{
    cout << "starting val == " << hex << val << endl;
    char *buf = new char[size];
    cout << "allocated memory of " << size << " bytes. buf == " << (int)buf
<< endl;

    for (int j = 0; j < pass; j++)
    {
        cout << "passing " << j << endl;
        for (int i = 0; i < size; i++)
        {
            buf[i] = val;
        }
        cout << "passed" << endl;
    }

    cout << "freeing" << endl;
    delete []buf;
    cout << "finished!" << endl;
    return 0;
}

Re: Strange memory problem with Linux booted from U-Boot

[Jan Engelhardt]

>Hi,
>
>I need some help on solving this strange problem.
>Here is what I have,
>I have a loadable module (linux.2.4.20) which contains a 2 mb static gloabal
>array.
>
>Additional information:
>The same error occurs if I just run depmod -a.

I'd be more interested in the kernel space code...



Jan Engelhardt
-- 
No TOFU for me, please.

Re: Strange memory problem with Linux booted from U-Boot

[linux-os]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3248 bytes --]


I tried your program with several 'val' values including ~0 and
0. The results were the same. In spite of using character pointers
on large negative integers, everything worked. What was the observed
kernel problem?? Perhaps, the kernel's printk() was not as kind
as g++ and you got some strange printed results??

On Mon, 28 Mar 2005, Ara Avanesyan wrote:

> Hi,
>
> I need some help on solving this strange problem.
> Here is what I have,
> I have a loadable module (linux.2.4.20) which contains a 2 mb static gloabal
> array.
> When I load it from linux booted via U-Boot the system crashes.
> Everything works ok if I do the same thing with the same linux booted with
> RedBoot.
> Before loading the module I check the current meminfo and get the same
> result both times.
>
> Additional information:
> The same error occurs if I just run depmod -a.
>
> system: Avila board 64 MB RAM, ixdp425 architecture, U-Boot: 1.1.2.
> Linux is MontaVista(R) Linux(R) Professional Edition 3.1.
>
> Ok, now an amazing reproduction of the same problem from user mode:
> the code below works for val = (~0), but not for 0, or even (~ff).
> Again, it works fine for linux booted from RedBoot.
>
> Some glue or something where and what to look?
> Any ideas of what potentially could cause this problem?
>
> Please CC me on reply.
>
> Thanks!
> Ara
>
> Several days ago I posted this question to U-boot mailing list but got not
> much help there:)
>
> ____
> error message:
> Unable to handle kernel paging request at virtual address e59f30f8
> mm = c000a320 pgd = c3e60000
> *pgd = 00000000, *pmd = 00000000
> Internal error: Oops: 0
> CPU: 0
> pc 2 [<c0054f64>]    lr : [<00000000>]    Tainted: GF
> sp : c3e45e94  ip : c3e45eb4  fp : c3e45eb0
> r10: 00000000  r9 : c3e45f04  r8 : 00000004
> r7 : 00000004  r6 : c016a000  r5 : c3e44000  r4 : e59f3054
> r3 : e91ba870  r2 : c019cc70  r1 : 00000000  r0 : 00000000
> Flags: nzCv  IRQs on  FIQs on  Mode SVC_32 Control: 39FF  Table: 03E60000
> DAC: 00000015
> Process klogd (pid: 89, stack limit = 0xc3e443a0)
> Stack: (0xc3e45e94 to 0xc3e46000)
>
> ___
> Now the (user level) code:
>
> #include <iostream>
>
> using namespace std;
>
> const int pass = 64;
> const int size = 2 * 1024 * 1024;
> const int val = 0xffffff00;
> int main()
> {
>    cout << "starting val == " << hex << val << endl;
>    char *buf = new char[size];
>    cout << "allocated memory of " << size << " bytes. buf == " << (int)buf
> << endl;
>
>    for (int j = 0; j < pass; j++)
>    {
>        cout << "passing " << j << endl;
>        for (int i = 0; i < size; i++)
>        {
>            buf[i] = val;
>        }
>        cout << "passed" << endl;
>    }
>
>    cout << "freeing" << endl;
>    delete []buf;
>    cout << "finished!" << endl;
>    return 0;
> }
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1661 bytes --]

Script started on Mon 28 Mar 2005 11:12:26 AM EST
LINUX> g++ -o xxx -Wall -O2 xxx.cpp
LINUX> ./xxx
starting val == ffffffff
allocated memory of 200000 bytes. buf == b7dde008
passing 0
passed
passing 1
passed
passing 2
passed
passing 3
passed
passing 4
passed
passing 5
passed
passing 6
passed
passing 7
passed
passing 8
passed
passing 9
passed
passing a
passed
passing b
passed
passing c
passed
passing d
passed
passing e
passed
passing f
passed
passing 10
passed
passing 11
passed
passing 12
passed
passing 13
passed
passing 14
passed
passing 15
passed
passing 16
passed
passing 17
passed
passing 18
passed
passing 19
passed
passing 1a
passed
passing 1b
passed
passing 1c
passed
passing 1d
passed
passing 1e
passed
passing 1f
passed
passing 20
passed
passing 21
passed
passing 22
passed
passing 23
passed
passing 24
passed
passing 25
passed
passing 26
passed
passing 27
passed
passing 28
passed
passing 29
passed
passing 2a
passed
passing 2b
passed
passing 2c
passed
passing 2d
passed
passing 2e
passed
passing 2f
passed
passing 30
passed
passing 31
passed
passing 32
passed
passing 33
passed
passing 34
passed
passing 35
passed
passing 36
passed
passing 37
passed
passing 38
passed
passing 39
passed
passing 3a
passed
passing 3b
passed
passing 3c
passed
passing 3d
passed
passing 3e
passed
passing 3f
passed
freeing
finished!
LINUX> exit

Script done on Mon 28 Mar 2005 11:12:59 AM EST

Re: Strange memory problem with Linux booted from U-Boot

[Ara Avanesyan]

----- Original Message ----- 
From: "Jan Engelhardt" <jengelh@linux01.gwdg.de>
To: "Ara Avanesyan" <araav@hylink.am>
Cc: <linux-kernel@vger.kernel.org>; <avila@lists.unixstudios.net>
Sent: Monday, March 28, 2005 8:06 PM
Subject: Re: Strange memory problem with Linux booted from U-Boot


> >Hi,
> >
> >I need some help on solving this strange problem.
> >Here is what I have,
> >I have a loadable module (linux.2.4.20) which contains a 2 mb static
gloabal
> >array.
> >
> >Additional information:
> >The same error occurs if I just run depmod -a.
>
> I'd be more interested in the kernel space code...
>
>
>
> Jan Engelhardt
> -- 
> No TOFU for me, please.
>

Oh, the code for kernel space is exactly the same code translated to C:
That is:

___________
#include <linux/vmalloc.h>

void mtestit(char val)
{
    char *buf;
    int i, j;
    int size = 64;
    int pass = 2 * 1024 * 1024;
    printk("starting val == %x\n", val);
    buf = vmalloc(size);
    printk("allocated memory of %d bytes. buf == %x\n", size, (int)buf);

    for (j = 0; j < pass; j++)
    {
        printk("passing %d", j);
        for (i = 0; i < size; i++)
        {
            buf[i] = val;
        }
        printk("passed\n");
    }

    printk("freeing\n");
    vfree(buf);
    printk("finished!\n");
}
___________

I call this in a module's entry point and insmod that module.
now, mtestit(0xff) works, but mtestit(0x00) crashes:(
Works fine with RedBoot. Very strange to me:)
Moreover, works fine if I do the very same thing from
within U-Boot (mw.b 100000 0 100000).

I'm interested in ideas of what could potentially be the
cause of this strange behaviour.

__
Thanks,
Ara

Re: Strange memory problem with Linux booted from U-Boot

[Eugene Surovegin]

On Mon, Mar 28, 2005 at 07:57:52PM +0500, Ara Avanesyan wrote:
> Hi,
> 
> I need some help on solving this strange problem.
> Here is what I have,
> I have a loadable module (linux.2.4.20) which contains a 2 mb static gloabal
> array.
> When I load it from linux booted via U-Boot the system crashes.
> Everything works ok if I do the same thing with the same linux booted with
> RedBoot.

As usual for such problems, check how different firmware configure 
memory controller, etc. Get dump of relevant chip registers under 
U-Boot and RedBoot and compare them.

Other possible problem area can be firmware -> kernel interface. I'm 
not familiar with that particular chip and RedBoot, but it's not 
uncommon for different firmware to have different conventions for the 
environment in which kernel starts execution.

I'd recommend posting to the specific mail-lists, lkml doesn't seem 
a good place for embedded and firmware related questions :)

--
Eugene

Re: Strange memory problem with Linux booted from U-Boot

[Ara Avanesyan]

> On Mon, Mar 28, 2005 at 07:57:52PM +0500, Ara Avanesyan wrote:
> > Hi,
> >
> > I need some help on solving this strange problem.
> > Here is what I have,
> > I have a loadable module (linux.2.4.20) which contains a 2 mb static
gloabal
> > array.
> > When I load it from linux booted via U-Boot the system crashes.
> > Everything works ok if I do the same thing with the same linux booted
with
> > RedBoot.
>
> As usual for such problems, check how different firmware configure
> memory controller, etc. Get dump of relevant chip registers under
> U-Boot and RedBoot and compare them.
>
> Other possible problem area can be firmware -> kernel interface. I'm
> not familiar with that particular chip and RedBoot, but it's not
> uncommon for different firmware to have different conventions for the
> environment in which kernel starts execution.
>
> I'd recommend posting to the specific mail-lists, lkml doesn't seem
> a good place for embedded and firmware related questions :)
>
> --
> Eugene
>

Eugene,

Thanks for your response and ideas.
Actually the problem is concerning to linux part as the same code works fine
within U-Boot as I posted before. This is why I asked lkml for help what
might
cause this behaviour.

__
Thanks,
Ara