# Brian Rose 2007-06-25:
> (Copied to NetBSD-users in the hope that someone may actually read it.)

:-)

> I notice that GCC has no information on AVR32. It looks like the Atmel 
> tools take a set of patches and apply those to the GCC/binutils tree. 
> Does anyone know if there are plans to roll this into the stock GCC? (I 
> know that is a question for the GCC list, I was just wondering if anyone 
> heard anything so I don't have to subscribe to a million lists to get an 
> answer.)

It's a question to Atmel people, actually. They're responsible for feeding
their changes to GCC, IMO.

> I guess the basic plan of attack is to get the modified GCC running on a 
> NetBSD host. Then I would need to change the various bits of build.sh to 
> accomodate the AVR32 platform.

Any (sufficiently) POSIXish system should do for host platform, actually.
I suppose Atmel's stuff will build on Linux, so sticking to that sounds
like the least-pain-approach.

Until your port reaches maturity, it's reasonable not to waste time on
getting avr32 support into in-tree toolchain, you can direct the build
machinery to use an external toolchain instead. Setting the following
make variables should do:

  MACHINE='avr32'
  MACHINE_ARCH='avr32'
  EXTERNAL_TOOLCHAIN='/wherever/the/toolchain/lives'
  MACHINE_GNU_PLATFORM='avr32-'

(Variable values are just uninformed guesses). I find it reasonable to
take an existing nbmake-${MACHINE} script and drop the variable there.
You might want to look through share/mk/ to see if you need some extra
complier options for the CPU.

> Then build the kernel and begin debugging the various drivers. An
> oversimplification for sure. But that is the plan.

Yeah, basically create sys/arch/avr32 and start populating it. Instead
of targetting the kernel directly, it might be better to target a simple
standalone program using libsa first (see sys/arch/*/stand/ for examples).

That will force you to create initial set of header files (in many cases,
you can just steal from other arches), and reward you with "your own
printf from the board" way sooner than if you targetted the kernel
directly -- it's a *lot* of work to get that running.

Hope this helps, and good luck!

	-- Jachym