Hi!

afaik drahn@ has two odroids, but I don’t anymore know which and how
well the support is.

Currently our tree only supports parts of the Samsung Series 3 and HP
Chromebook 11 . The currently provided miniroots do not work your
device.

I can give you an explanation how to start working on ARM, but it will
be rather lenghty, sorry. :)

For clarity, I think I should split in in chapters.  This might sound
like a lot of work, but it actually isn't.

Note: On multi-core processors, you can pass e. g. -j4 to every make
      command to speed up the compile time.
      Also, this text is written from my head and can contain issues.
      Please let me know of any issue!

Chapter 1: compile environment

To be able to compile and test things, you'll need an environment where
you can compile ARM kernels.  You can either a) install Bitrig on
another, better supported, ARM platform or b) install Bitrig on a
computer or VM and cross-compile the kernels.  We support both.  The VM
is probably a lot faster than on a native ARM machine.

To set up a cross-compile environment, you'll at first need to install a
cross-compilable binutils.  If it's not available on package mirrors,
compile it using:

  cd /usr/ports/bitrig/bitrig-binutils-2.24/ && \
    sudo FLAVOR=armcross make install

After this completed, you need to set up the rest of the compile
environment using Makefile.cross:

  cd /usr/src && sudo TARGET=armv7 make -f Makefile.cross cross-tools

There are multiple cross-targets, but to be able to compile a kernel,
cross-tools is enough.

Chapter 2: compiling a kernel

Compiling a kernel is easy once you got your environment:

  cd /usr/src/sys/arch/armv7/conf/
  config GENERIC
  cd ../compile/GENERIC/
  armmake

"armmake" is a special script which passes specific environment
variables to make, so that it cross-compiles correctly.  The script can
be downloaded from here[0].  We might want to put it into the src tree
though...

This is not needed on a native environment.  You can just use make
there.

Calling armmake in that directory will compile a normal BSD kernel.
Note that those cannot be directory booted from u-boot.  Therefore we
added another make target for each SoC.  Running

  armmake bsd.EXYNOS.umg

compiles the kernel and also generates a u-boot bootable kernel.
You can now use PXE/TFTP to boot it, or run it from an sdcard.

Chapter 3: starting kernels from u-boot

Well, first of all, you need to get into u-boot.  Most boards have
UART/serial consoles, using various connectors.  You'll need to find out
what your board needs.  Then you need to find out where it boots from.
Some boards boot from an on-board flash, others require u-boot to be
flashed to an sd-card.  This really depends on your board.

Once you gained u-boot access, you can use a few commands to load the
kernels.  A few example commands:

  usb start (initializes USB stack and devices)
  fatload usb 0:1 0xXXXXXXXX bsd.EXYNOS.umg
  ext2load mmc 0:1 0xXXXXXXXX bsd.EXYNOS.umg
  setenv serverip 192.168.1.1
  setenv ipaddr 192.168.1.2
  tftp bsd.EXYNOS.umg
  bootm 0xXXXXXXXX

0xXXXXXXXX denotes the memory address where to load the kernel to.  I
think you can omit that address when running ext2load/fatload/bootm.
Play around, test things.

Chapter 4: supporting your board!

This chapter will be a bit blurry, sorry.

Supporting your own board is a bit different to adding a completely new
SoC.  On a new SoC, you need to find out memory addresses and write
drivers from scratch (or get them somewhere else).  Boards are usually a
bit easier, as you most oftenly already have driver support and only
need to add a few knobs here and there.

What you'll need to do:
  * find the board's boardid.  This is also sometimes called mach_type.
    It's an identifier for your board.  You can probably find it in the
    board's u-boot source code.
    "git grep" in sys/arch/armv7/ for BOARD_ID_EXYNOS to see where the
    ID will defined and used.  Add the board id similarily to other
    EXYNOS board ids.
  * find the memory's console address.  This is specified somewhere in
    the board's u-boot source code.  prolly the board's config.
    This should be added in sys/arch/armv7/exynos/exynos_machdep.c

Now you should be able to get some uart output.

After that... well, I said it will be blurry...  If you have any issues,
please let me know.  Send me a mail or talk to me on #bitrig on OFTC.

I'll push a WIP branch for odroid-xu support to our git, it should be
rather helpful.

\Patrick

[0] http://sprunge.us/VZBe


On Mon, Sep 08, 2014 at 08:27:07AM +0000, iwtoa wrote:
> Hi all,
> 
> As anyone been successfull running bitrig on odroid-u3?
> 
> Is there an img available? Where are the current built for exynos?
> Otherwise, would the latest miniroot-exynos be a good starting point?
> Could we have a quick draft on where to start to get something bootable?
> 
> Thanks.
> Regards,
> -- iwtoa
> 

Reply via email to