compiler?
Andrew Elwell
I finally got the qemu toolchain up and running on my machine (yay!)
but I can't see a compiler in there --
I've done an opkg update (completed OK) but the only C++ ish things
are apps and the library uclibcxx - 0.2.2-3 - C++ library for embedded
systems
Annoyingly the file I need to build is relatively straightforward -
http://www.blitzortung.org/Documents/tracker_Linux.c
Can someone point me in the right direction?
Thanks
Andrew
Andrew Scheller
> but I can't see a compiler in there --
Qemu doesn't include a toolchain - it's just an emulator.
The "toolchain" part is in the 'openwrt' part of the git repository.
> Annoyingly the file I need to build is relatively straightforward -
> http://www.blitzortung.org/Documents/tracker_Linux.c
>
> Can someone point me in the right direction?
If it's only a single file you need to compile, you can simply compile
it as a static 32-bit executable on your regular Linux PC (assuming
you're running a 32-bit kernel & compiler - try a LiveCD if not) and
copy it across to the bifferboard - one of the advantages of
bifferboard using an x86-compatible CPU :)
Lurch
Andrew Elwell
> The "toolchain" part is in the 'openwrt' part of the git repository.
indeed, but if you select that at the 'make menuconfig' stage it falls
over with no rules to make target install. (and there's no* difference
to the current upstream head either)
> If it's only a single file you need to compile, you can simply compile
> it as a static 32-bit executable on your regular Linux PC (assuming
> you're running a 32-bit kernel & compiler - try a LiveCD if not) and
> copy it across to the bifferboard - one of the advantages of
> bifferboard using an x86-compatible CPU :)
threw together a VM and did this. still failed. Eventually hacked up
eniough of a makefile to get it running with the toolchain build (nice
n small)
... only to discover that the USB->Serial adaptor I had was missing
the kmod on the biffer factory firmware. Have built the new ones, now
need to re-flash with newer one
>
> Lurch
>
> --
> To unsubscribe send email to bifferboard...@googlegroups.com
* well, there's a minor diff in the Makefile, but nothing that adds
that functionality.
Andrew Scheller
>> The "toolchain" part is in the 'openwrt' part of the git repository.
> indeed, but if you select that at the 'make menuconfig' stage it falls
> over with no rules to make target install. (and there's no* difference
> to the current upstream head either)
I'm not sure that I follow what you're saying - are you following the
instructions from
https://sites.google.com/site/bifferboard/Home/openwrt-git ?
Ignore the stuff about SeaBIOS, the Qemu setup now uses BiffBoot
rather than SeaBIOS.
>> If it's only a single file you need to compile, you can simply compile
>> it as a static 32-bit executable on your regular Linux PC (assuming
>> you're running a 32-bit kernel & compiler - try a LiveCD if not) and
>> copy it across to the bifferboard - one of the advantages of
>> bifferboard using an x86-compatible CPU :)
>
> threw together a VM and did this. still failed.
Oh, any idea *why* it failed? Was it definitely a 32-bit static x86
(i486) executable you were building? Did it run in the VM?
> ... only to discover that the USB->Serial adaptor I had was missing
> the kmod on the biffer factory firmware. Have built the new ones, now
> need to re-flash with newer one
Yeah, the factory firmware is quite out of date (but "stable"), all
Biff's latest goodness is on github: https://github.com/bifferos/bb
Make sure you ignore the old repository
https://github.com/bifferos/openwrt though.
Andrew
biff...@yahoo.co.uk
On Mar 30, 1:41 pm, Andrew Scheller <ya...@loowis.durge.org> wrote:
> Yeah, the factory firmware is quite out of date (but "stable"), all
> Biff's latest goodness is on github:https://github.com/bifferos/bb
> Make sure you ignore the old repositoryhttps://github.com/bifferos/openwrtthough.
reason to keep it?
Biff.
Andrew Scheller
> I have been considering to delete that. Can anyone think of any
> reason to keep it?
Isn't it needed for GPL-ness?
https://sites.google.com/site/bifferboard/Home/factory-firmware
Lurch
biff...@yahoo.co.uk
On Mar 30, 1:49 pm, Andrew Scheller <ya...@loowis.durge.org> wrote:
> Isn't it needed for GPL-ness?https://sites.google.com/site/bifferboard/Home/factory-firmware
>
> Lurch
The source needs to be kept, but not the repository itself. Switching
the shipped units to the new git version is way overdue, and I can
perhaps do that for the next lot of boards. Anyhow, I may get some
flak for this, but I'm not sure if I can be bothered to comply with
the GPL in this respect. When I asked the OpenWrt developers how to
obtain source for a particular snapshot of OpenWrt they said 'search
the mailing list archives' or something like that. So I guess the
fact that they are contributing to the project makes it OK for them to
be in breach of GPL, because I'm pretty sure when I read the license
it said you have to provide the sources. It didn't say you can set
some brain-teaser, which, if solved gets the user the sources, it just
said provide the sources. It's not very specific about providing the
build configuration or makefiles either, or how much work the user
should have to go through to compile the sources.
However, in most cases, if not compliant with GPL the distributor is
requested to either comply with the GPL or cease distribution. In our
case ceasing distribution is not really a problem. The binaries we
ship are only for testing purposes, primarily testing the hardware
before shipping, and it would be pretty easy to erase before we send
the boards to the customer. So I've half a mind to just wait for that
formal complaint, and then change the production process, rather than
go through the considerable effort to back up snapshots of all sources
from all builds that we ship, that nobody requests the sources for
anyway. We have a git repo, so we are already streets ahead of most
of the far-eastern device manufacturers, it's possible that's enough
to satisfy everyone using the boards.
Usually, when users are using an out-of-date version of OpenWrt is
causes them problems, either stuff not working, or misunderstandings
on this forum, so shipping clean boards has some advantages. If the
first thing you have to do is compile and flash your board it might
not be such a bad thing.
Biff.