Date: Sat, 10 Mar 2007 20:49:36 +0200 From: John Hay <jhay@meraka.org.za> To: Sam Leffler <sam@errno.com> Cc: freebsd-arm@freebsd.org, Olivier Houchard <cognet@freebsd.org> Subject: Re: redboot based boot loader for kernels? Message-ID: <20070310184936.GA2769@zibbi.meraka.csir.co.za> In-Reply-To: <45F2E028.4080907@errno.com> References: <45E5A73E.20503@errno.com> <20070228.094155.660269855.imp@bsdimp.com> <20070305194018.GA73100@zibbi.meraka.csir.co.za> <45ECBA38.7030607@errno.com> <20070306064715.GA3932@zibbi.meraka.csir.co.za> <45F084C5.8020601@errno.com> <20070309064843.GA3384@zibbi.meraka.csir.co.za> <45F19438.5030109@errno.com> <20070310123835.GA83779@zibbi.meraka.csir.co.za> <45F2E028.4080907@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 10, 2007 at 08:43:20AM -0800, Sam Leffler wrote: > > > > Yip, and now after finishing most of the other stuff in my boot2 program, > > I decided to look at the 16 bit mode again... And it was working without > > me doing anything. Hmmm I know I have twiddled some of the compile > > options in my makefile... Maybe it was that. > > Ha, time heals all code :) :-) Still bothers me a bit. > >>>> I'm probably wrong and it would explain some issues we had with reset. > >>>> Feel free to send us a patch. I know I used both the appnote and the > >>>> linux driver as a basis for avila_ata.c ... > >>> I'll have a look at it as soon as I am happy with my boot2 loader. I'll > >>> just have to figure out how to map CS2. At the moment only CS1 is mapped, > >>> but for ALT_STATUS and DRV_CNTRL you need CS2. > >> Look in ixp425.c for the CS1 entry. Add CS2 and map it in the driver. > >> But I'm not sure how to deal with gluing this into the ata driver unless > >> you can just special case those registers and fetch from the alternate > >> map'd area. All this is kinda surprising as I did a bunch of tests on > >> my cf w/o seeing any issues--but I'm certainly no ata expert. > > > > Everywhere in the Intel appnote (302456-003) where they describe "True > > IDE Mode", they say that they implemented it with CS1 and CS2. The > > register set wrap around on an 8 byte boundary and I think we have just > > been lucky that a write to 0x1e actually went to the ATA_DRIVE register > > and didn't cause any problems. But the CF is then not really reset. This > > probably didn't matter too much because the CF is in a pretty sane state. > > Olivier and I saw occasional complaints about not being able to reset > the part but otherwise it seemed the driver worked fine (and when the > complaints stopped we stopped looking). I thought I also verified the > register writes against the operation of the linux driver but patches to > fix this would be welcome. I'll definitely look at it. > > Something else, appart from the Avila boards, I also have a Pronghorn > > Metro from Adi Engineering. It is very similar to the Avila software > > wise. The 2 main differences that I have found is, they use the other > > serial port for the console and they used CS3 and CS4 for the IDE/CF > > card. It seems silly to make a whole new kernel config for it. Would > > it be acceptable if one could detect the board type somehow on startup > > and use that to select the correct serial port and chip selects for > > the CF? > > The console seems like something to specify with hints unless you can > auto-detect. Regarding ata maybe you can map CS3 and CS4 too and try > probing both places. Well if one can assume that whatever ran before, did set the correct CS registers, one can just look at the CS timing registers to see which are configured. I used that today to make my boot2 program work on both boards. The avila_ata.c code already assume that part of those registers are pre setup, so maybe this isn't too bad an assumption. On both boards the unused CS timing registers are 0. In my boot2 program I used that info (CF-IDE CS registers) to choose the uart to use too. :-) Would that be an ok method to use in the kernel too, until we can find a better way? Or do we already have more than the Avila and Pronghorn boards to support? > > One last thing, I see that npe0 and npe1 use the same mac address. The > > uClinux that came installed use 2 different addresses: > > ixp400_eth: Using MAC address 00:d0:12:02:87:10 for port 0 > > ixp400_eth: Using MAC address 00:d0:12:12:87:10 for port 1 > > > > Not sure where they get it though. > > The mac is read from the h/w. If they are the same then it's likely > confusion mapping the npe's. That part of the driver needs to use hints > and/or better auto-config (though I'm not sure if it's possible to > identify different xscale boards/configs). Ignore this one, the macs are different. Probably too long between coffees. :-/ John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070310184936.GA2769>