gcwnow / buildroot Goto Github PK

Buildroot customized for the GCW0

License: GNU General Public License v2.0

Makefile 66.00% Arc 0.01% Shell 6.22% C 15.75% Python 7.51% Groff 0.01% C++ 2.12% Perl 1.48% Batchfile 0.01% Lex 0.27% Yacc 0.62%

buildroot's Introduction

To build and use the buildroot stuff, do the following:

1) run 'make menuconfig'
2) select the packages you wish to compile
3) run 'make'
4) wait while it compiles
5) Use your shiny new root filesystem. Depending on which sort of
    root filesystem you selected, you may want to loop mount it,
    chroot into it, nfs mount it on your target device, burn it
    to flash, or whatever is appropriate for your target system.

You do not need to be root to build or run buildroot.  Have fun!

Offline build:
==============

In order to do an offline-build (not connected to the net), fetch all
selected source by issuing a
$ make source

before you disconnect.
If your build-host is never connected, then you have to copy buildroot
and your toplevel .config to a machine that has an internet-connection
and issue "make source" there, then copy the content of your dl/ dir to
the build-host.

Building out-of-tree:
=====================

Buildroot supports building out of tree with a syntax similar
to the Linux kernel. To use it, add O=<directory> to the
make command line, E.G.:

$ make O=/tmp/build

And all the output files (including .config) will be located under /tmp/build.

More finegrained configuration:
===============================

You can specify a config-file for uClibc:
$ make UCLIBC_CONFIG_FILE=/my/uClibc.config

And you can specify a config-file for busybox:
$ make BUSYBOX_CONFIG_FILE=/my/busybox.config

To use a non-standard host-compiler (if you do not have 'gcc'),
make sure that the compiler is in your PATH and that the library paths are
setup properly, if your compiler is built dynamically:
$ make HOSTCC=gcc-4.3.orig HOSTCXX=gcc-4.3-mine

Depending on your configuration, there are some targets you can use to
use menuconfig of certain packages. This includes:
$ make HOSTCC=gcc-4.3 linux-menuconfig
$ make HOSTCC=gcc-4.3 uclibc-menuconfig
$ make HOSTCC=gcc-4.3 busybox-menuconfig

Please feed suggestions, bug reports, insults, and bribes back to the
buildroot mailing list: [email protected]

buildroot's People

Contributors

Stargazers

Watchers

Forkers

frantony gromv fanicy dmitrysmagin zear 0x64c gnaghi zemonade senquack padawin amigori tonyjih dnasdw sanikoyes hex55 martinx72 shadowapex shockdesign

buildroot's Issues

RTC drift

The RTC in my Zero is drifting at about +0.4-0.5 min / day -- more if I use it. I saw that there was some kind of RTC-related work in the last firmware release. Are there any more RTC fixes planned?

Enabling linkdev's 'alternate key mapping' input method causes SDL 2.0 to issue unrecognized keypress messages

This behavior does not occur with the public 8-20-2014 firmware, only with newer unreleased beta firmware dated 2014-11-23. SDL 1.2 behaves the same as the old firmware. SDL 2.0 does not, however:

From the command line, use opkrun to run Nebuleon's SDL2.0 version of his input tester: 'opkrun -m jstester-2.gcw0.desktop input-test.opk' Alternatively, run a SDL2.0 app directly from the command line after issuing following command: echo Y > /sys/devices/platform/linkdev/alt_key_map

Any button presses, excluding the DPAD, will cause the following message to show on stdout:
'INFO: The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL mailing list [email protected] EVDEV KeyCode 3XX' Where 3XX corresponds to each unique button press.

Despite these messages, the alternate key-to-joy-event mapping is indeed functioning. If you disable the key-to-joy-event mapping, SDL does not report these errors and receives SDL_KEYUP/SDL_KEYDOWN events from the buttons, as normal, with no complaints of unrecognized evdev keycodes.

m4 package compilation issue

Please see issue description over here
https://lists.gnu.org/archive/html/bug-m4/2018-08/msg00000.html

Maybe
package/m4/m4.mk
7:M4_VERSION = 1.4.17 -> 1.4.19 ?

Downloads from Sourceforge failing with "make gcw0_defconfig"

I end up having to manually download each Sourceforge tar archive, because the script no longer pulls the archive properly (downloads the webpage instead of the file is my guess).

Output error:

