Messages

31

Angstrom & OpenZaurus / Bitbake Scripts...

« on: June 03, 2005, 08:34:43 am »

June 3, 2005...

My rough work towards making a bitbake image on Debian under QEMU...  There is a problem with the compiler path I can't resolve (says it can't find arm-linux-gcc-2.95, but it is in the path)...

I use a build account called "bitbake" w/ sudo permissions to do everything root can.
I put all of my OE "/stuff" in ~/bb

- unzip this file
- grant sudo privledges to your build account
- cut and paste lines from bitbake_install.txt to command prompt
- get path settings from .bashrc add them to your shell, log out and back in, then type "export" to check your paths for PATH and BBPATH
- run refresh_toolchain.sh to get the latest build of bitbake and OE package data

If you are using a collie (5500), you can copy local.conf to ~/bb/build/conf/local.conf, otherwise you'll have to edit ~/bb/build/conf/local.conf as per the docs @ http://oe.handhelds.org/cgi-bin/moin.cgi/GettingStarted

Once your local.conf is done, you can start a build by doing:
cd ~/bb/build
bitbake openzaurus-sa


Let me know how it works/doesn't for you...

Cheers,
-Ironstorm

32

Angstrom & OpenZaurus / Debian-arm On Oz-3.5.3

« on: May 31, 2005, 12:41:15 pm »

I think the package trees are totally different...

Will also depend if deb-arm is gcc2 or gcc3 (oz is gcc3 as of 3.3.6)....

33

Angstrom & OpenZaurus / Bitbake On Qemu - Alpha

« on: May 30, 2005, 02:10:32 pm »

Updated initial post with progress...

34

Sharp ROMs / Databook Data Loss Bug (qtopia 2.1.1, Oz3.3.x, ?)

« on: May 30, 2005, 11:31:34 am »

