OMAP3 patch

Andrew Turner andrew at fubar.geek.nz
Sat May 21 08:27:37 UTC 2011


On Wed, 18 May 2011 11:32:53 +0100
Mark Murray <markm at FreeBSD.org> wrote:
> Andrew Turner writes:
> > It appears you have a Beagleboard-xM. I haven't had a chance to test
> > booting on the xM yet so it may be broken.
> 
> Oh bother :-) Yes I have an -xM.
From a software point of view the DM3730 in the -xM and the OMAP3530
are almost identical. The main differences between the boards are the
peripherals. I've tested the same binary on both now and it boots (see
below).

> > The xM also needs a driver written to enable the USB host hardware.
> 
> I've seen some traffic on that sobject recently.
The 4 USB Host connectors are attached to a USB PHY that is enabled via
the TPS65950 chip's LED interface. The only requirement to get USB
working should be to set the appropriate line high. Alternatively you
could try to get the USB OTG working as a host if you have the
appropriate cable.
> 
> > > ** Unable to read "user.scr" from mmc 1:1 **
> > > reading uImage
> > > 
> > > 3994161 bytes read
> > > Booting from mmc ...
> > > ## Booting kernel from Legacy Image at 80200000 ...
> > >    Image Name:   FreeBSD
> > >    Image Type:   ARM Linux Kernel Image (uncompressed)
> > >    Data Size:    3994097 Bytes =  3.8 MB
> > >    Load Address: 80200000
> > >    Entry Point:  802000e0
> > >    Verifying Checksum ... OK
> > >    XIP Kernel Image ... OK
> > These addresses are interesting. I don't think XIP will work. You
> > can try to load the image to a different address in U-Boot or build
> > FreeBSD to run at a different address.
> 
> Erm, OK. :-)
> 
> Suggestions of where to look to find alternatives?
I've put an updated copy of std.omap3 at [1]. Place it in
sys/arm/cortexa8/omap3. With it I've managed to get FreeBSD to the
mountroot prompt. Because the kernel is running from a different
address you will need to do a full buildkernel. I've updated the
kernel build script at [2] to be smarter about setting the load address
(i.e. not hard coded).

As far as I can tell U-Boot uses memmove to copy the kernel from where
it is loaded to where it will be run from. This means the requirements
for the kernel's load address are:
 * Don't overwrite the U-Boot code
 * Be different from the loadaddr U-Boot variable

> Try what instead of XIP?
Normally U-Boot will load the kernel to $loadaddr then copy it to the
correct location. There is a short header with the information it needs
to do this. When this $loadaddr and the value printed after "Load
Address:" are the same no copy takes place.

Andrew

[1] http://fubar.geek.nz/files/freebsd/omap/std.omap3
[2] http://fubar.geek.nz/files/freebsd/omap/build_beagle.sh


More information about the freebsd-arm mailing list