GPIO support

[biff...@yahoo.co.uk]

I was getting a bit fed up with my JTAG experiments (2 weeks and
hardly any progress), so I decided to try something a bit easier
starting from this morning.

So I've added GPIO sysfs support to 2.6.30.5, however I need testers,
not only for the basic GPIO functionality, but also to see if the i2c
modules can be layered on top of this to solve the issues people were
previously seeing. I suspect that this will also allow MMC support,
albeit with somewhat slow data rates. If nothing else, it will allow
folk to get/set pins without having to write kernel modules or dicky
little programs like biff-gpio.

If all goes well, I'll try to submit this to LKML.

Google sites has been jerking me around today, but seems
intermittently available. I've added the patch and description of how
to use the functionality here:

http://sites.google.com/site/bifferboard/Home/gpio
(see bottom of the page).

regards,
Biff.

[Nelson Neves]

I'll be back from vacations Monday! You can count me in for the tests!

Will cross my fingers this time ;)

Thanks for your persistence with the I2C issue,

Regards.

[Razvan Dragomirescu]

Hey Biff, I'll give it a try too, I've always meant to try to figure out a way to do this. Good work!

 

Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

[Razvan Dragomirescu]

Hello again Biff,

It doesn't appear to work for me, I've applied the patch to 2.6.30.1 though, not to 2.6.30.5. Everything looks fine, compilation works, then I do:

echo 16 > /sys/class/gpio/export (works fine)

echo out > /sys/class/gpio/gpio16/direction (also works fine)

echo 0 > /sys/class/gpio/gpio16/value (nothing happens)
echo 1 > /sys/class/gpio/gpio16/value (nothing happens either)


So it just doesn't turn the LED on or off, it's always lit.

Any ideas?

R.

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

[Nelson Neves]

My question, I have the Bifferboard OnFlashSystem up and running with kernel version 2.6.30.2, will the available patch work or do I really need the 2.6.30.5 ???

Regards,

Nelson.

ps: will test this tonight, will only have access to hardware later (back from vacations)!

[bifferos]

I've just uploaded a new version of the patch (v2) today. This
shouldn't make much difference, but you can try that.
In my case, setting the direction to 'out' immediately turns on the
LED.

Is your kernel a clean kernel, could it be you have another driver
accessing GPIO pins?

On Aug 31, 2:54 pm, Razvan Dragomirescu

<razvan.dragomire...@gmail.com> wrote:
> Hello again Biff,
>
> It doesn't appear to work for me, I've applied the patch to 2.6.30.1 though,
> not to 2.6.30.5. Everything looks fine, compilation works, then I do:
>
> echo 16 > /sys/class/gpio/export (works fine)
> echo out > /sys/class/gpio/gpio16/direction (also works fine)
>
> echo 0 > /sys/class/gpio/gpio16/value (nothing happens)
> echo 1 > /sys/class/gpio/gpio16/value (nothing happens either)
>
> So it just doesn't turn the LED on or off, it's always lit.
>
> Any ideas?
>
> R.
>
> --
> Razvan Dragomirescu
> Chief Technology Officer
> Cayenne Graphics SRL
>
> On Mon, Aug 31, 2009 at 1:48 AM, Razvan Dragomirescu <
>

> razvan.dragomire...@gmail.com> wrote:
> > Hey Biff, I'll give it a try too, I've always meant to try to figure out a
> > way to do this. Good work!
>
> > Razvan
>
> > --
> > Razvan Dragomirescu
> > Chief Technology Officer
> > Cayenne Graphics SRL
>

[bifferos]

It seems the patch applies to 2.6.30.1, however using 2.6.30.5 is also
very easy. Simply copy exactly the same initramfs.cpio that you used
with the old kernel and you should get a boot.

On Aug 31, 2:59 pm, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> My question, I have the Bifferboard OnFlashSystem up and running with kernel
> version 2.6.30.2, will the available patch work or do I really need the
> 2.6.30.5 ???
>
> Regards,
>
> Nelson.
>
> ps: will test this tonight, will only have access to hardware later (back
> from vacations)!
>
> On Mon, Aug 31, 2009 at 2:54 PM, Razvan Dragomirescu <
>

