Commit Graph

10 Commits

Author SHA1 Message Date
David Woodhouse
62c4f0a2d5 Don't include linux/config.h from anywhere else in include/
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-04-26 12:56:16 +01:00
David S. Miller
90a6646bf6 [SPARC64]: Fix system type in /proc/cpuinfo and remove bogus OBP check.
Report 'sun4v' when appropriate in /proc/cpuinfo

Remove all the verifications of the OBP version string.  Just
make sure it's there, and report it raw in the bootup logs and
via /proc/cpuinfo.

Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 01:14:25 -08:00
David S. Miller
7890f794e0 [SPARC64]: Add prom_{start,stop}cpu_cpuid().
Use prom_startcpu_cpuid() on SUN4V instead of prom_startcpu().

We should really test for "SUNW,start-cpu-by-cpuid" presence
and use it if present even on SUN4U.

Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 01:13:04 -08:00
David S. Miller
1a7a242c89 [SPARC64]: Recognize "virtual-console" as input and output console device.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 01:12:28 -08:00
David S. Miller
12eaa328f9 [SPARC64]: Use ASI_SCRATCHPAD address 0x0 properly.
This is where the virtual address of the fault status
area belongs.

To set it up we don't make a hypervisor call, instead
we call OBP's SUNW,set-trap-table with the real address
of the fault status area as the second argument.  And
right before that call we write the virtual address into
ASI_SCRATCHPAD vaddr 0x0.

Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 01:12:15 -08:00
David S. Miller
d82ace7dc4 [SPARC64]: Detect sun4v early in boot process.
We look for "SUNW,sun4v" in the 'compatible' property
of the root OBP device tree node.

Protect every %ver register access, to make sure it is
not touched on sun4v, as %ver is hyperprivileged there.

Lock kernel TLB entries using hypervisor calls instead of
calls into OBP.

Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20 01:12:03 -08:00
Eddie C. Dost
c126cf80d4 [SPARC64]: Serial Console for E250 Patch
From: Eddie C. Dost <ecd@brainaid.de>

I have the following patch for serial console over the RSC
(remote system controller) on my E250 machine. It basically adds
support for input-device=rsc and output-device=rsc from OBP, and
allows 115200,8,n,1,- serial mode setting.

Signed-off-by: David S. Miller <davem@davemloft.net>
2006-01-18 14:54:31 -08:00
David S. Miller
4cb29d1812 [SPARC64]: Kill arch/sparc64/prom/memory.c
No longer used.

Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-29 18:05:28 -07:00
David S. Miller
bff06d5522 [SPARC64]: Rewrite bootup sequence.
Instead of all of this cpu-specific code to remap the kernel
to the correct location, use portable firmware calls to do
this instead.

What we do now is the following in position independant
assembler:

	chosen_node = prom_finddevice("/chosen");
	prom_mmu_ihandle_cache = prom_getint(chosen_node, "mmu");
	vaddr = 4MB_ALIGN(current_text_addr());
	prom_translate(vaddr, &paddr_high, &paddr_low, &mode);
	prom_boot_mapping_mode = mode;
	prom_boot_mapping_phys_high = paddr_high;
	prom_boot_mapping_phys_low = paddr_low;
	prom_map(-1, 8 * 1024 * 1024, KERNBASE, paddr_low);

and that replaces the massive amount of by-hand TLB probing and
programming we used to do here.

The new code should also handle properly the case where the kernel
is mapped at the correct address already (think: future kexec
support).

Consequently, the bulk of remap_kernel() dies as does the entirety
of arch/sparc64/prom/map.S

We try to share some strings in the PROM library with the ones used
at bootup, and while we're here mark input strings to oplib.h routines
with "const" when appropriate.

There are many more simplifications now possible.  For one thing, we
can consolidate the two copies we now have of a lot of cpu setup code
sitting in head.S and trampoline.S.

This is a significant step towards CONFIG_DEBUG_PAGEALLOC support.

Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-22 20:11:33 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00