[lkml]   [2008]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: bcm33xx port
    On Sunday 08 June 2008, Maciej W. Rozycki wrote:
    > On Sun, 8 Jun 2008, Luke -Jr wrote:
    > > the bcm63xx patches OpenWrt has that I'm using as a base for this...
    > It would be best if the patches you are referring to got merged with the
    > mainline. Otherwise whoever uses them is essentially on their own --
    > people lack the resources needed to chase random changes out there in
    > general.

    Is merging with mainline something I can help with, being a beginner in this
    area generally and not having any part in writing them?

    > > > That's grossly wrong. If you need to preset it for the time being
    > > > till you debug calibration, then for a MIPS processor assume one
    > > > instruction per clock tick and two instructions per loop -- that may
    > > > not be entirely correct, but is a good approximation. Otherwise you
    > > > risk peripheral devices are not driven correctly with all sorts of the
    > > > nasty results.
    > >
    > > Meaning this?
    > > preset_lpj = loops_per_jiffy = 2;
    > Not exactly. Try harder -- this is simple arithmetic and you've got all
    > the data given above already. :)

    200 / 2? I'm not really sure what a 'jiffy' is..

    > > > and (b) control being transferred to a block of memory that isn't
    > > > actually code, as can happen if exception vectors or global
    > > > pointers-to-functions aren't set up correctly, or if the kernel stack
    > > > is being corrupted. When you say "the instruction in question is a
    > > > store word", how do you know that?
    > >
    > > The RI error spits out a bunch of info, including epc which presumably
    > > points to the instruction causing the problem: ac85ffc0; this is 'sw
    > > a1,-64(a0)'
    > I have seen that already and wrote these stores in __bzero are protected.
    > Perhaps the fixup fails for some reason, but you need to investigate it
    > and this is why I suggested to see how the RI handler is reached. Since
    > this is a known point the failure leads to, you should be able to work
    > backwards from there quite easily.

    Ah, so what you're saying is that perhaps the 'sw' is triggering a TLB
    exception, and the handler for *that* is causing the RI problem?



     \ /
      Last update: 2008-06-08 22:31    [W:0.053 / U:6.380 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site