Yesterday we made overlay for pdas such as iPAQ hx4700 It contains some pda stuff ( gpe fbreader ) And some e-related stuff use svn co svn://gentoo.ru/hx4700/portage to add this overlay _________________________________ Gentoo GNU/Linux 2.6.18 Dual Xeon E-mail: alexxy@... E-mail: alexxyum@...
Hi, I have been using crossdev and gentoo to build an uclibc embedded platform. I have been buidling my toolchain using: crossdev -binutils 2.16.1-r2 -gcc 3.4.5-r1 -libc 0.9.28 -kernel 2.6.16.20 -t i386-pc-linux-uclibc and crossdev -binutils 2.16.1-r2 -gcc 3.4.5-r1 -libc 0.9.28 -kernel 2.6.16.20 -t arm-softfloat-linux-uclibc As you can see I am targeting both Intel and Arm platforms. I'm using portage snapshot from portage-20060703.tar.gz. I intend only to update the portage snapshot I am using only if I need to to fix a bug or add features. Things have been working well, but there have been some issues with uclibc's shared library loader, which so far I have worked around using LD_PRELOAD. Having cross-compiled both mozilla for dfb and mozilla against X to use with XDirectFB(dfb mozilla still seems to have some issues) these shared library loader issues seem to be rearing there head again and I cant seem to work around them with LD_PRELOAD for mozilla/X. I have noticed though that since uclibc 0.9.28 there seems to have been a fair bit of work done in uclibc's ldso directory and it looks like these bugs may have been fixed there - hence the need to try and build against uclibc from svn. I have done this by creating a new uclibc-1.0.0.ebuild (version 1.0.0 just to(Continue reading)
Hi everyone,
I've set up a 'build root' that I can chroot into for cross development.
There is also a directory of targets to compile for, and for each
target, a series of different configurations.
When I chroot into my buildroot my 'enter_chroot' script will
automatically mount -o bind each of the sysroot, binpkgs, and overlay
directories for a specified configuration, as well as mount -o bind the
portage tree itself.
So my directory structure looks something like this:
gentoo-crossdev-buildroot/
enter_chroot.sh
(mounts proc, mounts -o bind portage/sysroot/binpkg/overlay etc)
portage/
... (the portage tree)
buildroot/
... (all cross compilation tools and a stage1 filesystem)
targets/
arm-9tdmi-linux-gnu/
cross-toolchain/
configurations/
reference/
overlay/
binpkgs/
sysroot/
client1/
...
(Continue reading)
Is your $SYSROOT the same as your $PORTAGE_CONFIGROOT? Cuz portage only looks in $PORTAGE_CONFIGROOT and cares nothing of $SYSROOT.. On Sat, 2007-01-13 at 00:12 +0100, Christopher Friedt wrote: > Hi everyone, > > I've set up a 'build root' that I can chroot into for cross development. > There is also a directory of targets to compile for, and for each > target, a series of different configurations. > > When I chroot into my buildroot my 'enter_chroot' script will > automatically mount -o bind each of the sysroot, binpkgs, and overlay > directories for a specified configuration, as well as mount -o bind the > portage tree itself. > > So my directory structure looks something like this: > > gentoo-crossdev-buildroot/ > enter_chroot.sh > (mounts proc, mounts -o bind portage/sysroot/binpkg/overlay etc) > portage/ > ... (the portage tree) > buildroot/ > ... (all cross compilation tools and a stage1 filesystem) > targets/ > arm-9tdmi-linux-gnu/ > cross-toolchain/ > configurations/(Continue reading)
Does anyone know of any Hard Real Time Systems, where deterministic response is required, that work with Gentoo-Embedded? -- -- http://www.softwaresafety.net/ http://www.designer-iii.com/ http://www.unusualresearch.com/
Bob Paddock wrote: > Does anyone know of any Hard Real Time Systems, > where deterministic response is required, that work > with Gentoo-Embedded? Um, the way you posed your question, is sure to solicit 'religious wars' on a few issues. Soft real time, means that timing constraints are soft or guildlines for process performance metrics. Hard real time, means the timing constraints are hard or an absolute requirement. Granted, most often these timing constraints are arbitrarily set, but a system that violates those arbitrary timing constraints is said to not be 'real time'. But think about if a missile, is suppose to change it's rudder in response to an AD input, in 150ns, does it mean that the missile as as system is a failure if the rudder response is 151 ns or 150.002 ns? Usually not the case, in fact rarely. The designer settle for the best (lowest latency) response in a particular subsystem that they can get. Determinism is another funny character. Real embedded systems use a 'state machine' design where every state or transition is fully characterized and defined. ON a large complex system, it is virtually impossible to discover, characterize, define and test all possible states of a complex system. (just look at the behavior of a single(Continue reading)
Hi, I really enjoyed your article, it was very compact and informative. Thnx, István -- Nyílt forráskód azokra az igazán nehéz napokra. BSA Open source for those really hard days. BSA http://www.osbusiness.hu -- -- gentoo-embedded@... mailing list
That's nearly perfect James - a really quick overview on tons of papers. Thanks. What do you think of probabilistic theory and system/OS controllable scheduling of sequential/parallel execution (actually fault tolerant) where instead of check pointing it relies on voting of SM responses, where a whole application is divided on several functionality-completed SMs; and missed deadlines of application parts are just a subset of covered faults (most of its faulty semantic hardened up to timing and/or crash failure semantics). As a result, it achieves a predictable HRT with a given reliability. rgs, alex
...forgot to send it on :-D Scal <at> Grid - site is still in dev, but may give some visibility http://sourceforge.net/projects/sgrid/ http://sgrid.sourceforge.net/ rgs, alex
momentics wrote: > That's nearly perfect James - a really quick overview on tons of papers. > Thanks. > > What do you think of probabilistic theory and system/OS controllable > scheduling of sequential/parallel execution (actually fault tolerant) > where instead of check pointing it relies on voting of SM responses, > where a whole application is divided on several > functionality-completed SMs; and missed deadlines of application parts > are just a subset of covered faults (most of its faulty semantic > hardened up to timing and/or crash failure semantics). > As a result, it achieves a predictable HRT with a given reliability Throwing 'slow curve_balls' at an old timer, is a dangerous affair, as you know.... voting is not new, only newly repackaged. Achievement of fault tolerance, is quite simple, when a fault occurs, your system continues to a valid conclusion. Whether you use check-pointing, roll back and recovery, voting, or some other methodology as the underlying mechanism, makes absolutely no difference to establishing the ability of a system to handle faults. (That's the slow part of your pitch you wanted me to take a swing at). Missed deadlines are exactly my thesis. Deadlines (timing constraints) are rarely anything but arbitrary. The fact that one can 'massage' a number as in the example of my previous posting on the missile rudder, is one case. What determines or establishes timing of one component in an overall system? And if you miss it by a very small margin, but consistently miss it by that very(Continue reading)
RSS Feed2 | |
|---|---|
19 | |
43 | |
28 | |
26 | |
9 | |
24 | |
31 | |
17 | |
32 | |
39 | |
60 | |
8 | |
43 | |
99 | |
37 | |
57 | |
51 | |
8 | |
6 | |
42 | |
4 | |
52 | |
53 | |
38 | |
15 | |
67 | |
18 | |
19 | |
39 | |
27 | |
63 | |
67 | |
18 | |
29 | |
112 | |
42 | |
7 | |
20 | |
15 | |
65 | |
43 | |
32 | |
12 | |
15 | |
84 | |
40 | |
33 | |
102 | |
75 | |
58 | |
92 | |
91 | |
86 | |
75 | |
68 | |
51 | |
50 | |
24 | |
69 | |
48 | |
52 | |
36 | |
55 | |
45 | |
147 | |
74 | |
107 | |
136 | |
48 | |
53 | |
43 | |
16 | |
55 | |
67 | |
47 | |
66 | |
55 | |
106 | |
64 | |
15 |
