Date: Sat, 10 Mar 2007 08:43:20 -0800 From: Sam Leffler <sam@errno.com> To: John Hay <jhay@meraka.org.za> Cc: freebsd-arm@freebsd.org, Olivier Houchard <cognet@freebsd.org> Subject: Re: redboot based boot loader for kernels? Message-ID: <45F2E028.4080907@errno.com> In-Reply-To: <20070310123835.GA83779@zibbi.meraka.csir.co.za> References: <20070228102459.GB28669@zibbi.meraka.csir.co.za> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
John Hay wrote: >>> Well in effect I only get half of the bytes, but not the first or second >>> half. With every 16 bit read I get 2 bytes. But some are missing. So if >>> the start of the sector on the disk looks like this: >>> >>> 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 >>> 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>> >>> What I read is this: >>> >>> 01 02 >>> 05 06 >>> 09 10 >>> 13 14 >>> 17 18 >>> 21 22 >>> 25 26 >>> 29 30 >>> >>> So after 128 reads you start to read zeros because all the data has been >>> read. >> So you're reading 4 bytes at a time, swab'ing 'em, then taking only 2. > > 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 :) > >>> In another email you asked: >>> >>>> 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. > > 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. > > 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). Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45F2E028.4080907>