[mc1322x] My first application

Sat Jun 5 14:55:48 EDT 2010

So maybe the thing to do is use OEHOME that defaults to HOME instead
of HOME? Then you can just use something like:

export OEHOME=/home/apps bitbake foo

-Mar.

On Sat, Jun 05, 2010 at 01:23:32PM -0400, Jon Smirl wrote:
> On Sat, Jun 5, 2010 at 1:14 PM, Daniel Berenguer
> <dberenguer at usapiens.com> wrote:
> > I installed the OE toolchain on a second Ubuntu PC without problems.
> > It's just an issue of installing mc1322x-oe in /home/user and the rest
> > of packages wherever you want.
> >
> > Daniel.
> 
> This is my diff from Mar's repo.
> 
> jonsmirl at terra:/home/apps/mc1322x-oe$ git diff
> diff --git a/mc1322x/conf/site.conf b/mc1322x/conf/site.conf
> index 00f3911..d4dcf27 100644
> --- a/mc1322x/conf/site.conf
> +++ b/mc1322x/conf/site.conf
> @@ -1,4 +1,4 @@
> -TOP="${HOME}/mc1322x-oe"
> +TOP="/home/apps/mc1322x-oe"
> 
>  # Standard OE dir, corresponding to:
>  #  git clone git://git.openembedded.net/org.openembedded.dev
> diff --git a/openembedded b/openembedded
> index 08c443b..2403fd5 160000
> --- a/openembedded
> +++ b/openembedded
> @@ -1 +1 @@
> -Subproject commit 08c443b60d3821a89fdae90a39f2a32d63853607
> +Subproject commit 2403fd53440120102c2c63f3b035c3fe66b50ef2
> diff --git a/profile b/profile
> index 9a3e5ca..a4c1f15 100644
> --- a/profile
> +++ b/profile
> @@ -5,8 +5,8 @@
>  #  . profile
> 
>  # svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake
> -export BBPATH="${HOME}/mc1322x-oe/mc1322x:${HOME}/mc1322x-oe/openembedded"
> -export PATH="${HOME}/mc1322x-oe/bitbake/bin:$PATH"
> +export BBPATH="/home/apps/mc1322x-oe/mc1322x:/home/apps/mc1322x-oe/openembedded"
> +export PATH="/home/apps/mc1322x-oe/bitbake/bin:$PATH"
> 
>  umask 0002
>  unset CDPATH
> jonsmirl at terra:/home/apps/mc1322x-oe$
> 
> 
> >
> > On 5 June 2010 11:03, Daniel Berenguer <dberenguer at usapiens.com> wrote:
> >> I finally made the OpenEmbedded toolchain work. mc1322x-oe now resides
> >> in /home/user whilst the rest of directories (libmc1322x, contiki and
> >> linux serialdev) are elsewhere. libmc1322x seems to be hard-pointing
> >> to /home/ser/mc1322x and a grep of the current makefiles should indeed
> >> help. BTW, I prefer to stop tinkering the toolchain :-)
> >>
> >> Setting up (setup.sh) the openembedded overlay is the trickiest step
> >> IMO. But once completed, the rest of the install runs quite smooth.
> >>
> >> Thanks for your help!
> >>
> >> Daniel.
> >>
> >>
> >> On 4 June 2010 22:17, Andrew Pullin <pullin at berkeley.edu> wrote:
> >>> On 6/4/2010 12:29 PM, Mariano Alvira wrote:
> >>>>
> >>>> On Fri, Jun 04, 2010 at 12:13:48PM -0700, Andrew Pullin wrote:
> >>>>
> >>>>>
> >>>>> I don't mean to undercut Mariano's wonderful work in getting this all
> >>>>> put together with OpenEmbedded, but:
> >>>>>
> >>>>
> >>>> Haha, don't worry about that! It took me a day to get that
> >>>> together. Please, undercut away!
> >>>>
> >>>
> >>> In that case, you should consider switching the mc1322x project to the
> >>> CodeSourcery toolchain. It seems like it's a lot more targeted to bare metal
> >>> development. Sure, there are bugs, but I think it lowers the entry barrier.
> >>> That's part of how the Tmote-Sky platform got widespread: there was a
> >>> straightforward binary toolchain available for it (as RPM's).
> >>> Of course, there's a lot of details about syscalls/exception handlers/etc
> >>> that I've managed to ignore so far, so perhaps there's a definite reason why
> >>> a linux-targeted toolchain is better?
> >>>
> >>>> Dean is using a codesourcery chain for python-on-a-chip:
> >>>> $ git clone http://github.com/jsnyder/arm-eabi-toolchain.git
> >>>>
> >>>> It has a problem with my funny line in start.S:
> >>>>
> >>>>         bl _rom_data_init+.-base
> >>>>
> >>>> where I replaced it with:
> >>>>
> >>>>        ldr r12,=_rom_data_init
> >>>>        mov lr,pc
> >>>>        bx  r12
> >>>>
> >>>> I guess you didn't have this problem?
> >>>>
> >>>
> >>> I think I did have that problem? If you use the latest version, 2010-q1, it
> >>> segfaults on trying to assemble that file. The usual response from
> >>> CodeSourcery is, "Our business model is that you pay us to fix bugs in GCC".
> >>> Which is fine, but it stymies most people pretty quickly. I'm pretty sure
> >>> that 2008-q1 version is the one I settled on after trying a few, and it
> >>> assembles start.S / start-romvars.s without any problems.
> >>>
> >>>>> There's a couple little edits you have to do to the source, too:
> >>>>> - remove the STDERR declaration from printf.c , it's implicity declared
> >>>>> in newlib
> >>>>>
> >>>>
> >>>> Along these lines, the contiki port now uses Contiki's printf (and
> >>>> company) in cpu/arm/common/dbg-io --- I plan to pull these into
> >>>> libmc1322x as they are pretty good (and BSD licensed).
> >>>>
> >>>> We had to modify _write_r in syscalls.c to get newlib's printf to work
> >>>> in python-on-a-chip... you didn't have to do that?
> >>>>
> >>>
> >>> Nope. I'm not even familiar with syscalls, and alot of this OS design, but
> >>> it did work. That is, by removing the STDERR declaration and the stub
> >>> functions in printf.c in libmc1322x, the libmc1322x tests build and appears
> >>> to work on actual hardware. I don't think I've tried it with Contiki yet,
> >>> though.
> >>> At some earlier time, I claimed that %f worked in newlib's printf ... I
> >>> don't know why I said that, becasue looking at it now, it definitely
> >>> doesn't. So I rescind that.
> >>>
> >>>> Also, they are using your red-bsl script over there with some
> >>>> changes... I suppose really the whole point of this reply is to tell
> >>>> people to checkout the python-on-chip port!
> >>>>   -Mar.
> >>>>
> >>>
> >>> Yes, I will  have to take a look at that project. I did red-bsl because an
> >>> equivalent thing exists for the Tmote-Sky's, the tos-bsl.py program. The
> >>> easier it is to get the code onto the platform, the easier it'll be for
> >>> people to adopt that platform. Although everyone is talking about Cortex M3
> >>> these days, not ARM7.... so....?
> >>>
> >>> -Andrew
> >>>
> >>
> >
> > _______________________________________________
> > mc1322x mailing list
> > mc1322x at devl.org
> > http://devl.org/cgi-bin/mailman/listinfo/mc1322x
> >
> 
> 
> 
> -- 
> Jon Smirl
> jonsmirl at gmail.com
> 
> _______________________________________________
> mc1322x mailing list
> mc1322x at devl.org
> http://devl.org/cgi-bin/mailman/listinfo/mc1322x