Is the Bifferboard so much different from a LINUX PC?
lutz
maybe my questions are absolutely stupid (I started LINUX only in
March 2010) maybe not (I started programming in 1973 with punched
cards).
Question 1:
Whenever I take a SD card out of the Biffboard 2 slot, insert it into
my Xubuntu 9.10 PC to copy some files, and later reinsert it into the
Bifferboard, a new /dev/sdx is created. Is there a way around that? I
do not want to mount the device everytime.
Q2: I have created the easiest of programs using Code::Blocks under
U9.10 and compiled it with the GNU GCC using the -486 compiler flag.
It runs fine on the PC. On the Bifferboard the executable program is
not even found, even though the source is there. A shell-script runs
also fine? What did I forget to do?
Q3: I have obviously a sort of pre Bifferboard-distro, i.e. everything
is loaded and runs from flash. I can use the SD card for permanent
files (once Q2 is solved). All files I install or copy into the
filesystem are lost at reboot including shell scripts that I want to
be executed at startup like the ntpdate program (and the installtion
is gone anyway).
On the other hand there is so much space left in flash memory, I want
to use it to keep files permanent like a startup shellscript, some
recorded data etc. without using the SD (I have a Bifferboard with
only one USB too which I will need for data collection). How do I
create a permanent filesystem there? Surely there is a way other than
recompiling the kernel with programs like the "HelloBiff" added (and
it would be no use for recorded data anyway). Btw the SheevaPlug can
be used without any problems even though there is also only flash
memory.
The log of my session is uploaded with the upload of the forum so you
can see what I was doing.
biff...@yahoo.co.uk
Hi Lutz,
I see no stupid questions at all :).
Q1
I think you can make hotplug mount the card when it's inserted
automatically, but I don't know how. Hopefully
someone else can help.
Q2
You need -static to get your program running on the Bifferboard. Also
you need to run it with './' at
the start if it's not in your path. Either copy it to /sbin, /bin
etc... or call it like this:
./hello_world
Q3
For running programs from ubifs, I suggest a modification to /etc/
preinit to mount ubifs and launch
a shell script/program from it. I haven't done this in the default
firmware because the intention is
to install a complete system to ubifs, then change the kernel command-
line to boot that, and only
use the shipping firmware as a kind of bootstrapping/installer
mechanism. It's unfinished due to
other stuff I'm doing, but that's the general idea.
So yes, you have to recompile the kernel/initrd to add your own stuff
and the shipping firmware is
just a demo, but you can easily make it so you never have to change it
again, by changing
/etc/preinit (or other start-up scripts). I will at some point
publish a firmware that does this, or
you can wait a bit.
regards,
Biff.
ernstoud
> Question 1:
> Whenever I take a SD card out of the Biffboard 2 slot, insert it into
> my Xubuntu 9.10 PC to copy some files, and later reinsert it into the
> Bifferboard, a new /dev/sdx is created. Is there a way around that? I
> do not want to mount the device everytime.
Do you execute a sync command and an unmount command BEFORE taking out
the SD card? Otherwise any write cache data is not flushed. My SD card
when taken out and reinserted again always gets the same device (/dev/
sda) when sync/unmount is performed.
If linux sees write errors to a device caused by write caches not
written out properly it will not mount any device again using that
device name. That could lead to serious data corruption on the just
inserted device (if the write cache would be flushed to another memory
device that is). I experience this myself on my vmware linux devices;
if I forget to do the unmount of an USB stick in vmware and reinsert
it again it will get a different device name (i.e. /dev/sda becomes /
dev/sdb etc.)
On your second question (and Biff's answer) I also find it rather
weird that linux does not find executables within the current
directory without the explicit reference to the directory (the
preceding ./). Any other OS that I know of searches default in the
current directory and then looks at any path specified. I reckon it is
one of linux security mechanisms that it takes getting used to.
Ernst
Edwin van den Oetelaar (Oetelaar Automatisering uit Best)
> On your second question (and Biff's answer) I also find it rather
> weird that linux does not find executables within the current
> directory without the explicit reference to the directory (the
> preceding ./). Any other OS that I know of searches default in the
> current directory and then looks at any path specified. I reckon it is
> one of linux security mechanisms that it takes getting used to.
This is not Linux specific.
Every unix shell since 30 years works like that.
The 'path' used for finding executables is searched front to back.
If it would work like you 'expect' you have a serious security problem.
For instance, an administrator types 'adduser' when his shell is in your home directory. (expecting
to run /sbin/adduser )
You put a file called 'adduser' there (with chmod +x flag) containing 'rm -R /etc' in it, what
happens...
Note that the command gets excuted with the administrator (root) rights....
If you want you could just do PATH=.:$PATH to add you directory as the first searched.
lutz
thanks for the rapid replies.
ad Q1)
hotplug was a good keyword. I found this in the web:
https://dev.openwrt.org/ticket/3432
which seemed exactly what I wanted.
However, after naively copying the files as indicated
(and altering the string in the ls-command to "/dev/sd*") nothing
happened.
I have no indication the script started at all (I had read something
about common.rc and enabling,
but this seemed to be a shortcut, whatever ...).
Syncing and unmounting works of course well, but then I have to create
the mount point
and mount again. I wanted it to be automatic like the hotplug suggests
and Ubuntu does.
ad Q2) well I DID use "./" for the hellobif program (see biff.log in
the files section)
and I have now even added "PATH=.:$PATH"; same result: "/bin/ash:
hellobif: not found".
After compiling the hellobif with gcc -static ... it found the program
(seems strange to me!=)
and ran it correctly.
What an achievement for mankind: almost 500 kByte code for a single
output line.
ad Q3:
For what I want: running a small program -at least in terms of lines
of code- that
listens to an usb-stick that attaches to our French teleinfo power
counter (something
like CurrentCost, but it gets the real value, i.e what you pay), even
the demo system is fine.
I just need available RAM-disk space after boot that has not been
erased.
Well I guess, I wait a more refined version of the "demo".
biff...@yahoo.co.uk
> ad Q2) well I DID use "./" for the hellobif program (see biff.log in
> the files section)
Hah! - Was being lazy and you caught me out!
> After compiling the hellobif with gcc -static ... it found the program
> (seems strange to me!=)
> and ran it correctly.
>
> What an achievement for mankind: almost 500 kByte code for a single
> output line.
Indeed. This shows the bloat in libc. If you want something smaller
investigate dietlibc.
Install from here:
http://www.fefe.de/dietlibc/
Crib my examples from here:
https://bifferboard.svn.sourceforge.net/svnroot/bifferboard/initrd/diet/
> Well I guess, I wait a more refined version of the "demo".
OK, in the meantime, this thread seems relevant:
http://groups.google.com/group/bifferboard/browse_thread/thread/a5e62d7dc667f588#
Biff.
biff...@yahoo.co.uk
I've updated the BMD page, with the three files you need to do the
'install-to-ubifs' steps:
http://sites.google.com/site/bifferboard/Home/bifferboard-mini-distribution
The file bzImage-initrd is the image that will ship with all new
boards now. It's switched from LZMA to gzip compression because that
gives a much faster decompression, and still fits in the lowest 2MB of
flash. The config for this kernel can be found here:
https://bifferboard.svn.sourceforge.net/svnroot/bifferboard/kernel/2.6.30.5/config-bmd-initrd
If anything isn't clear, let me know.
cheers,
Biff.
On Apr 9, 10:29 pm, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:
> OK, in the meantime, this thread seems relevant:http://groups.google.com/group/bifferboard/browse_thread/thread/a5e62...
>
> Biff.
lutz
On 10 Apr., 00:06, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:
...
> If anything isn't clear, let me know.
...
Well, ahem, yes there are some very basic questions (sort of: Q: what
do you see on your screen? A: a vase with flowers!)
I assumed to "get the files from sourceforge" you need to do something
I am not familar with (install svn? and then do what?)
well I copied and pasted the files (no good with binaries, but this
was "text") on my Ubunto-PC (correct? there is no Python on the
bifferboard!)
I ran build.sh and after some minutes got this:
...
checking whether to build static libraries... yes
configure: creating libtool
checking for pkg-config... no
checking for CURL... configure: error: in `/home/lutzi/bifferboard/
opkg-0.1.8':
configure: error: The pkg-config script could not be found or is too
old. Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.
Alternatively, you may set the environment variables CURL_CFLAGS
and CURL_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
To get pkg-config, see <http://pkg-config.freedesktop.org/>.
See `config.log' for more details.
make: *** [opkg-0.1.8/src/opkg-cl] Error 1
cd `pwd`/root && tar zcf ../bmd-root.tgz .
cd: 1: can't cd to /home/lutzi/bifferboard/root
make: *** [tarball] Error 2
lutzi@ubuntu:~/bifferboard$ ls -all
total 460
drwxr-xr-x 3 lutzi lutzi 4096 2010-04-13 21:00 .
drwxr-xr-x 30 lutzi lutzi 4096 2010-04-13 21:07 ..
-rwxrwxrwx 1 lutzi lutzi 270 2010-04-13 20:53 build.sh
-rw-r--r-- 1 lutzi lutzi 4249 2010-04-13 20:54 makecpio
-rw-r--r-- 1 lutzi lutzi 1096 2010-04-13 20:52 Makefile
drwxr-xr-x 10 lutzi lutzi 4096 2010-04-13 21:00 opkg-0.1.8
-rw-r--r-- 1 lutzi lutzi 437009 2010-02-22 00:27 opkg-0.1.8.tar.gz
-rw-r--r-- 1 lutzi lutzi 101 2010-04-13 20:55 opkg.conf
lutzi@ubuntu:~/bifferboard$ cat *.conf
src/gz snapshots http://bifferos.planetlee.eu/bmd/packages
lists_dir ext var/opkg-lists
arch i386 1
so, what did I do wrong?
actually it would help me if it was clearly (for me!) indicated WHERE
you need to do things (what machine? which dir)
b) if finally this runs, do I have to copy (what file? the *.gz?) onto
the SD and insert it in the Bifferboard?
thanks for being patient!
Lutz
biff...@yahoo.co.uk
It tells you what you did wrong. You don't have pkg-config.
Get yourself a proper Linux distribution, e.g. Slackware <grin> and
install *everything*, then that build will probably work.
However... you don't have to do that. I provided the kernel + initrd,
the kernel without initrd and the tarball. That's all you need.
It shouldn't be hard to understand if you follow a Windows/Linux
installation analogy: You have a bootable DVD, you insert DVD, change
BIOS to boot from DVD, copy files to hard disk, change BIOS to boot
from hard disk, and away you go.
You'll do the same thing with my images: bzImage-initrd is the DVD.
Flash it, change command-line to boot it, then use that to copy the
tarball from a webserver somewhere (you'll have to set that up
somehow). Install tarball onto ubifs over the net, then change
command-line to boot that instead.
Biff.
> src/gz snapshotshttp://bifferos.planetlee.eu/bmd/packages
lutz
On 13 Apr., 22:17, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:
> It tells you what you did wrong. You don't have pkg-config.
>
> Get yourself a proper Linux distribution, e.g. Slackware <grin> and
> install *everything*, then that build will probably work.
just for grins I installed a couple of packages and it worked, ok.
> However... you don't have to do that. I provided the kernel + initrd,
> the kernel without initrd and the tarball. That's all you need.
correct, you attached the files at the end of your link but did not
refer to the place in the text; so naturally I overlooked them.
>
> It shouldn't be hard to understand if you follow a Windows/Linux
> installation analogy: You have a bootable DVD, you insert DVD, change
> BIOS to boot from DVD, copy files to hard disk, change BIOS to boot
> from hard disk, and away you go.
>
> You'll do the same thing with my images: bzImage-initrd is the DVD.
> Flash it, change command-line to boot it, then use that to copy the
> tarball from a webserver somewhere (you'll have to set that up
> somehow). Install tarball onto ubifs over the net, then change
> command-line to boot that instead.
I do understand. Effectively with the system I have I am at step 2,
running from initrd
(at least the console-command looks the same as in my boot).
That´s what I complained about in my first post: after reboot
everything I have installed is lost.
So now I try to mount /ubifs, but the system cannot read fstab which
points to /tmp/fstab which is not there.
What is this?
biff...@yahoo.co.uk
> > However... you don't have to do that. I provided the kernel + initrd,
> > the kernel without initrd and the tarball. That's all you need.
>
> correct, you attached the files at the end of your link but did not
> refer to the place in the text; so naturally I overlooked them.
I refered to them in the email where I told you about the link. See
above. They were added purely for your benefit, some time after I'd
written the text, so yes, text and files don't match.
> > It shouldn't be hard to understand if you follow a Windows/Linux
> > installation analogy: You have a bootable DVD, you insert DVD, change
> > BIOS to boot from DVD, copy files to hard disk, change BIOS to boot
> > from hard disk, and away you go.
>
> > You'll do the same thing with my images: bzImage-initrd is the DVD.
> > Flash it, change command-line to boot it, then use that to copy the
> > tarball from a webserver somewhere (you'll have to set that up
> > somehow). Install tarball onto ubifs over the net, then change
> > command-line to boot that instead.
>
> I do understand. Effectively with the system I have I am at step 2,
> running from initrd
> (at least the console-command looks the same as in my boot).
> That´s what I complained about in my first post: after reboot
> everything I have installed is lost.
>
> So now I try to mount /ubifs, but the system cannot read fstab which
> points to /tmp/fstab which is not there.
>
> What is this?
Have you flashed "bzImage-initrd"?
lutz
On Apr 14, 1:41 am, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:
> On Apr 14, 12:14 am, lutz <l...@bickhardt.fr> wrote:
...
>
> > So now I try to mount /ubifs, but the system cannot read fstab which
> > points to /tmp/fstab which is not there.
>
> > What is this?
>
> Have you flashed "bzImage-initrd"?
now I have, same result, different cause.
both the mount and the console command do not work
I will upload the log next.
biff...@yahoo.co.uk
from Biffboot.
lutz
On 14 Apr., 14:54, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:
> Saw the log, looks like your flash isn't formatted. Use ubiformat
> from Biffboot.
>
great! worked! why not in the first place?
another wall I ran into: what is the wget from busybox for
wget http://u:p...@1.2.3.4/x/y for user u and password p?
so I downloaded from your webpage
perfect, but decompressing it with tar -xv put me in a loop with no
output at all for 5 minutes before I ctrl-Ced it and
gzip -d x tells me something about an unrecognized suffix"
renamed the file to have a .gz suffix, but now "gzip:
invalid magic"
and idea?
biff...@yahoo.co.uk
On Apr 14, 6:09 pm, lutz <l...@bickhardt.fr> wrote:
> On 14 Apr., 14:54, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
> wrote:
>
> > Saw the log, looks like your flash isn't formatted. Use ubiformat
> > from Biffboot.
>
> great! worked! why not in the first place?
I'm guessing because of the bug I fixed in v3.1 of Biffboot:
http://sites.google.com/site/bifferboard/Home/bootloader/changelog
(first in the list)
>
> another wall I ran into: what is the wget from busybox for
> wget http://u:p...@1.2.3.4/x/y for user u and password p?
> so I downloaded from your webpage
Yeah - no idea 'bout that.
> perfect, but decompressing it with tar -xv put me in a loop with no
> output at all for 5 minutes before I ctrl-Ced it and
> gzip -d x tells me something about an unrecognized suffix"
> renamed the file to have a .gz suffix, but now "gzip:
> invalid magic"
>
> and idea?
No idea whatsoever, but maybe you can reconstruct the tarfile without
the gzip compression (.tar) and try again. You can try netcat (nc) if
you're unable to setup a webserver. I'm pretty sure that's supplied
on my initrd image.
Biff.
lutz
On 14 Apr., 19:21, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:
>
...
>
> > and idea?
>
> No idea whatsoever, but maybe you can reconstruct the tarfile without
> the gzip compression (.tar) and try again. You can try netcat (nc) if
> you're unable to setup a webserver. I'm pretty sure that's supplied
> on my initrd image.
>
> Biff.
I just continued and put in the console command you provided, it comes
out with "/bin/ash: ubi.mtd=rootfs: not found"
ok, maybe that is due to the fact that I could not decompress?
HOWEVER, I rebooted just to check and guess what? The file I could not
decompress was still there.
So: this is what I wanted: having files I downloaded before ready to
use. Well I probably cannot yet install packages, but that is still
something.
One question: am I the first one to run into these problems?
Regards and thanks!
biff...@yahoo.co.uk
> On 14 Apr., 19:21, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
> wrote:
> ...
>
> > > and idea?
>
> > No idea whatsoever, but maybe you can reconstruct the tarfile without
> > the gzip compression (.tar) and try again. You can try netcat (nc) if
> > you're unable to setup a webserver. I'm pretty sure that's supplied
> > on my initrd image.
>
> > Biff.
>
> I just continued and put in the console command you provided, it comes
> out with "/bin/ash: ubi.mtd=rootfs: not found"
Please google 'kernel command-line'.
> ok, maybe that is due to the fact that I could not decompress?
>
> HOWEVER, I rebooted just to check and guess what? The file I could not
> decompress was still there.
>
> So: this is what I wanted: having files I downloaded before ready to
> use. Well I probably cannot yet install packages, but that is still
> something.
>
> One question: am I the first one to run into these problems?
There is a lot of assumed knowledge in embedded Linux. You need to be
a Linux expert before you start. Starting with embedded is the wrong
way to learn Linux. Also, you need to be prepared to read around the
subject, which is the thing newbies rarely want to do, e.g. you could
read about ubifs, you could understand what a kernel command-line is,
etc...
Finally, you need to be prepared to try things. E.g. I had to prompt
you to try my bzImage-initrd, I knew it was probably different to what
you had on your board at that time, but you never bothered until I
suggested. So, you prefer to post another question, instead of trying
something that would take 2 minutes.
You're not the first person to behave in this way, and you won't be
the last, and I can understand perfectly, because I was once like that
(I think we all were), but getting stuff done in Linux - before
everyone on the list gets bored and stops answering your emails - has
a lot more to do with your general attitude and approach rather than
specific pieces of knowledge.
I guess I'm not helping because I answer emails too quickly, and that
gets you into bad habits! Anyhow, I think you are virtually there,
I'll let someone else take over now for a while, as other stuff is
catching up on me!... :).
regards,
Biff.
lutz
wrote:
...
Well, sorry you run out of patience, I do appreciate your fast answers
though.
Let me just express some general thoughts as well.
>
> > One question: am I the first one to run into these problems?
>
> There is a lot of assumed knowledge in embedded Linux. You need to be
> a Linux expert before you start. Starting with embedded is the wrong
> way to learn Linux. Also, you need to be prepared to read around the
> subject, which is the thing newbies rarely want to do, e.g. you could
> read about ubifs, you could understand what a kernel command-line is,
> etc...
Clearly, you are right with what you say. However, I am not interested
in UNIX or LINUX as such, it is just a more complicated and complex OS
than the VAX/VMSes and IBM/MVSes of my time. Do you really think that
a wget really need that many parameters to get things done?
What I am interested in is getting things to do what they are supposed
to do.
You start by reading about it (in this case the Bifferboard) in the
web and think,
great! just what I needed! Then you consult all the wisdom and forums
and man pages
and wikis that Google puts at your fingertips and you try to figure
out what do do first.
Usually one would assume that you start a device up and it does what
the doc says.
With embedded linux (in general, no particular assault at the
Bifferboard) it seems first
you have to download, make, tweak, flash, guess and google
your way around to finally arrive at a state close to what you
expected.
>
> Finally, you need to be prepared to try things. E.g. I had to prompt
> you to try my bzImage-initrd, I knew it was probably different to what
> you had on your board at that time, but you never bothered until I
> suggested. So, you prefer to post another question, instead of trying
> something that would take 2 minutes.
Then after having sorted out all the outdated, unrelevant and obsolte
things
you are somehow stuck because after a couple of hours reading, trying,
rebooting
you just run out of ideas and dare to ask around. Of course it takes
only two
minutes for the one having built the wall to realize someone is going
to hit it,
because unfortunately that traffic sign was posted in the wrong
direction.
What I mean is that instead of spreading the hints around in various
places,
why not make a step by step guide as to how to do things for a
particular version
with precise logs and commands so there is no guessing just the facts.
This
way even a newbie could use the product and maybe buy some more boards
because
his application gets bought by others.
>
> You're not the first person to behave in this way, and you won't be
> the last, and I can understand perfectly, because I was once like that
> (I think we all were), but getting stuff done in Linux - before
> everyone on the list gets bored and stops answering your emails - has
> a lot more to do with your general attitude and approach rather than
> specific pieces of knowledge.
Since you are talking about attitude I have to remark that personally
I would
like to have things easier (because they are well documented and work)
than
complicated (because they are ueber-complex, over-documented and do
not work as
described on top). And, may I finish this remark with an observation I
have been able
to make in more than 30 years working with IT folks, it is the
developper that is
responsible for that not the user.
>
> I guess I'm not helping because I answer emails too quickly, and that
> gets you into bad habits! Anyhow, I think you are virtually there,
> I'll let someone else take over now for a while, as other stuff is
> catching up on me!... :).
Yes, you were helping, there was really no need for pedagogic and
missonary
gaps in your replies, so I did appreciate them, because I was
frustrated enough.
However, I am not only complaining, I also have a contribution to
make. I will upload
a small Python script called bb_console.py that I extracted from the
bb_upload-files.
It does what the name implies, you call it and it connects you to the
bifferboard. No
need for putty and other terminal emulators. This gift is of course
poisoned, it may be
too easy to use ;-)
Btw. the bb_eth_upload.py returned without any hint as to why it was
not working,
maybe I will try to debug it, if there are no known reasons for this.
>
> regards,
> Biff.
cordialement
Lutz
biff...@yahoo.co.uk
All valid comments - but there is one thing I have to correct. I
didn't run out of patience, I just ran out of time. There is a big
difference. All the time I spend teaching you about Linux is time I
cannot spend improving the software for the Bifferboard, and there are
other things in my life, e.g. a really annoying rear brake drum on my
car which just refused to come off the hub last night. Grrr...
Andrew Scheller
> car which just refused to come off the hub last night. Grrr...
You obviously need to hack your car so your brakes are
bifferboard-controlled ;-)
Lurch
(In case any lawyers are reading - that was a joke, so no suing me for
any fatal accidents!)
D. Rimron
> I guess I'm not helping because I answer emails too quickly,
>
ask there" and "google this, get results, help yourself, bye" - since it
stops the mailing list getting clogged up with pointless/out of context
junk. :)
-Dx