linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "David Baird" <dhbaird@gmail.com>
To: linuxppc-embedded@ozlabs.org
Subject: Problem booting Linux 2.6 on Virtex-4
Date: Sun, 13 Jan 2008 22:12:38 -0700	[thread overview]
Message-ID: <440abda90801132112y76f2899by4ef582c9b58fd6b6@mail.gmail.com> (raw)

Hi,

I'm having trouble with getting Linux to boot farther than early_init.
 Things start to go obviously wrong after early_init calls memset to
clear the .bss section.  The first symptom I noticed was that the
stack (which currently contains the link register) was getting zeroed
by memset.  This doesn't make any sense because the stack does not
intersect the .bss section;  I confirmed that the do not intersect by
using JTAG+xmd to read the registers and also by inserting print
statements.

So, I experimented further and discovered that different memory
regions seem to be aliased on to each other every 2*32*256 bytes.

e.g.:

    char * ptr = 0;
    unsigned long addr = 0xc0001234; // pick some address
    int n = 1; // pick some integer

    // Now write values to two different addresses:
    ptr[addr] = 42;
    ptr[addr + n*2*32*256] = 24;
    volatile asm ("nop");

    // Now mysteriously, ptr[addr] == 24

The reason I have written 32*256 is because that corresponds to the
number of bytes per cache line times the number of cache lines ...
because I was suspicious this might be related to caching.  However,
with experimentation, I found that the aliasing does not occur every
32*256 bytes, but rather every 32*512 bytes (hence 2*32*256).
Anyways, I looked in embed_config (and confirmed by dumping zImage.elf
with objdump) that the cache is being invalidated with "dccci".
"dccci" is being called, as expected, and therefore everything looks
good in the code.

I am completely perplexed.  The cache appears to be initialized
properly.  I don't have any trouble in real mode.  But as soon the
kernel switches into virtual mode (in head_4xx.S), then this memory
aliasing problem happens.  I wrote a completely standalone assembler
script that initializes the cache, TLBs, and virtual mode in the same
way as embed_config and head_4xx.S and so I am able to reproduce the
problem outside of the kernel.  I can attach that code if someone
thinks it will be useful - just let me know.

Does anyone have an idea about what might be going wrong?  I can send
more information or test anything that you want me to.

-David

             reply	other threads:[~2008-01-14  5:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-14  5:12 David Baird [this message]
2008-01-14  8:37 ` Problem booting Linux 2.6 on Virtex-4 Enno Lübbers
2008-01-14 20:11   ` David Baird
2008-01-14 21:09     ` Stephen Neuendorffer
2008-01-15  0:14       ` David Baird
2008-01-15  7:24         ` Enno Lübbers
2008-01-14 23:49     ` David Baird

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=440abda90801132112y76f2899by4ef582c9b58fd6b6@mail.gmail.com \
    --to=dhbaird@gmail.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).