>>> p7zip 9.20.1 Downloading
--2015-04-19 21:36:18--  http://downloads.sourceforge.net/project/p7zip/p7zip/9.20.1/p7zip_9.20.1_src_all.tar.bz2
Resolving downloads.sourceforge.net (downloads.sourceforge.net)... 216.34.181.59
Connecting to downloads.sourceforge.net (downloads.sourceforge.net)|216.34.181.59|:80...  connected.
HTTP request sent, awaiting response... 307 Temporary Redirect
Location: http://sourceforge.net/projects/p7zip/files/p7zip/9.20.1/p7zip_9.20.1_src_all.tar.bz2/download?use_mirror=colocrossing [following]
--2015-04-19 21:36:18--  http://sourceforge.net/projects/p7zip/files/p7zip/9.20.1/p7zip_9.20.1_src_all.tar.bz2/download?use_mirror=colocrossing
Resolving sourceforge.net (sourceforge.net)... 216.34.181.60
Connecting to sourceforge.net (sourceforge.net)|216.34.181.60|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 14580 (14K) [text/html]
Saving to: ‘/home/larry/Downloads/NathanStuff/N64/buildroot/dl/p7zip_9.20.1_src_all.tar.bz2.tmp’

100%[======================================>] 14,580      --.-K/s   in 0.04s

2015-04-19 21:36:19 (335 KB/s) - ‘/home/larry/Downloads/NathanStuff/N64/buildroot/dl/p7zip_9.20.1_src_all.tar.bz2.tmp’ saved [14580/14580]

>>> p7zip 9.20.1 Extracting
bzcat /home/larry/Downloads/NathanStuff/N64/buildroot/dl/p7zip_9.20.1_src_all.tar.bz2 | tar --strip-components=1 -C /home/larry/Downloads/NathanStuff/N64/buildroot/output/build/p7zip-9.20.1  -xf -
bzcat: /home/larry/Downloads/NathanStuff/N64/buildroot/dl/p7zip_9.20.1_src_all.tar.bz2 is not a bzip2 file.
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
make: *** [/home/larry/Downloads/NathanStuff/N64/buildroot/output/build/p7zip-9.20.1/.stamp_extracted] Error 2

There have been 100's of these, and I am having to redownload every single one... *sigh

request for pyalsaaudio / python-alsaaudio support

If we have http://pyalsaaudio.sourceforge.net/ (in the same way there is PyGame support in https://github.com/gcwnow/buildroot/tree/opendingux-2012.08/package/python-pygame) we could record audio from Python.

With pyalsaaudio support , microphones testing could be added to https://bitbucket.org/clach04/hwtest/wiki/Home

Using test firmware dated 2014-11-23, SDL2.0 receives random mouse motion events

In test firmware dated 2014-11-23, I experienced random MOUSEMOTION events in my port of Neverball, which uses SDL 2.0. These occur about every 5 seconds or so if the unit is just left sitting running the program. If you move the analog joystick, the events are numerous and seem to coincide with the JOYAXISEVENTS the analog issues.

You can easily verify/reproduce the behavior by running the event-loop-sdl-2 binary in the bin/ folder of this small console-mode example program I put together to show the problem: https://github.com/senquack/event-loop-example

WiFi doesn't work with symbols

It looks like you're using either shell calls or something else that needs special-character escaping in the new Connect utility. However it works, it doesn't with properly random WPA2 keys with special characters.

I finally got it working with my local network by finding the Connect settings under /media/data/local/home/.local/share/gcwconnect/networks , editing the file, and replacing the double quotes around the WPA2 key with single quotes.

Of course, anyone with single quotes in their WPA2 key is going to be out of luck.

MXU MIPS instruction set extension

I was wondering, did your project write commit 6c2a690? If so, where did you find documentation on the MXU instructions? If not, where did you find the patch?

I've been looking for more information on the ISE, but I've only been able to find the Dingoonity wiki page, jzmedia.h in libjzcommon, mxu_as (that massive Bash script that filters assembly to replace MXU instructions with .word directives), and a few disparate mentions on mailing lists.

This is not an issue

G-sensor does not work under beta firmware (post-August 20th 2014 test firmware)

Under test firmware 2014-11-23, the g-sensor does not work, or at least does not work as before. From the command line, you can start the g-sensor module using 'gsensor --start' and see that its module gets loaded with 'lsmod'.

However, both SDL 1.2 and SDL2.0 only report 1 joystick available, whereas under the last public release, two would be reported and the G-sensor's reported name would be 'mxc6225'

It is easy to reproduce this behavior: simply try to run Nebuleon's SDL2.0 version of his input tester. Alternatively, run Neverball. Neither reports finding more than one joystick and neither finds the g-sensor. Also, none of the devices in /dev/input/ show anything when running 'cat' on them and moving the unit about. There also is no symlink created from /dev/input/gsensor to the device file, not that this in itself indicates a bug.

cant build from a directory with spaces in the name

The title is self-explanatory. :)