[Razvan Dragomirescu]

My apologies, it works fine, I was just looking at the blue LED instead :(. BTW, is there any way to control that LED with GPIO? The red LED is not visible on the outside of the plastic enclosure and it's hard to see of a user that is just looking at a close enclosure? Can we control the green or blue LEDs that have holes in the plastic case for them?

Thanks,
Razvan

[bifferos]

Easy mistake to make :-).

I'm afraid the blue is connected to the switcher, and the green to the
ethernet media, so unless you want to send lots of packets, no.

Biff.

On Aug 31, 7:29 pm, Razvan Dragomirescu

[Razvan Dragomirescu]

That's ok, it was just an experiment :). BTW, what pin number do we use to get the "reset button" status? With all this mapping and remapping I'm getting a little confused :).

 

Cheers,

Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

[Nelson Neves]

From http://bifferos.bizhat.com/pinouts/

Red LED (RTCRD/GPIO16)
Reset button (RTCAS/GPIO15)

2	JTAG TMS / GPIO11
3	JTAG TDI / GPIO13
4	JTAG TDO / GPIO9
5	JTAG TCK / GPIO12

Think that reset will be 15, I guess!

Regards,

Nelson.

[bifferos]

This patch is completely generic, and can theoretically be used with
any RDC chip. It's supposed to be of a sufficiently high standard to
be included in Linux (cough), and I'll submit it if no problems are
found. GPIO pin numbers follow those found in the RDC datasheets for
R8610, R3282, R3210 (GPIOs 0-59).

By coincidence GPIO numbers here: http://bifferos.bizhat.com/pinouts/
still map to the GPIO numbers in the patch, because the GPIO bank used
by Bifferboard is the first bank (phew!).

Previous patches were Bifferboard specific, and made use of the fact
that only one GPIO bank is ever of interest to Bifferboard users, and
more specifically that only 6 lines on that bank can be used. This is
obviously the wrong approach if we ever want to see RDC GPIO support
in the mainline kernel, so we will now stick to the world according to
RDC when it comes to pin numbers.

thanks,
Biff.


On Aug 31, 8:45 pm, Razvan Dragomirescu

<razvan.dragomire...@gmail.com> wrote:
> That's ok, it was just an experiment :). BTW, what pin number do we use to
> get the "reset button" status? With all this mapping and remapping I'm
> getting a little confused :).
>
> Cheers,
> Razvan
>
> --
> Razvan Dragomirescu
> Chief Technology Officer
> Cayenne Graphics SRL
>

[Nelson Neves]

Hi,

I've been having some hard time trying to get this to work on my OnFlashSystem with kernel 2.6.30.2, some tips would be very welcome. I followed the instructions from here:
http://sites.google.com/site/bifferboard/Home/howto/faster-route-to-kernel--initrd

Being a bit dumb I have create this set of custom script to automate the creation of the OnFlashSystem (just need to run the script on the numeric order):
http://botdream.com/bifferboard/onflashsystem/bifferboardflash.tar.gz

