20 May, 2008

1 commit


19 Feb, 2008

1 commit

  • The idea of this thing is we could save/restore the firmware's
    palette when breaking in and out of the firmware prompt.

    Only one driver implemented this (atyfb) and it's value is
    questionable. If you're just debugging you don't really
    care that the characters end up being purple or whatever.

    And we can provide better debugging and firmware command
    facilities with minimal in-kernel console I/O drivers.

    Signed-off-by: David S. Miller

    David S. Miller
     

07 Feb, 2008

1 commit

  • The early per-cpu handling needs a slight tweak to work when booting
    on a non-zero cpu.

    We got away with this for a long time, but can't any longer as now
    even printk() calls functions (cpu_clock() for example) that thus make
    early references to per-cpu variables.

    Signed-off-by: David S. Miller

    David S. Miller
     

27 Oct, 2007

1 commit


17 Sep, 2007

1 commit

  • As noted by Al Viro, when we try to call prom_set_trap_table()
    in the SMP trampoline code we try to take the PROM call spinlock
    which doesn't work because the current thread pointer isn't
    valid yet and lockdep depends upon that being correct.

    Furthermore, we cannot set the current thread pointer register
    because it can't be properly dereferenced until we return from
    prom_set_trap_table(). Kernel TLB misses only work after that
    call.

    So do the PROM call to set the trap table directly instead of
    going through the OBP library C code, and thus avoid the lock
    altogether.

    These calls are guarenteed to be serialized fully.

    Since there are now no calls to the prom_set_trap_table{_sun4v}()
    library functions, they can be deleted.

    Signed-off-by: David S. Miller

    David S. Miller
     

21 Jul, 2007

1 commit

  • The current scheme works on static interpretation of text names, which
    is wrong.

    The output-device setting, for example, must be resolved via an alias
    or similar to a full path name to the console device.

    Paths also contain an optional set of 'options', which starts with a
    colon at the end of the path. The option area is used to specify
    which of two serial ports ('a' or 'b') the path refers to when a
    device node drives multiple ports. 'a' is assumed if the option
    specification is missing.

    This was caught by the UltraSPARC-T1 simulator. The 'output-device'
    property was set to 'ttya' and we didn't pick upon the fact that this
    is an OBP alias set to '/virtual-devices/console'. Instead we saw it
    as the first serial console device, instead of the hypervisor console.

    The infrastructure is now there to take advantage of this to resolve
    the console correctly even in multi-head situations in fbcon too.

    Thanks to Greg Onufer for the bug report.

    Signed-off-by: David S. Miller

    David S. Miller
     

16 Jul, 2007

2 commits

  • Only adding cpus is supports at the moment, removal
    will come next.

    When new cpus are configured, the machine description is
    updated. When we get the configure request we pass in a
    cpu mask of to-be-added cpus to the mdesc CPU node parser
    so it only fetches information for those cpus. That code
    also proceeds to update the SMT/multi-core scheduling bitmaps.

    cpu_up() does all the work and we return the status back
    over the DS channel.

    CPUs via dr-cpu need to be booted straight out of the
    hypervisor, and this requires:

    1) A new trampoline mechanism. CPUs are booted straight
    out of the hypervisor with MMU disabled and running in
    physical addresses with no mappings installed in the TLB.

    The new hvtramp.S code sets up the critical cpu state,
    installs the locked TLB mappings for the kernel, and
    turns the MMU on. It then proceeds to follow the logic
    of the existing trampoline.S SMP cpu bringup code.

    2) All calls into OBP have to be disallowed when domaining
    is enabled. Since cpus boot straight into the kernel from
    the hypervisor, OBP has no state about that cpu and therefore
    cannot handle being invoked on that cpu.

    Luckily it's only a handful of interfaces which can be called
    after the OBP device tree is obtained. For example, rebooting,
    halting, powering-off, and setting options node variables.

    CPU removal support will require some infrastructure changes
    here. Namely we'll have to process the requests via a true
    kernel thread instead of in a workqueue. workqueues run on
    a per-cpu thread, but when unconfiguring we might need to
    force the thread to execute on another cpu if the current cpu
    is the one being removed. Removal of a cpu also causes the kernel
    to destroy that cpu's workqueue running thread.

    Another issue on removal is that we may have interrupts still
    pointing to the cpu-to-be-removed. So new code will be needed
    to walk the active INO list and retarget those cpus as-needed.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • There is a special domain services capability for setting
    variables in the OBP options node. Guests don't have permanent
    store for the OBP variables like a normal system, so they are
    instead maintained in the LDOM control node or in the SC.

    Signed-off-by: David S. Miller

    David S. Miller
     

29 May, 2007

1 commit


22 Jul, 2006

1 commit


01 Jul, 2006

1 commit


20 Mar, 2006

8 commits


19 Jan, 2006

1 commit

  • From: Eddie C. Dost

    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

    Eddie C. Dost
     

15 Oct, 2005

1 commit

  • Doing a "SUNW,stop-self" firmware call on the other cpus is not the
    correct thing to do when dropping into the firmware for a halt,
    reboot, or power-off.

    For now, just do nothing to quiet the other cpus, as the system should
    be quiescent enough. Later we may decide to implement smp_send_stop()
    like the other SMP platforms do.

    Based upon a report from Christopher Zimmermann.

    Signed-off-by: David S. Miller

    David S. Miller
     

30 Sep, 2005

1 commit


23 Sep, 2005

1 commit

  • 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

    David S. Miller
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds