lkml.org 
[lkml]   [2001]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: AMD SC410 boot problems with recent kernels
    On 22 Dec 2001, H. Peter Anvin wrote:
    > I mean %dx -- you'd built a 32-bit counter into %dx:%cx.

    Ok - didn't know this. Sorry for confusion - it's the first time I'm
    digging deeper into x86 assembler stuff. My conclusion is that %dx:%cx is
    0000:0001 after the old wait routine.

    > It's part of the counter. This seems to be *your* code, since there
    > is nothing even closely similar in any previous kernel, so I don't
    > know what you're trying to do here...

    See above - the code after a20_wait_old just outputs stuff to an 8 bit
    dioport with LEDs attached.

    > Doesn't change the fact that the board is still broken, and they
    > didn't provide the BIOS routine to compensate.

    Hmm, I still don't understand this. Ok, the BIOS does not have the
    routine, but this is rather common on embedded boards which do not have a
    full featured BIOS. I mean - the procedure used by your code is to use
    BIOS, then KBC and then 'fast' method one after the other until everything
    fails. So it should be ok if KBC method worked, shouldn't it? I mean - not
    taking into accout that due to some strange reasons the KBC method does
    _not_ work correctly at the moment, but that's another question.

    > At that point, the fact that the old code worked by accident is
    > unfortunately irrelevant; especially since you obviously have a
    > workaround that you can use.

    Could you elaborate why you think that the old code worked only by
    accident? [please be patient - I'm no native speaker and it may be that I
    do sometimes not understand everything correctly. I'm trying hard.] As I
    said above: before I do not understand _why_ the new code breaks it's
    rather difficult to draw conclusions.

    If the board is really _broken_ I have no problem with the fact that in
    the future the manufacturer has either to supply a correct BIOS or a
    workaround patch has to be used. If it's only uggly that there's no BIOS
    routine it would IMHO be better to find a way to make it work again. There
    are fixes for other uggly architectures in the code as well, see the
    Toshiba Laptop reference. If the board may be PC compatible, Linux should
    IMHO boot without further changes.

    Are there other x86 boards where the BIOS doesn't provide the routine and
    where the KBC method actually _works_? Would be interesting; I'm not sure
    that much people have tested this yet, as most "normal" motherboards today
    have full featured BIOSes. So any comments from embedded people using the
    mechanimsm on other boards (SC410 or something different) would be
    helpful.

    > No, but the sequence in verbatim either before or after the call
    > delay.

    Now, I've tried these variants in the section after a20_test_wait:

    ----------8<----------
    call delay # Serialize and make delay constant

    pushw %dx
    smsw %dx
    lmsw %dx
    popw %dx
    ---------->8----------
    pushw %dx
    smsw %dx
    lmsw %dx
    popw %dx

    call delay # Serialize and make delay constant
    ----------8<----------

    Still no change -> reboots.

    Robert
    --
    +--------------------------------------------------------+
    | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
    | Pengutronix - Linux Solutions for Science and Industry |
    | Braunschweiger Str. 79, 31134 Hildesheim, Germany |
    | Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4 |
    +--------------------------------------------------------+


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:14    [W:2.363 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site