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
next 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).