[mc1322x] My first application

Sat Jun 5 13:23:32 EDT 2010

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