This seems to be working (I only tested the basic stuff, don't know if I have all the necessary patches applied correctly). But I'm having some difficulty applying the gpio patches from here:
http://sites.google.com/site/bifferboard/Home/gpio

I got this:
./7-applypatches
patching file drivers/gpio/Kconfig
Hunk #2 succeeded at 189 (offset -12 lines).
patching file drivers/gpio/Makefile
Hunk #1 FAILED at 14.
1 out of 1 hunk FAILED -- saving rejects to file drivers/gpio/Makefile.rej
patching file drivers/gpio/rdc321x_gpio.c
patching file drivers/gpio/Kconfig
Hunk #1 succeeded at 75 with fuzz 2 (offset 12 lines).
Hunk #2 FAILED at 215.
1 out of 2 hunks FAILED -- saving rejects to file drivers/gpio/Kconfig.rej
patching file drivers/gpio/Makefile
Hunk #1 FAILED at 14.
1 out of 1 hunk FAILED -- saving rejects to file drivers/gpio/Makefile.rej
The next patch would create the file drivers/gpio/rdc321x_gpio.c,
which already exists!  Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/gpio/rdc321x_gpio.c.rej


from Kconfig.rej
*************** config GPIO_MCP23S08
*** 201,203 ****
        a GPIO interface supporting inputs and outputs.
 
  endif
--- 215,220 ----
        a GPIO interface supporting inputs and outputs.
 
  endif
+
+
+

from Makefile.rej
*************** obj-$(CONFIG_GPIO_TWL4030)    += twl4030-gpio.o
*** 14,16 ****
  obj-$(CONFIG_GPIO_XILINX)    += xilinx_gpio.o
  obj-$(CONFIG_GPIO_BT8XX)    += bt8xxgpio.o
  obj-$(CONFIG_GPIO_VR41XX)    += vr41xx_giu.o
--- 14,17 ----
  obj-$(CONFIG_GPIO_XILINX)    += xilinx_gpio.o
  obj-$(CONFIG_GPIO_BT8XX)    += bt8xxgpio.o
  obj-$(CONFIG_GPIO_VR41XX)    += vr41xx_giu.o
+ obj-$(CONFIG_GPIO_RDC321X)    += rdc321x_gpio.o

from rdc321x_gpio.c.rej
... very long text


Please note that I don't have experience with this, only followed the wiki and tried to put the pieces together, please apologize for any dumb mistake!

Also tried with kernel 2.6.30.5 making small adjustments into my scripts but It also fails whem applying the gpio patches.

Regards,

Nelson.

[bifferos]

I've just uploaded version 3 - try that instead (with 2.6.30.5).

cheers,
Biff.

On Sep 1, 1:13 am, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> Hi,
>
> I've been having some hard time trying to get this to work on my
> OnFlashSystem with kernel 2.6.30.2, some tips would be very welcome. I

> followed the instructions from here:http://sites.google.com/site/bifferboard/Home/howto/faster-route-to-k...

> *from Kconfig.rej*

> *************** config GPIO_MCP23S08
> *** 201,203 ****
>         a GPIO interface supporting inputs and outputs.
>
>   endif
> --- 215,220 ----
>         a GPIO interface supporting inputs and outputs.
>
>   endif
> +
> +
> +
>

> *from Makefile.rej*

> *************** obj-$(CONFIG_GPIO_TWL4030)    += twl4030-gpio.o
> *** 14,16 ****
>   obj-$(CONFIG_GPIO_XILINX)    += xilinx_gpio.o
>   obj-$(CONFIG_GPIO_BT8XX)    += bt8xxgpio.o
>   obj-$(CONFIG_GPIO_VR41XX)    += vr41xx_giu.o
> --- 14,17 ----
>   obj-$(CONFIG_GPIO_XILINX)    += xilinx_gpio.o
>   obj-$(CONFIG_GPIO_BT8XX)    += bt8xxgpio.o
>   obj-$(CONFIG_GPIO_VR41XX)    += vr41xx_giu.o
> + obj-$(CONFIG_GPIO_RDC321X)    += rdc321x_gpio.o
>

> *from rdc321x_gpio.c.rej*

[Jason]

Biff,

Do you know if the pins marked NS on the expansion board connectors
are wired up on the main board or not (I've not been able to trace
them yet)?

I'm wondering, based upon a suspicion that other models from the OEM
support additional switches, whether one could use a variation of the
GPIO driver to see if any of these lines are connected to the CPU GPIO
pins (suspect this may need to run as a debug boot process before any
RDC configuration occurs that may dedicate the RDC pins to a specific
process).

Regards
Jason

[bifferos]

I just updated the pinouts page. I'm afraid you're out of luck.

cheers,
Biff.

[Nelson Neves]

Hi Biff,

patch now runs OK, but after flashing I don't have the /sys/class/gpio directory!

I've applied this 2 patches under 2.6.30.5:

patch -p1 < ../biffinitrd-0.3/rdc-cpu-detect-2.6.30.4.patch
patch -p1 < ../biffinitrd-0.3/rdc-gpio-2.6.30.5-3.patch

patching file Documentation/x86/rdc.txt
patching file arch/x86/include/asm/processor.h
patching file arch/x86/kernel/cpu/Makefile
patching file arch/x86/kernel/cpu/rdc.c
patching file drivers/gpio/Kconfig
Hunk #2 succeeded at 191 (offset -12 lines).
patching file drivers/gpio/Makefile
patching file drivers/gpio/rdc321x_gpio.c

after booting I only have this directories under /sys/class:

bdi
pci_bus
tty
vtconsole
misc
usb_host
input
net
ieee80211
mem
firmware
vc
usb_endpoint

Any idea what I may be doing wrong ?

Regards,

Nelson.

[Razvan Dragomirescu]

Can you check your .config to see if CONFIG_GPIO_SYSFS is set? That's the option that makes the /sys/class/gpio appear (as far as I can tell).

 

Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

[Nelson Neves]

I was just checking this now! Realised that it was off!

>make kernel_menuconfig

under:
Device Driver->GPIO Support->sys/class/gpio/... (sysfs interface)

I'm just waiting for the compilation, will post results soon!

Thanks Razvan!

[Nelson Neves]

Hurray, it's finally working!

>make menuconfig

activate options under:
-[*] Device Driver->GPIO Support->sys/class/gpio/... (sysfs interface)
-[*] Device Driver->GPIO Support->RDC321X GPIO support

Red Led now goes On and OFF!

Thanks guys, sorry for the dumb questions!

Regards,

Nelson,

[Razvan Dragomirescu]

Hi guys,

I seem to have GPIO working for the output (turning the _red_ LED on and off), but I can't seem to be able to read that d**n reset button. Here's what I do:

echo 15 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio15/direction (this is probably not needed since the pins are set to input as the default anyway)

Every time I do "cat /sys/class/gpio/gpio15/value" it always comes out as "1", regardless of the status of the button (pressed or not pressed). I've also tried to read all the values from gpio1 to gpio15 and all of them are "stuck" to 1, so unless the GPIO for the reset button is >16 there's something wrong with the driver.

Biff, did you check input too? Am I doing anything wrong?

Thanks,

Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

[bifferos]

No, you're not doing anything wrong. I thought I had this working,
but it seems not, because I managed to get the same behaviour as you
with one of my patches. I also managed to have this working another
time, so I'm not quite sure what is going on.

On Sep 2, 6:28 pm, Razvan Dragomirescu <razvan.dragomire...@gmail.com>
wrote:

> Hi guys,
>
> I seem to have GPIO working for the output (turning the _red_ LED on and
> off), but I can't seem to be able to read that d**n reset button. Here's
> what I do:
>
> echo 15 > /sys/class/gpio/export
> echo in > /sys/class/gpio/gpio15/direction (this is probably not needed
> since the pins are set to input as the default anyway)
>
> Every time I do "cat /sys/class/gpio/gpio15/value" it always comes out as
> "1", regardless of the status of the button (pressed or not pressed). I've
> also tried to read all the values from gpio1 to gpio15 and all of them are
> "stuck" to 1, so unless the GPIO for the reset button is >16 there's
> something wrong with the driver.
>
> Biff, did you check input too? Am I doing anything wrong?
>
> Thanks,
> Razvan
>
> --
> Razvan Dragomirescu
> Chief Technology Officer
> Cayenne Graphics SRL
>

> On Wed, Sep 2, 2009 at 1:15 AM, Nelson Neves <nelson.s.ne...@gmail.com>wrote:
>
> > Hurray, it's finally working!
>
> > >make menuconfig
>
> > activate options under:
> > -[*] Device Driver->GPIO Support->sys/class/gpio/... (sysfs interface)
> > -[*] Device Driver->GPIO Support->RDC321X GPIO support
>
> > Red Led now goes On and OFF!
>
> > Thanks guys, sorry for the dumb questions!
>
> > Regards,
>
> > Nelson,
>

> > On Tue, Sep 1, 2009 at 11:02 PM, Nelson Neves <nelson.s.ne...@gmail.com>wrote:
>
> >> I was just checking this now! Realised that it was off!
>
> >> >make kernel_menuconfig
>
> >> under:
> >> Device Driver->GPIO Support->sys/class/gpio/... (sysfs interface)
>
> >> I'm just waiting for the compilation, will post results soon!
>
> >> Thanks Razvan!
>
> >> On Tue, Sep 1, 2009 at 10:59 PM, Razvan Dragomirescu <
> >> razvan.dragomire...@gmail.com> wrote:
>
> >>> Can you check your .config to see if CONFIG_GPIO_SYSFS is set? That's
> >>> the option that makes the /sys/class/gpio appear (as far as I can tell).
>
> >>> Razvan
>
> >>> --
> >>> Razvan Dragomirescu
> >>> Chief Technology Officer
> >>> Cayenne Graphics SRL
>

[Razvan Dragomirescu]

Ok, no problem. I'd be happy to test again if you figure it out. No rush.

 

Cheers,

Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

[Nelson Neves]

I've updated my semi-automated scripts to get OnFlashSystem up and running a bit more easily, sort of a helper for beginners, thought that may be useful to someone in the robotics/electronic hobbyist/etc. Just need to follow the numbers! It's a bit hard-coded, so I advise to run through it just to get the idea. Included Biff's python script to flash the board, hope that you don't mind (I can always remove your scripts and fetch them from SVN if you prefer!). If you are going to flash board from the scripts please change the MAC address from 93-... script.

http://www.botdream.com/bifferboard/onflashsystem/bifferboardflash-2.6.30.5.tar.gz

One can always pick a prepared flash image from the wiki, but this is nice to get your hands and start playing with it! No need to wget later from image, you can prepare it yourself with your extra binaries on it!

Once again, thanks for your help,

Regards,

Nelson.

ps: also have some of this numbered scripts stuff over OpenWrt, if anyone needs it I can share it!

[bifferos]

Sorry it took so long. I fixed a problem, re-tested and now it looks
good.
I have combined all required 2.6.30.5 patches into a single, large
patch. All details are here:

http://sites.google.com/site/bifferboard/Home/s3282-kernel-issues

thanks,
Biff.

On Sep 2, 7:07 pm, Razvan Dragomirescu <razvan.dragomire...@gmail.com>
wrote:

> Ok, no problem. I'd be happy to test again if you figure it out. No rush.
>
> Cheers,
> Razvan
>
> --
> Razvan Dragomirescu
> Chief Technology Officer
> Cayenne Graphics SRL
>

[Nelson Neves]

Hi,

I've replaced my OnFlashSystem scripts for the kernel 2.6.30.5 and biffinitrd-0.3.tar.bz2 to include only the newly updated config and patch files from http://sites.google.com/site/bifferboard/Home/s3282-kernel-issues:
bifferboard-2.6.30.5-3.config
bifferboard-2.6.30.5-3.patch

Patches seem to be correctly applied but when compiling the kernel I get this error:
...
  CC      arch/x86/kernel/cpu/cmpxchg.o
  CC      arch/x86/kernel/cpu/intel.o
make[2]: *** No rule to make target `arch/x86/kernel/cpu/rdc.o', needed by `arch/x86/kernel/cpu/built-in.o'.  Stop.
make[1]: *** [arch/x86/kernel/cpu] Error 2
make: *** [arch/x86/kernel] Error 2

any tip for what may be happening ?

Regards,

Nelson.

[bifferos]

please try bifferboard-2.6.30.5-4.patch.
thanks,
Biff.

On Sep 6, 11:40 pm, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> Hi,
>

> I've replaced my OnFlashSystem scripts for the kernel 2.6.30.5 and
> biffinitrd-0.3.tar.bz2 to include only the newly updated config and patch

> files fromhttp://sites.google.com/site/bifferboard/Home/s3282-kernel-issues

> :
> bifferboard-2.6.30.5-3.config
> bifferboard-2.6.30.5-3.patch
>
> Patches seem to be correctly applied but when compiling the kernel I get
> this error:
> ...
>   CC      arch/x86/kernel/cpu/cmpxchg.o
>   CC      arch/x86/kernel/cpu/intel.o
> make[2]: *** No rule to make target `arch/x86/kernel/cpu/rdc.o', needed by
> `arch/x86/kernel/cpu/built-in.o'.  Stop.
> make[1]: *** [arch/x86/kernel/cpu] Error 2
> make: *** [arch/x86/kernel] Error 2
>
> any tip for what may be happening ?
>
> Regards,
>
> Nelson.
>

[Nelson Neves]

Now it's complaining a bit fruther with this lzma error:

WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
  GEN     .version
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      vmlinux
  SYSMAP  System.map
  OBJCOPY arch/x86/boot/compressed/vmlinux.bin
  LZMA    arch/x86/boot/compressed/vmlinux.bin.lzma
lzma_tukaani: invalid option -- 's'
  LD      arch/x86/boot/compressed/piggy.o
ld: arch/x86/boot/compressed/vmlinux.bin.lzma: No such file: No such file or directory
make[2]: *** [arch/x86/boot/compressed/piggy.o] Error 1
make[1]: *** [arch/x86/boot/compressed/vmlinux] Error 2
make: *** [bzImage] Error 2


I've downloaded tukaani latest version here: http://tukaani.org/lzma/lzma-4.32.7.tar.gz
Extracted and compiled it successfully (didn't make install).
made a symbolic link: sudo ln -s /home/nelson/lzma/lzma-4.32.7/src/lzma/lzma /usr/local/bin/lzma_tukaani

running lzma_tukaani -V will get:
LZMA command line tool 4.32.7
LZMA SDK 4.32

It seems to be the same problem from lzma that I had previously :(
Note: I'm running this from my Vmware Image Linux Ubuntu, but I got this working with my previous scripts!
Will test this tonight wit my live development environment to check if the same applies!

Regards,

Nelson.

[Nelson Neves]

Tested with the very recent patch bifferboard-2.6.30.5-5.patch but will fail in the begin, think is the same problem as previously reported regarding the CPU (was fixed from patch 3 to 4):

  CC      arch/x86/kernel/cpu/intel.o
make[2]: *** No rule to make target `arch/x86/kernel/cpu/rdc.o', needed by `arch/x86/kernel/cpu/built-in.o'.  Stop.
make[1]: *** [arch/x86/kernel/cpu] Error 2
make: *** [arch/x86/kernel] Error 2

Just reporting ;).

Regards,

Nelson.

[bifferos]

I have just installed Slackware 13, and it comes with lzma as follows:
bash-3.1$ lzma --help
Usage: lzma [OPTION]... [FILE]...
Compress or decompress FILEs in the .xz format.

Mandatory arguments to long options are mandatory for short options
too.

-z, --compress force compression
-d, --decompress force decompression
-t, --test test compressed file integrity
-l, --list list information about files
-k, --keep keep (don't delete) input files
-f, --force force overwrite of output file and (de)compress
links
-c, --stdout write to standard output and don't delete input
files
-0 .. -9 compression preset; 0-2 fast compression, 3-5
good
compression, 6-9 excellent compression; default
is 6
-M, --memory=NUM use roughly NUM bytes of memory at maximum; 0
indicates
the default setting, which depends on the
operation mode
and the amount of physical memory (RAM)
-q, --quiet suppress warnings; specify twice to suppress
errors too
-v, --verbose be verbose; specify twice for even more verbose
-h, --help display this short help
-H, --long-help display the long help (lists also the advanced
options)
-V, --version display the version number

With no FILE, or when FILE is -, read standard input.

Report bugs to <lasse....@tukaani.org> (in English or Finnish).


We will therefore standardise on the above version, which requires no
patches to the kernel. This represents a change from previous patches
I've provided, however it means less for me to keep updating.

I've uploaded v6 of the patch, try that.

thanks,
Biff.

On Sep 7, 3:05 pm, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> Tested with the very recent patch

> bifferboard-2.6.30.5-5.patch<http://sites.google.com/site/bifferboard/Home/s3282-kernel-issues/bif...>but

> will fail in the begin, think is the same problem as previously
> reported
> regarding the CPU (was fixed from patch 3 to 4):
>
>   CC      arch/x86/kernel/cpu/intel.o
> make[2]: *** No rule to make target `arch/x86/kernel/cpu/rdc.o', needed by
> `arch/x86/kernel/cpu/built-in.o'.  Stop.
> make[1]: *** [arch/x86/kernel/cpu] Error 2
> make: *** [arch/x86/kernel] Error 2
>
> Just reporting ;).
>
> Regards,
>
> Nelson.
>

> ...
>
> read more »

[Nelson Neves]

PERFECT!!! Now I got my image compiled!

I'm using lzma from Ubuntu Repository:

lzma 4.32.0beta3 Copyright (C) 2006 Ville Koskinen
Based on LZMA SDK 4.43 Copyright (C) 1999-2006 Igor Pavlov

Usage: lzma [flags and input files in any order]
  -c --stdout       output to standard output
  -d --decompress   force decompression
  -z --compress     force compression
  -k --keep         keep (don't delete) input files
  -f --force        force overwrite of output file and compress links
  -t --test         test compressed file integrity
  -S .suf  --suffix .suf   use suffix .suf on compressed files
  -q --quiet        suppress error messages
  -v --verbose      be verbose
  -h --help         print this message
  -L --license      display the license information
  -V --version      display version numbers of LZMA SDK and lzma
  -1 .. -2          fast compression
  -3 .. -9          good to excellent compression. -7 is the default.
     --fast         alias for -1
     --best         alias for -9 (usually *not* what you want)


thanks Biff!

regards,

Nelson.

[bifferos]

On Sep 7, 4:53 pm, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> PERFECT!!! Now I got my image compiled!

<snip>
> thanks Biff!

No problem - nice to have someone test stuff so quickly as it's much
easier to fix stuff while it's still fresh in my mind, rather than
weeks after I've released it!

cheers,
Biff.

[Nelson Neves]

Hi again,

after testing this on my real Linux Ubuntu Desktop at home, it seems OK (at least it compiles OK).
After flashing Bifferboard It won't boot :( ...

from the compilation I get this:
...
Root device is (8, 1)
Setup is 11164 bytes (padded to 11264 bytes).
System is 911 kB
CRC 78566bed
Kernel: arch/x86/boot/bzImage is ready  (#1)


padded ? is the image getting size problems ? I was including netcat asmutils, but then just left it out, but I'm having the same problem!

from the serial console I have this output:

\0x00\0x80\0x00BIFFBOOT: Config block not present, using defaults.

BIFFBOOT v2.0 32-bit Loader by bifferos (c) 2009
Redistribution prohibited, all rights reserved.
Press <ESC>
Link up
Checking NIC
Loaded from flash.


Is the image getting to big ? The only thing that I have changed was the kernel command line, I'm using a BIFFBOOTV2.0, so need this command to boot! (it was working previously with this)
-Processor type and features
 [*] Built-in kernel command line
     (console=uart,io,0x3f8) Built-in kernel command string
     [*] Built-in kernel command line overrides boot loader arguments (new)


I will remove some asmutils and try it again!

Regards,
Nelson.

[Nelson Neves]

Removed asmutils httpd, ftpd and telnetd and got it working!

from compilation:

...
Root device is (8, 1)
Setup is 11164 bytes (padded to 11264 bytes).

System is 909 kB
CRC 11afb162

Kernel: arch/x86/boot/bzImage is ready  (#1)

saved 2Kb from image and was enough!

Regards,
Nelson.

[bifferos]

My example configuration includes all the new functionality I've
added: w1, i2c, MMC over GPIO and even biffconfig, which is demo code
for writing to the configuration area. If you don't need to use this
stuff, remove it from the kernel to get a smaller image, then you
should be able to keep the asmutils.

Also, don't forget to remove maths emulation if you're not going to
use it - the savings are considerable.

cheers,
Biff.

[Nelson Neves]

OK, no problem! For testing this should be fine!

Forgot to mention that I also tested the Button Input and it's working! Didn't had time to actually test the other GPIO inputs, but sure they will be working fine!
Hope to start some I2C tests soon, now that I've got my development environment updated and stable!

Thanks!
Nelson.