Subject: EBSA-285 adventures

From: Paul Stewart <[email-masked]>
Date: Tue, 2 Jun 1998 03:49:01 PDT

First of all, I'd like to thank Russell King, Dave Gilbert, Philip
Blundell, Linus, the Itsy team and all the other Linux and ARM-Linux
developers for their artifacts allowing me to get this far with only
web searches and an FTP here or there.  I continue to marvel at the
incredible dedication and attention to detail that has cultivated
this work.

  That said, I've got a quasi-success report, for those who may not
have been able to piece together the entire procedure for cross-
compiling for the EBSA-285, and then a slightly off- topic question
that I hope others who work with this sort of hardware may be able
to shed light on.

  My goal is to get an EBSA-285 up and running linux.  I had on hand
the Digital EBSA-285 eval board, the 5-volt passive backplane, a
22140A-based ethernet card, and for development purposes a i586 
linux box.  To get any real support, I quickly realized from 
summaries of diffs and reading the config code for 2.0.33 that a 
2.1.xx(x) kernel would be critical, since it seemed that the real 
watershed for EBSA-285 support came in the experimental branch of 
the kernel.  My first attempt at compiling such a kernel came with
picking up the latest of everything: Linux 2.1.103, the latest 
snapshot of binutils (2.9.1.0.4) and egcs snapshot 19980531, all 
of relatively recent vintage.

  This approach, of course was met with failure, first because
the lack of ELF support in egcs.  The 2.1 kernels require ELF support
in many crucial places.  After a little hunting I found diffs to 
gcc 2.7.2.2 on Russell's exceedingly helpful ftp site,
ftp://ftp.arm.uk.linux.org/pub/armlinux/tools/.  It was a little hard
to find, since the patches that were highlighted in the webpages and
READMEs were for the ARM/a.out variety, which is probably more useful
to the folks building on 2.0 systems, and moreover it appears that 
even on the 2.1 kernels, the a.out format is still the defacto 
application binary format.  

  My attempt at using gcc-2.7.2.2 with binutils 2.9.1.0.4 looked
promising... all the way up until the final link stage where I
got nasty looking messages about overflows in relocation.  I took
this as a sign that I should have just taken the "binutils-2.8-elf"
diff also on Russell's site and used that.  There was an ever-so-
slight version skew between the two.  gcc-2.7.2.2 seemed to have 
a problem reminiscent of a warning on Russell's Tool page: while
compiling in the 3Com directory, I got failure messages from the
assembler complaining that "Processor does not support halfwords 
or signed bytes" from gas/config/tc-arm.c.

  I considered two things to be wrong with this: Firstly, the 
compiler failed to suppress StrongARM instructions.  I was 
prepared to forgive this, especially since the EBSA-285 is a 
StrongARM-based processor.  It was still a bug, but not one I was 
prepared to tackle just then.  The second issue was that since
I was on a StrongARM, I'd actually like to pass that code on to
the assembler and have it take advantage of those instructions.
Towards this purpose, I modified gcc to support a "-msa110",
which worked just like the (perhaps broken) "-m6" argument,
except it passed the "-msa110" down to the binutils-2.8 
assembler, which did accept this flag.  I think modified
arch/arm/Makefile to have a check for CONFIG_CPU_SA110 in the
non-"CONFIG_BINUTILS_NEW" branch of CONFIG_CPU_32.

  The last of the patches that I applied should have been made
at the very beginning: I'd assumed that by 2.1.103, that the
kernel had been made mostly ARM-friendly, and a patch of the
magnitude of the earlier ones for 2.0.33 and 2.1.99 which I
had picked up before.  To my surprise there were 72k lines of 
modifications, covering many of the issues I'd found in my 
first passes at a compile and addressing quite a few more 
issues I'd expected to run into on the horizon, like a VGA
console.  A great big "attaboy" goes out to Russell and whoever
else made it possible for me not to think about what exactly
KSTK_ESP() was and what to set it to for ARM architectures.

  The only configuration option that gave me trouble was "CONFIG_FB",
