1 |
Hi, |
2 |
|
3 |
Further to my previous message I believe I have narrowed the problem |
4 |
down to the following (see text below) commit. |
5 |
|
6 |
I am basing this diagnosis on the fact that I can boot any kernel before |
7 |
version 2.6.14, which was when this change was merged, with all more |
8 |
recent kernels (up to git-sources-2.6.19_rc1-r3) failing with similar |
9 |
but random error messages. Whilst there were other changes which could |
10 |
have caused this issue it seems like more than a coincidence to me that |
11 |
this problem appeared in the same version as a re-write of the SPARC64 |
12 |
boot-up sequence. |
13 |
|
14 |
Unfortunately I know absolutely no SPARC64 assembler (and what I can |
15 |
intuit from my, now woefully poorly, recollected knowledge of 6502 is |
16 |
limited ;-) so I am unable to pursue this issue much further, other than |
17 |
by filing a simple bug report obviously. |
18 |
|
19 |
I generally like to be a bit more helpful than that when I file a bug |
20 |
report though... Anyone have any ideas? |
21 |
|
22 |
Max |
23 |
|
24 |
---------------------------------------------------------------------- |
25 |
|
26 |
commit bff06d552240ba7f5b49482a4865871d7bc03dc2 |
27 |
Author: David S. Miller |
28 |
Date: Thu Sep 22 20:11:33 2005 -0700 |
29 |
|
30 |
[SPARC64]: Rewrite bootup sequence. |
31 |
|
32 |
Instead of all of this cpu-specific code to remap the kernel |
33 |
to the correct location, use portable firmware calls to do |
34 |
this instead. |
35 |
|
36 |
What we do now is the following in position independant |
37 |
assembler: |
38 |
|
39 |
chosen_node = prom_finddevice("/chosen"); |
40 |
prom_mmu_ihandle_cache = prom_getint(chosen_node, "mmu"); |
41 |
vaddr = 4MB_ALIGN(current_text_addr()); |
42 |
prom_translate(vaddr, &paddr_high, &paddr_low, &mode); |
43 |
prom_boot_mapping_mode = mode; |
44 |
prom_boot_mapping_phys_high = paddr_high; |
45 |
prom_boot_mapping_phys_low = paddr_low; |
46 |
prom_map(-1, 8 * 1024 * 1024, KERNBASE, paddr_low); |
47 |
|
48 |
and that replaces the massive amount of by-hand TLB probing and |
49 |
programming we used to do here. |
50 |
|
51 |
The new code should also handle properly the case where the kernel |
52 |
is mapped at the correct address already (think: future kexec |
53 |
support). |
54 |
|
55 |
Consequently, the bulk of remap_kernel() dies as does the entirety |
56 |
of arch/sparc64/prom/map.S |
57 |
|
58 |
We try to share some strings in the PROM library with the ones used |
59 |
at bootup, and while we're here mark input strings to oplib.h routines |
60 |
with "const" when appropriate. |
61 |
|
62 |
There are many more simplifications now possible. For one thing, we |
63 |
can consolidate the two copies we now have of a lot of cpu setup code |
64 |
sitting in head.S and trampoline.S. |
65 |
|
66 |
This is a significant step towards CONFIG_DEBUG_PAGEALLOC support. |
67 |
|
68 |
Signed-off-by: David S. Miller |
69 |
|
70 |
---------------------------------------------------------------------- |
71 |
On Fri, 2006-10-13 at 11:19 +0200, Martin Andersen wrote: |
72 |
> > Hi, |
73 |
> > |
74 |
> > |
75 |
> > I'm trying to get the latest 2006.1 Sparc Universal bootcd (downloaded |
76 |
> > yesterday) to run on some Blade2500 machines, without much success. I've tried |
77 |
> > the Silver & Non-Silver models, and both the provided kernels (2.6.16 & 2.6.17) |
78 |
> > |
79 |
> > Some basic info regarding the specs (a prtdiag -v is also attached) -- |
80 |
> > |
81 |
> > OpenBoot v4.17.1 |
82 |
> > 4096 Mb RAM |
83 |
> > XVR-1200 GFX module (SUNW,375-3101) |
84 |
> > Dual UltraSPARC IIIi 1280 Mhz CPUs |
85 |
> > Broadcom NIC (bge0 in Solaris) |
86 |
> > |
87 |
> > Some have both a XVR-1200 and a XVR-100 module installed (I've tested on both) |
88 |
> > The problem however seems to be related to the initial ramdisk -- |
89 |
> > |
90 |
> > |
91 |
> > <..begin BootPROM output..> |
92 |
> > |
93 |
> > Loading initial ramdisk (644214 bytes at 0x133F802000 phys, 0x40C00000 virt)... |
94 |
> > |
95 |
> > ERROR: Last Trap: Illegal Instruction |
96 |
> > |
97 |
> > Error -256 |
98 |
> > |
99 |
> > ERROR: Last Trap: Memory Address not Aligned |
100 |
> > |
101 |
> > |
102 |
> > <..end BootPROM output..> |
103 |
> > |
104 |
> > And then it throws you back to the ok prompt. Any suggestions? I'll be happy |
105 |
> > to test any experimental livecd's and/or possible BootPROM fixes (env. settings, |
106 |
> > disabling mem, etc.) I didn't do an asr-disable, as the previous problems seemed |
107 |
> > to have to do with having more than 4Gb mem, which isn't the issue here. |
108 |
> > |
109 |
> > |
110 |
> > Regards, |
111 |
> > |
112 |
> |
113 |
> Hi, |
114 |
> |
115 |
> I have a similar problem trying to boot any kernel more recent than |
116 |
> 2.6.11. I am currently net-booting a 2.6.11-r8 kernel which works fine. |
117 |
> |
118 |
> The errors which I have experienced so far include: |
119 |
> |
120 |
> Illegal Instruction |
121 |
> Memory Address not Aligned |
122 |
> Data Access Exception |
123 |
> Fast Instruction Access MMU Miss |
124 |
> IDPROM: Warning, unknown format type! |
125 |
> |
126 |
> They seem to change depending on the size of the kernel image which I am |
127 |
> attempting to boot and the version from which it was built. Other than |
128 |
> that there is no obvious rhyme nor reason. |
129 |
> |
130 |
> There is a forum post with similar (unresolved) issues here: |
131 |
> http://forums.gentoo.org/viewtopic-p-3642405.html |
132 |
> |
133 |
> If 2.6.11 was still in portage I would suggest that you tried that but |
134 |
> as it isn't.... |