Andrew Thomas wrote:
>
> Russell King - ARM Linux Admin writes:
> > Mark van Doesburg writes:
> > > christophe wrote: I've got an ebsa285 card but not the ARM SDT
> > > (only got the demonstration version, which doesn't have angel
> > > remote_a)
> > >
> > > Is there any Linux tool or free dos tool to upload Linux kernel
> > > to ebsa285 flash memory ?
> > >
> > > I've created a very crude program to program the flash in the blank
> > > programming mode. It has a module you have to load in order to access
> > > the ROM. To program you have to run a simple program which allows you to
> > > crash your computer if you get the address wrong :-) Let me know if
> > > you're interested.
> >
> > I do have a working version of Digital's FMU (flash management utility)
> > which works under Linux on the EBSA285. However, Digital have put a non-
> > freely distributable license on it, so I'm unable to distribute it.
> >
> > Since the license has been transferred to Intel, what are the chances
> > of getting it changed? 0?
>
> I don't see how these tools will acomplish the final goal of getting the
> kernel to boot. As far as I can tell the primary boot loader (in flash
> block 0) isn't capable of loading an elf kernel which is what has been
> generated by the kernel build. Converting this to axf format doesn't
> seem to help as the 2nd conditional in head-armv.S tests r1 to determine
> the board type (OK, we can bodge this).
>
> Can someone out there who is running a linux kernel on an EBSA285
> board please explain how to take the vmlinux generated by 'make all'
> and get the thing to boot on an ebsa285 using tools which are publicly
> available. [Sorry if I sound frustrated only I'm trying to write my
> own boot loader (for linnux for an ebsa285) and is driving me cRaZYYY
Well, its a hack, not elegant and only a temporary solution; It also
probably has many hidden problems that I've yet to uncover. Thus far
I'm up to mounting an NFS root FS and failing some where in the init
process. But here is:
Oh yea - I run the ebsa285 on a PCI backplane - maybe that matters:
0.) Make some changes to the start of head-armv.S. These things
would
be done by a proper linux boot loader:
- Dissable interuptts, MMU, and caching, set mode to
supervisor.
- inittialize address 0x100 (i.e. PARAMS_BASE)
to some valid values (see arch/arm/kernel/setup.c
(param_struct)) - maybe this is optional ?
- Set r0 to 0 and r1 to 4 and fall through to
the original code.
1.) I built the image as is - no changes to the build env.
2.) Strip the image, objcopy the image, wrap a AIF header around
the image. The aif header says to load the image at 0x8000.
3.) Connect to the board w/ armsd and load the flash management
utility (fmu.axf)
4) Via fmu.axf program the image to one of the flash sectors.
5.) turn the roto switch on card to point to the correct sector.
6) exit the fmu and armsd and tip back into the card at 9600
Other problems include:
- the PCI code does not assign IO or Mem addresses to PCI devices
- there are some assumptions in the PCI inerrupt mapping that didn't
work for me.vPCI interupt mapping seems to assume that the ebsa board
is in the system slot of my PCI backplane (slot 3 has the same
interupt mapping as the system slot).
--
Dave Baukus
Inet Inc. - R & D
[EMAIL PROTECTED]
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