which when enabled, started a compile in arch/arm/drivers/char1.  
I'm not sure what the semantic significance of "CONFIG_FB" is, but it 
would appear that I do not need it, since the arch/arm/drivers/char
path seems to have what I want and compiles cleanly with CONFIG_FB
turned off.

  So, to summarize, here's how I got a vmunix for my EBSA-285:

  * Acquire gcc-2.7.2.2, binutils-2.8, from ftp://prep.ai.mit.edu,
    and linux-2.1.103 from ftp.linux.org

  * Acquire and apply patches to all of these from the ones
    provided on ftp://ftp.arm.uk.linux.org/pub/armlinux/

  * (Optionally?) modify this patched gcc to invoke the StrongARM
    assembly personality in GAS.

  * Configure and compile the development tools.  I guess 
    arm-unknown-linuxelf will work in most places.  I started 
    using arm-unknown-elf, and had to modify a few config scripts 
    to maintain that nomenclature.  Don't forget to rename the
    binutils-generated filenames in your $prefix/bin/ dir as 
    Dave Gilbert's instructive post to this list pointed out 
    (speaking of which, where would be the best place to keep
    this post archived?  There are web pages that reference this
    post) -- you'll need all the tools to have the same root name
    when you supply the CROSS_COMPILE line to the Linux Makefile.

  * Configure and compile linux.  All done (we hope)

  So what's my problem?  Actually getting this kernel into the
EBSA-285.  Angelboot would appear to be the right answer, available
both from Causality (http://www.causality.com/) and in modified 
form as a part of the Linux-on-brutus distribution at
http://www.research.digital.com/wrl/people/kerr/linux-brutus.html.
The problem I'm having is that the EBSA seems entirely unresponsive
in the angel debug protocol.  Configuring it without an ethernet 
card plugged in and attached only via serial, it prints out the
version banner on bootup, and is completely silent and does not
respond to angelboot's packets.  When an 21140A card is plugged
in, it emits no traffic whatsoever, although from the status lights
on the card, it's apparent that the EBSA has initialized the PHY.

  Has anyone seen this behavior before?  Running the self-test flash
image returns successful results (including echoing back characters
sent to the serial port), so if this is a hardware problem, it is
a strange one.  Writing the "angel2" ROM image into the flash via
the PCI bus was successful, but this image exhibits the same 
behavior, after outputting a slightly different version banner.

  Anyway, I'd like to thank all the folks who have gotten me here
so far, by the mere virtue of publishing their artifacts.  I hope
that my relatively large "ObArmLinux" has bought me at least a
little credit for a arm-hardware question.

--
Paul

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: David Alan Gilbert <[email-masked]>
Date: Tue, 02 Jun 1998 12:13:13 +0100

Hi Stewart,
  Some points you might like to consider:

  1) I used a patched EGCS version of the compiler; like GCC 2.8.x
     if you tell it to use StrongARM instructions it sometimes generates
     erroneous halfword loads; so I tell it to compile for ARM6.

  2) The patches as of a few days ago didn't allow swapping to work on
     the 285 - its getting better; it should be fixed now-ish.

  3) I have a TFTP booter for that ether card; (Its Russ's 3com TFTP booter with
     some patches).  I'll try and remember to
     bring it in - although I still use Angel to load it.
     (Take your serial rates down to something like 19200 and see if you still
     have hastles).

  4) Most of the Linux PCI drivers presume consistency between the PCI
     view of memory and the CPU view of memory with cache snooping hardware
     to ensure this.  The 285 doesn't have any hardware like that.
     This problem affects the 21040 (tulip) ether driver.
     At the moment the only fix for this is turn off the data cache and write
     buffer - I have a two line patch for that I can send you.
     Phil is working on some more general soloutions to this problem.

  5) You probably don't have a working floating point emulator for that
     kernel version.

  6) (Noting 4) The Ncr53c8xx SCSI drivers seem to work with very little
     work.
Dave
-- 
----------------------------------------------------------------------
- Dr. David Alan Gilbert - WARNING! This is a beta release .signature-
- Work:    dg @ cogency.co.uk        - +44-(0)161-428-9444           -
- Home:    gro.gilbert @ treblig.org -                               -
----------------------------------------------------------------------
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Paul Koning <[email-masked]>
Date: Wed, 3 Jun 1998 09:07:47 -0400

>>>>> "David" == David Alan Gilbert <[email-masked]> writes:

 David> Hi Stewart, Some points you might like to consider:

 David> 3) I have a TFTP booter for that ether card; (Its Russ's 3com
 David> TFTP booter with some patches).  I'll try and remember to
 David> bring it in - although I still use Angel to load it.  (Take
 David> your serial rates down to something like 19200 and see if you
 David> still have hastles).

