redboot based boot loader for kernels?

[Sam Leffler]

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