This bug effected used to affect Opie in OZ3.3.x (it may still affect OZ, haven't checked)...  

If your Calendar data file (datebook.xml) gets to be large (i.e. mine is 100K), it can take quite a while for the Calendar application to close if a update was made (i.e. 1m30s).

If while closing, a suspend occurs, your Calendar data will have null characters written into datebook.xml at the point in the file that Calendar was writting to...

When next you open Calendar the data after that point in your Calendar file will not appear in the Calendar app...  

First thing don't panic...  

Calendar overwrites the databook.xml file on exit and only when something has been changed....

So, you can likely still save your data, if you've not changed it or closed the calendar yet...

Here's how:
1. cp ~/Applications/datebook/datebook.xml ~/Applications/datebook/datebook.xml.nulls
-> important if your calendar is still open, you changed something before realizing your data is gone...
2. kill or close Calendar  (kill is probably safer)
3. run check-datebook.sh
-> see attached script file
-> assumes databook.xml is here @ /root/Applications/datebook/datebook.xml
-> you should see "datebook.xml contains null characters and is being cleaned." if corruption has occurred else you will get no output.
4. reopen Calendar check your data is back

If your data is not back, close calendar:
- cp ~/Applications/datebook/datebook.xml.nulls ~/Applications/datebook/datebook.xml
- run check-datebook.sh

If your data is still not back, restore from a previous backup.

Proper Fix
Since I'm not sure if the problem is in the reading of datebook.xml or when the file is given to the XML parser...  My suggestion is to fix it at the reading stage.

To fix it:
- binary read the file by it's size (not as a null terminate string from a text file)
- remove all null characters from the buffer
- plant the cleaned buffer into a string buffer and give it to the XML parser

Alternatively, you could fix writing when a suspend event occurs, but I suspect this could be hard or even impossible (if it's a kernel-level-type problem).

-ironstorm

35

Angstrom & OpenZaurus / Oz Needs To Get Better...

« on: May 27, 2005, 12:29:29 am »

We use gcc 2 for compatibility with all the applications built for Sharp.
The Video playback performance has practically nothing to do with these things.

There is nothing wrong with using GCC2 in itself, I thought the reason OE/OZ moved to GCC3 was to get better performance out of Arm processor...  My experince has been very limited with Video, but the 1 file I played on OZ3.3.6, OZ3.5 [both GCC3] and Qtopia [GCC2] was the IBM linux commercial (~9MB), it was quite watchable on OZ and choppy/skippy on Qtopia...  

The main thing that makes me think GCC2 is going to become limiting is most libary files I expect will eventually move towards GCC4 (in Debian Arm or whichever distro we derive source from)...  that could eventually lead to either a lot of work to maintain GCC2 support or leave us with old libraries that don't support new formats, or new optimizations...  might not happen though.

and about your alarms not working.. which device are you using?

Sorry I meant that as the reason I switched to Qtopia, to get my alarms/apm working again...  It's a nice ROM btw...
 
-Ironstorm

36

Angstrom & OpenZaurus / Oz Needs To Get Better...

« on: May 26, 2005, 10:18:13 pm »

The glass is more then half full and filling more then it is leaking. However it still has a good bit to go. That said OZ/Opie is a volunteer project. My advice is to remember that.

This is a development system; it is 'unstable'. That means it is development quality. All comunications are best sent and best received with that view point.

I think one of the reasons that the devs slave away at this is to produce a usable product, if not for end users, for themselves as users.

I was hoping we could get to the point where we could all agree on some baseline for what meets the critia for a successful release in the eyes of everyone.

Of the list of 8 things I outlined a PDA OS should do/have, the latest unstable OZ 3.5.3 has 2 or 3 of them straight away after being flashed (notepad, addressbook and maybe backup data/sync)... of the other 5-6 things having a calculator, calendar and time keeping can be made to work with some effort, but overall I don't regard it as a successful release.

As Mickyl would prefer to see, I'd rather spend my time fixing it in the build system (and if I can get a successful build of something to start with, that will help me start getting deeper on that) then watch every non-dev in the community duplicate their efforts struggling to try to fix those 5 or 6 things, or worse give up in frustration...

The Qtopia ROM I'm currently using (or even the original Sharp ROM), while being based on older (some would say obsolete) technologies and build tools actually nail all 8 on the list and some of the gravy list too, but show their age in other various ways (i.e. gcc2 based, shitty video playback performance) which make me think they are evoultionary dead ends...  But on the practical side they will have to do for now... (can live without alarms working only so long)

Anyway I think the comments from your post have been stated many times before, and mine likewise.

Cheers,

-Ironstorm

37

Angstrom & OpenZaurus / Oz Needs To Get Better...

« on: May 26, 2005, 06:29:52 pm »

We even cut BitBake's memory requirements from 1.5 GigaBytes to 128MB lately - is that a word?

How recently?  Last Thursday when I last tried to do a build of OZ using the latest Bitbake, Bitbake ate through around 400MB of ram and 300MB of swap and 2GB of disk space before the kernel compile bombed (where DISTRO="openzaurus")...   (I'm sure the Disk I/O of swapping contributes to what is an already painful compile time under QEMU on Win32)

If this has changed in the past week, I should refresh the toolchain again and have another go...

38

Angstrom & OpenZaurus / Oz Needs To Get Better...

« on: May 26, 2005, 05:17:48 pm »

With little fanfare, last night I somewhat grudgingly flashed over my Zaurus' OZ 3.5.3 w/ the new Qtopia ROM.

I've used OZ since version 3.2 was released. And while it has always seemed better then the Sharp ROM, it has also always seemingly been plagued by release quality problems from an end user perspective (perhaps evidenced by the lack of “stable” release for approaching 2 yrs). More recently with the crippling APM problem, OZ has become almost unbearable as PDA OS.

Perhaps some of the issues surrounding OZ can attributed to a lack articulated requirements for what a PDA should be able to do...   Here, as a single user, is my opinion of what is needed in a PDA OS...

A PDA OS should:

• Include a notepad
• Include a calculator
• Include a clock and be able to keep time (there are something like 25 major time zones in the world, those 25 should be included)
• Have working power management, so the PDA sleeps when it should and wakes for alarms and can advise users when it needs to be charged
• Include an address book
• Include a todo list
• Include a calendar/appointment book (obliviously this depends on time keeping and power management)
• The ability to sync PIM data to desktop or back it up to removal media or both

All of the things listed above should work as soon as the device is finished being flashed.  If they don't the OS should not be released; stable, unstable, or otherwise until the offending software is rolled back to a working state again.

The gravy stuff that would be nice to have available either on the ROM or as upgrades (but not necessary for a release) includes:

• An audio player for MP3s and OGGs
• An email client
• A web browser
• A movie / video player

Typically, the response I've seen in the past is that more developers are needed to make this stuff happen... And they most certainly are needed, but the bar for entry has been and still remains too high in my opinion.

I myself have made a few attempts to lower this bar for both myself and others in the community wishing to have a go at building OZ by cobbling together preconfigured OZ build environments (both in the days of the OpieSDK and more recently w/ BitBake under QEMU) and though I still feel this (or something like a Knoppix CD based build env) would be the best ways to introduce and catalyze interest in the OZ development process, I’m beginning to wane on whether they are doable in a practical sense.

I want to use OZ, I really do…  But it needs to get better…  I welcome comments...

Cheers,

-Ironstorm

39

Angstrom & OpenZaurus / Oz3.5.3 (collie) On/off Button Problem

« on: May 14, 2005, 09:50:47 pm »

I just may get into this game sooner than I thought. As soon as I can make time I'll give'er a whirl. thanks ironstorm.

I wouldn't waste your time till the devs get around to addressing the problem with the build system...
http://bugs.openembedded.org/show_bug.cgi?id=2

40

Angstrom & OpenZaurus / Bitbake On Qemu - Alpha

« on: May 14, 2005, 12:19:22 pm »

| Patch config-guess-uclibc.patch does not apply (enforce with -f)

The above was reported in the IRC channel by someone else also...  I've filed a bug http://bugs.openembedded.org/show_bug.cgi?id=2 hopefully it will get fixed soon.

41

Angstrom & OpenZaurus / Bitbake On Qemu - Alpha

« on: May 14, 2005, 02:28:11 am »

Unfortuantely, I don't get the build going... it fails with the following message... (not sure if I'm supposed to set DISTRO to familiar --- I'm trying to build OZ)

Code: [Select]

bitbake@debian-bitbake:~/bb/build$ bitbake opie-image
NOTE: Using cache in '/home/bitbake/bb/build/tmp/cache'
NOTE: Parsing finished. 2286 cached, 0 parsed, 47 skipped, 0 masked.
NOTE: Building provider hash: [####################] (100%)
NOTE: build 200505140023: started

OE Build Configuration:
TARGET_ARCH   = "arm"
TARGET_OS     = "linux"
MACHINE       = "collie"
DISTRO        = ""
TARGET_FPU    = ""

NOTE: package gnu-config-native-0.1cvs20050513: started
NOTE: package gnu-config-native-0.1cvs20050513-r3: task do_fetch: started
NOTE: package gnu-config-native-0.1cvs20050513-r3: task do_fetch: completed
NOTE: package gnu-config-native-0.1cvs20050513-r3: task do_patch: started
NOTE: Applying patch 'config-guess-uclibc.patch'
ERROR: function do_patchcmd failed
ERROR: log data follows (/home/bitbake/bb/build/tmp/work/gnu-config-native-0.1cv                                                                                                                     s20050513-r3/temp/log.do_patchcmd.774)
| Replacing patch config-guess-uclibc.patch with new version
| Applying patch config-guess-uclibc.patch
| patching file config.guess
| Hunk #1 succeeded at 138 (offset 2 lines).
| Hunk #2 FAILED at 840.
| Hunk #3 FAILED at 849.
| Hunk #4 succeeded at 891 (offset 16 lines).
| Hunk #5 FAILED at 910.
| Hunk #6 FAILED at 929.
| Hunk #7 FAILED at 971.
| 5 out of 7 hunks FAILED -- rejects in file config.guess
| Patch config-guess-uclibc.patch does not apply (enforce with -f)
NOTE: Task failed:
NOTE: package gnu-config-native-0.1cvs20050513-r3: task do_patch: failed
ERROR: TaskFailed event exception, aborting
NOTE: package gnu-config-native-0.1cvs20050513: failed
ERROR: Build of opie-image failed

42

Angstrom & OpenZaurus / Oz3.5.3 (collie) On/off Button Problem

« on: May 13, 2005, 01:22:56 pm »

I wish I had the time to set up a development environment, grab the kernel sources & play around. Maybe one day.  thanks Mickey.

You could have a go at building with my QEMU virtual machine image of a bitbake build environment...
( see https://www.oesf.org/forums/index.php?showtopic=12564 )

43

Angstrom & OpenZaurus / Bitbake On Qemu - Alpha

« on: May 13, 2005, 11:40:19 am »

How do I download your image?
Do I have to install Azureus? I already have a BitTorrent client.

You need a client that supports reading Magnet URIs...  I created the torrent using Azuerus 2.3.0 which does magnet...  You might be able to find other clients that do magnet also...

44

Angstrom & OpenZaurus / Bitbake On Qemu - Alpha

« on: May 13, 2005, 11:37:51 am »

"This image file will likely be updated/replaced very soon.". Why that ?

I plan to fix that TARGET_OS line and it will also be moved from hosting of the file off my home PC to a server...   So, no I wouldn't wait if I were you...

45

Angstrom & OpenZaurus / Bitbake On Qemu - Alpha

« on: May 13, 2005, 10:14:03 am »

Lots of people (myself included) have said, I'd love to help make OZ better but don't have the time or know-how to set-up the build environment.

This mini-project attempts to help by making it as easy as running a QEMU virtual machine, logging in and typing 'bitbake oe-image'.

Requirements:
- QEMU  for Windows or Linux

- My Debian BitBake QEMU image (using Azureus):
magnet:?xt=urn:btih:7YPQB3DWM3ARTZE3JL4FMLKL7FT7MT5H
(this file will grow to be ~5.5GB as you build)  Note: This image file will likely be updated/replaced very soon.

- A fast computer would be helpful...

Instructions
- Uncompress the disk image (you can use 7-zip on Windows)
- Start QEMU with using the image file as your -hda
- I used 192MB, but you could proably get away with 96 to 128MB of QEMU RAM
- Optional: use -redir tcp:22::22 with QEMU and then you can ssh to localhost and get into the image using PuTTY, if you have an SSHd running on localhost either turn it off or change the port parameter mapping to something else.
- login with bitbake/bitbake
- edit ~/bb/build/conf/local.conf -> uncomment line TARGET_OS="linux" and save
- cd ~/bb/build
- bitbake oe-image
- in Windows I recommend using task manager to set the QEMU.exe task to low priority, then minimize and check back with QEMU every half an hour to see how it's progressing...  (it takes a long time to initially pull all the bb packages to local cache)

Update - May 30:
Bitbake 1.3.0 requires almost 256MB exactly to work as a build environment...  this is much reduced from the previous 700MB (RAM+SWAP) that was previously required...

Things move much faster when SWAP can be avoided on QEMU...

Hopefully, I'll be able to get a better bitbake image done soon...  just trying a build with the ASSUME_PROVIDES="virtual/gcc-arm-linux-2.95" as per the suggestion in this bug (This bug ( http://bugs.openembedded.org/show_bug.cgi?id=29 ) has kept me from building successfully lately, but hopefully adding), if this succeeds I'll clean and pack this image.