I had the same problems Paul Stewart mentioned, which sound very
different from your experience.

If I configure the EBSA-285 as "central function", it doesn't respond
at all to any input.  On powerup, it prints the "angel" banner
message, and that is all.  Angelboot gets no response from it. 
(I'm using speed 9600 for the initial exchange, that's the speed the
banner comes out at.  But others don't work either.)

Configured as "not central function" I got it to work once, but not
again.  What seems to happen then is that it doesn't print out a
banner a person can read.  Instead (right now, for me) it prints out a 
steady stream of meaningless characters.  Angelboot doesn't appreciate 
this either; it complains bitterly about "received 0xff when expecting 
start of packet".  The appearance of that stream doesn't change a lot
no matter what I set for line speed (interesting...).

My setup is just the EBSA-285 in the backplane, no other cards of any
kind.  Any ideas?  I'v been trying to make some progress using FMU
(under DOS) but that's a major pain because our only PCI PC is my
wife's PC, which I try not to take apart too often... :-)

A TFTP booter would be much appreciated.  If I can get H-Forth to work 
I can use that to go forward, but at the moment I can't get that to
work either because of the problems above...

 David> 6) (Noting 4) The Ncr53c8xx SCSI drivers seem to work with
 David> very little work. 

That reminds me... I found that PCI IDE adapters exist (they are rare
but if you can find them they are cheap).  Any idea whether that could 
be made to work (with the proviso you mentioned)?  I have some spare
IDE drives but no SCSI drives, so this approach is attractive...

	paul

---

From: Philip Blundell <[email-masked]>
Date: Wed, 03 Jun 1998 14:56:11 +0100

>but if you can find them they are cheap).  Any idea whether that could 

It shouldn't be a problem.  I have IDE going on a CATS board (which is 
basically just an EBSA-285 with some extra bells and whistles).

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Wed, 3 Jun 1998 22:35:59 +0100 (BST)

> work either because of the problems above...

My TFTP loader isn't the most friendly of sources - it was originally
written to be as small as possible for the EBSA-110.  This means that
it contains some C code, written to be as efficient as possible and
some assembler code.  As a consequence, it's not readable at all.
 However, it is easily expandable in terms of network hardware.

It has not been designed to be distributed, but was more a stop-gap
tftp/bootp implementation that loaded quickly on the EBSA-110 to pull
a large kernel image quickly to it.

So, what does this mean in terms of the EBSA-285?  Well, I added to
the code a driver for 3com 3c59x cards.  Dave Gilbert has added a
particular type of DEC ether chip.  I have not received his code yet,
so I'm not exactly going to start publicising it yet.  Maybe once
Dave's sent his patches I'll have a closer look at it to make it
more publically available.

Please note, however, that this does not loader does not currently
fall under the GNU Public License, but may do in future.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Philip Blundell <[email-masked]>
Date: Wed, 03 Jun 1998 22:50:35 +0100

>fall under the GNU Public License, but may do in future.

What licence is it under currently?

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Wed, 3 Jun 1998 23:07:40 +0100 (BST)

> What licence is it under currently?

It's under my own copyright at the moment - no one has any rights to it
except by express permisssion, which means Dave Gilbert and myself
currently.  Like I say, once it's in a distributable form, it then
stands a chance of becoming GNU.

Phil, not everything can be GNU from the start.
   _____

---

From: Philip Blundell <[email-masked]>
Date: Thu, 04 Jun 1998 10:07:16 +0100

>Phil, not everything can be GNU from the start.

If you must read between the lines of everything I say, at least do me the
courtesy of not complaining about what you think you've discovered.

p.

---

From: Paul Stewart <[email-masked]>
Date: Fri, 5 Jun 1998 09:49:22 PDT

>wife's PC, which I try not to take apart too often... :-)

Possibly as a sign of Intel's commitment to the StrongARM, new PDFs have been arriving on their developer site:

 http://developer.intel.com/design/strong/techdocs/index.htm

At this page, one can now find an App Note for programming the flash memory of the EBSA-285 using the EBSA's JTAG port and a PC serial port.  I hope to report later today whether or not my adventures in implementing this sort of setup works.

--
Paul