stripped toolchain won't compile

Hi,

on http://www.student.kuleuven.ac.be/~s0169612/isl3893.html is Ruben 
Faelens' description on how to compile the firmware for the Medion MD40900.

Unfortunately the stripped toolchain 
http://isl3893.sourceforge.net/download/toolchain/isl3893-stripped-toolchain.tgz 
won't compile on SuSE 10.0.

I already tried downgrading gcc, gcc-c++, cpp, flex and bison to the 
version included in SuSE 9.3.
I do remember that I was able to compile it on an earlier version of 
SuSE, but I do not remember which one, possibly 9.1 oder 9.2.

make-tools.sh end with this message:
In file included from ../../gcc-2.95.3/gcc/c-lex.c:31:
../../gcc-2.95.3/gcc/c-parse.h:54: error: conflicting types for `RETURN'
../../gcc-2.95.3/gcc/rtl.def:503: error: previous declaration of `RETURN'
make[1]: *** [c-lex.o] Fehler 1
make[1]: Leaving directory `/mnt/sda6/tools/build-gcc/gcc'
make: *** [all-gcc] Fehler 2

Any ideas on how to solve this?

Or: could someone post/upload a precompiled toolchain for SuSE ?

Stefan

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language

Re: stripped toolchain won't compile

Hi again,

I would like to rephrase my question.

Apparently compiling the toolchain is highly dependent on which linux 
and which version you use.

So, the those people who have successfully compiled the toolchain: which 
linux and which version did you use? Please let us know the versions of 
gcc, flex and bison too.

And can you compile the toolchain "from scratch"? Meaning: can you 
unpack the sources in /tmp, run make-tools.sh and enter /tmp as the 
installation-directory. That will cause no disturbance to your existing 
installation and will take only a few minutes. If that works, please 
tell the list. Up to now anyone trying to start building firmwares will 
spend hours just finding the correct configuration.

Thanks, Stefan

stn21 schrieb:

> Hi,
>
> on http://www.student.kuleuven.ac.be/~s0169612/isl3893.html is Ruben 
> Faelens' description on how to compile the firmware for the Medion 
> MD40900.
>
> Unfortunately the stripped toolchain 
> http://isl3893.sourceforge.net/download/toolchain/isl3893-stripped-toolchain.tgz 

Re: stripped toolchain won't compile

Hi yet once more 

Debian does not seem to work either, so far I also tried Knoppix 3.9 and 
Knoppix 3.1. Same results as with Suse.

Stefan

stn21 schrieb:

> Hi,
>
> on http://www.student.kuleuven.ac.be/~s0169612/isl3893.html is Ruben 
> Faelens' description on how to compile the firmware for the Medion 
> MD40900.
>
> Unfortunately the stripped toolchain 
> http://isl3893.sourceforge.net/download/toolchain/isl3893-stripped-toolchain.tgz 
> won't compile on SuSE 10.0.
>
> I already tried downgrading gcc, gcc-c++, cpp, flex and bison to the 
> version included in SuSE 9.3.
> I do remember that I was able to compile it on an earlier version of 
> SuSE, but I do not remember which one, possibly 9.1 oder 9.2.
>
> make-tools.sh end with this message:
> In file included from ../../gcc-2.95.3/gcc/c-lex.c:31:
> ../../gcc-2.95.3/gcc/c-parse.h:54: error: conflicting types for `RETURN'
> ../../gcc-2.95.3/gcc/rtl.def:503: error: previous declaration of `RETURN'
> make[1]: *** [c-lex.o] Fehler 1
> make[1]: Leaving directory `/mnt/sda6/tools/build-gcc/gcc'

Re: stripped toolchain won't compile

Hello Stefan,
I remember having built the toolchain on Debian unstable a year ago.
But I also remember having had to fix the embedded assembler parts in
the toolchain, because my compiler was a bit anal about multiline
assembler
(you had to add \ to the end of each line, basically)
Which compiler version did you use for building? I can imagine the
toolchain builds only okay with gcc 2.95.3, too.

You could also try a toolchain from a different source (make sure to get
genromfs anyway!) - you try to get the same version numbers.

I think I ran a diff on the provided toolchain once, and it was an
unmodified upstream toolchain. However I think I failed in using a gcc
3.x for building a isl3893 firmware two years ago... man I've really
forgotten everything since.

best regards,
Erich Schubert
--

-- 
    erich <at> (vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
   To understand recursion you first need to understand recursion.   //\
        Es gibt kein idiotensicheres Programm, weil Idioten so       V_/_
                      genial sind. -- E. Murphy

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: stripped toolchain won't compile

Hi,
> In file included from ../../gcc-2.95.3/gcc/c-lex.c:31:
> ../../gcc-2.95.3/gcc/c-parse.h:54: error: conflicting types for `RETURN'
> ../../gcc-2.95.3/gcc/rtl.def:503: error: previous declaration of `RETURN'

Try flex-old on Debian. I think the c-parse.h and c-lex.c files are
generated via bison/flex. The reason Debian still has flex-old and
bison-1.35 packages
likely is that some of the older applications (e.g. gcc 2.95.3) still
need it.

In fact:
> apt-cache showsrc gcc-2.95 | grep Build
Build-Depends: cpp-2.95, dejagnu (>= 1.4), bzip2, binutils (>=
2.11.90.0.1-1), debhelper (>= 3.0.25), gperf (>= 2.7-3), autoconf2.13,
bison-1.35, flex-old, gettext, texinfo, libgc-dev [!avr !hppa !
hurd-i386], awk, libncurses-dev, libgmp3-dev, help2man, dpkg-dev (>=
1.13.9)

you really seem to need bison-1.35 and flex-old for it.

best regards,
Erich Schubert
--

-- 
   erich <at> (vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
    Go away or i'll replace you with a very small shell script.     //\
    Der Anfang aller Erkenntnis ist das Staunen. --- Aristoteles    V_/_

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language

Re: stripped toolchain won't compile

Hi,
So I just remembered that I had some free diskspace on a box, booted it
up and tried to build the toolchain. Here are the steps I followed (I
didn't completely build the toolchain, sorry, don't have that much
time... but I'd really like to help you... this is probably as much as I
could do now.)

1. Install build-essentials and the usual stuff
  You'll need at least "build-essential zlib1g-dev flex-old bison-1.35"
2. install "stow" for nice /usr/local installations
3. unpack the stripped toolchain
4. make everything writeable (chmod -R u+w *)
5. remove the jffs block from the make script, since this was stripped
from
the toolchain (no license files included, and not used)
6. edit gcc-2.95.3/gcc/config/arm/arm.c and change line 531 to read
  arm_prgmode = TARGET_APCS_... instead of arm_prog_mode
7. change make-tools.sh to use "make BISON=/usr/bin/bison-1.35" for
making
  gcc in line 121 (but you can just add this too make commands)
8. run make-tools.sh and pick install dir
"/usr/local/stow/arm-toolchain"
9. use stow to link them from /usr/local (this makes uninstallation much
easier)

I can't rememeber doing step #6, and I havn't tested the resulting
toolchain. But at least it compiles then. I didn't bother to further
track down the problem... that line expands via a macro to the following
cast:
((enum attr_prog_mode) arm_prgmode)

Compiled the toolchain

Hi.

many thanks to the people who answered on my compile-toolchain problem.

Special thanks to Arco, Erich and Ulf for valuable hints on how to patch+build the sources.

I am happy to report that the toolchain now compiles on my Suse 10.0 with gcc downgraded to 3.3.1-29 (as in suse 9.0), flex downgraded to 2.5.4a-199 (as in suse 9.0) and bison downgraded to 1.875-51 (as in suse 9.1).

I then re-upgraded all packages (and cpp+gcc-c++) to their suse-10-defaults gcc 4.0.2, flex 2.5.4a-297, bison 1.875-56, and compiled the toolchain again. This time it did NOT work, compiler-error again, so apparently downgrading gcc does help.

Erich hinted that maybe the whole thing only compiles flawlessly with gcc 2.95. I could not check that because I could not find a Suse old enough But I think, he may be correct.

Erich also hinted to
1) make all file writeable (chmod -R a+w * in tools/).
2) edit gcc-2.95.3/gcc/config/arm/arm.c and change line 531 to read
 arm_prgmode = TARGET_APCS_... instead of arm_prog_mode

I did these two things and recompiled (from scratch) with the suse 10.0 standard-versions of gcc/flex/bison into  installdir=/tmp/uclinux_tools_1.6.0.0, test only. Compiling worked.

One remark from me: When I change the configuration of my Linux, like compiler-versions etc, I always (and quite often :-/) restart compiling the toolchain from scratch, deleting tools/ and unpacking the achive again. The build-process does quite a lot before actually compiling, like rebuilding sources with flex/bison. So only by complete recompiling can I be sure that the new config works.


Unfortunately I also have to say that compiling worked, but uploading to the AP in all cases did not.
The sources for the AP-600 completely "bricked" the AP, the usual "firmware exceeds flash size". I could recover it with the instructions on Ruben Faelens site http://www.student.kuleuven.ac.be/~s0169612/isl3893.html using the minimal-image (http://isl3893.sourceforge.net/download/firmware/siemens-wlanap600rp/apfw.minimal.img).

Thanks to Ruben and to the list-member who created the minimal-image. I don't remember who that was, sorry

Then I had some fun bricking and unbricking the AP with some other firmwares.
Unbricking usually worked using safe-mode (IP 192.0.2.93)

So I compiled the AP600-sources (see above), the sources for the wet54gs5 (as suggested on Ruben's page) and the sources for the wet54gv2 (as suggested on http://www.seattlewireless.net/index.cgi/ISL3893) Both wet-sources simply caused the AP to hang/reboot every 1 minute. No harm done simple tftp of another FW-image and the AP was up again.

Also I downloaded the firmware + sources of the sitecom WL-122-v1. The original firmware-image works on my AP, but compiling the sources was rather difficult, lots of missing softlinks, no apps-nongpl. Finally I found a way to compile the image. But again: uploading just bricks the AP, new "firmware exceeds flash size" and so on.

But at least one piece of good news: there is a standard firmware-image with telnet enabled. It is for the ZCOM XG-2000 (identical to the AP600 and the MD40900, of course) and can be found on http://www.178mobile.com/download.htm , seek XG-2000. There are two version there, both work fine. Also there is a webfilesset, in case you get "invalid web-filesystem". There is also a link to the GPL-sources, but that leads to nirvana.com, so apparently nobody has recently taken ZCOM to court for GPL-violations.

BTW: The sitecom WL-122-v1-firmware is very similar to the XG-2000-FW, telnet enabled too.

Telnet is nice for playing around with the webserver boa. It can easily be reconfigured to download any file from the AP. I was hoping to use it to upload files. That would help testing new applications (like olsrd http://olsr.org).

Also I tried to understand the mechanism by which the web-interface set the radio. No luck here.

I am hoping to find a way to get the AP into Adhoc-mode. Reason: I would like to use it as a "Freifunk"-node (www.freifunk.net), which is a network for public and free internet-access in a few german cities. Berlin is the big leader concerning Freifunk, and in my hometown we are just starting. That also is what the routing-protocol olsr is for.

Stefan

Re: Compiled the toolchain

Hello Stefan,

On So, Mär 12, 2006 at 08:55:30 +0100, stn21 wrote:
> [...]
> Telnet is nice for playing around with the webserver boa. It can easily 
> be reconfigured to download any file from the AP. I was hoping to use it 
> to upload files. That would help testing new applications (like olsrd 
> http://olsr.org).

searching the list archive at

  http://sourceforge.net/mailarchive/forum.php?forum=isl3893-devel

for "olsr" reveals this interesting posting from Ulf.

  http://sourceforge.net/mailarchive/message.php?msg_id=12469159

And searching for "mount nfs" gives this example.

  http://sourceforge.net/mailarchive/message.php?msg_id=12978530

Personally I had problems with nfs, I used a ruby script to upload an
arm-netcat for further file transfers. You can find the script in this
posting.

  http://sourceforge.net/mailarchive/message.php?msg_id=14803095

> Also I tried to understand the mechanism by which the web-interface set 
> the radio. No luck here.

Initial setting is done during interface enumeration from what is
called the PDA (Production Data Area). Have a look into islmvc_dev.c
to see whats going on during boot. Wireless interface is always set to
MODE_AP, there is no code in the original driver to set any other
mode.

Later settings are done via setoid library calls. There is also a
command line tool to do some settings by hand. But you cannot change
the operation mode this way.

You may want to look into the wireless patch to understand how to
set up MODE_CLIENT.

  http://isl3893.sourceforge.net/download/patches/isl3893_wireless_ext_2.diff.tgz

Johannes
--

-- 
Not using mail encoding is like always writing on postcards.
Key ID = 1024D/8014B0E9
Key fingerprint = 71FB 4193 DFC5 9827 7D06  B9F4 A6C2 D414 8014 B0E9

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642

Re: Compiled the toolchain

Hello,

Benjamin, this could be the occasion to have someone interested in
bridging the projects, so i'm hopping in !

> I am hoping to find a way to get the AP into Adhoc-mode. Reason: I
> would like to use it as a "Freifunk"-node (www.freifunk.net), which is
> a network for public and free internet-access in a few german cities.
> Berlin is the big leader concerning Freifunk, and in my hometown we
> are just starting. That also is what the routing-protocol olsr is
> for. 

I don't really know the internal hardware architecture, but from what I
gather, you have two arm processors, one which executes linux, the
other, PCI-connected, which is dedicated to wifi. Am I right ?

About the wifi driver in ad-hoc mode:

0/ you can try to have the conexant-provided driver work;

1/ the chips in there may be "fullmac" and able to run the standard
prism54 driver, which is in the current kernel. You can have a go at
porting it to 2.4 -- after checking that your chip is, indeed, fullmac
compatible. I know a hack to check this if your interested. Basically,
it uses this information:

http://jbnote.free.fr/islsm/doku.php?id=documentation:isl38xx_hardware

You can use the direct memory window to write to ram and find the
address at which the memory wraps.

2/ you can also port to 2.4 the 'softmac' driver, which works with all
revisions of the wifi arm chip:

http://jbnote.free.fr/prism54usb

(it has a PCI version, which needs a bit of love, though). If you're
interested in this, then let's talk a bit more about it, because there
are some modifications that you need to be aware of so that it goes
smoothly (PDA readback, at first sight, won't be done in the same way).

3/ If you're interested in very low-level wifi tinkering, we're also
currently trying to rewrite a 100% free firmware (the code that runs on
the second arm processor) at 

http://svnweb.tuxfamily.org/listing.php?repname=freemac+%28prism54%
29&path=%2F&sc=0

None of these are obvious solutions, though...

JB

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Compiled the toolchain

Hi folks,
A couple of notes:
- "firmware exceeds flash size". Make sure you got the partition sizes
in _your_ firmware setup correctly, too. Check out uClinux/.config
The AP600 partition sizes I have here are:
CONFIG_ROCKHOPPER_APFW_START_ADDR=10000
CONFIG_ROCKHOPPER_APFW_START_ADDR=10000
CONFIG_ROCKHOPPER_APFW_END_ADDR=360000
CONFIG_ROCKHOPPER_JFFS_START_ADDR=360000
CONFIG_ROCKHOPPER_JFFS_START_ADDR=360000
CONFIG_ROCKHOPPER_JFFS_END_ADDR=400000
CONFIG_ROCKHOPPER_MAX_WFS_SIZE=500000
CONFIG_ROCKHOPPER_MAX_UAP_SIZE=131072
I think they were too small in the AP600 source package, especially if
you enable all the stuff you might find interesting... keep it small.
- afaik it's a single ARM processor running both the MAC (which is of a
fullmac type) and Linux. There was a new firmware with a SoftMAC
architecture, but the last time I had contact with Conexant it was still
in beta. Given that the isl3893 isn't their latest product, and the ARM7
platform is quite popular, we could ask them to get the GPL version of
the new firmware. I think the seriously could benefit from some OSS
development on their platform...
- I'd setup a system with the conexant MAC first before spending too
much time with trying to get the pcmcia and USB code working... first
make sure the problem is not at a different layer, you can always try to
replace the MAC later when you are confident of having the other stuff
right. Sorry, Jean-Baptsite.
I'd really appreciate a FreeMAC for the isl3893, too, but getting the
rest working right is probably difficult enough for now. 
- nfs worked fine for me two years ago... if I recall correctly, I first
determined the correct ports (which usually are assigned dynamicly!) via
"rpcinfo -q" or so on the nfs server itself. This is needed because we
don't have portmap on the isl3893. Then you need to give both (nfs and
mount!) as mount parameters (port=xyz,mountport=xyz) on the client
IIRC. 
According to my docs, I used the commandline
mount -t nfs -o nolock,port=$2,mountport=$3 $1:/home/nfs /tmp/nfs
on the isl3893, with $1 the IP, $2 the nfs port and $3 the mount port.
- the wireless extensions patch is useful, so grab it. you still need to
build the wireless tools, though, and the patch is incomplete. Not all
iwconfig commands are supported, but the basic ones like essid and
channel work IIRC.
I don't know if there is a newer version of that patch available.

best regards,
Erich Schubert
--

-- 
    erich <at> (vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
  A polar bear is a rectangular bear after a coordinate transform.   //\
   Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln.   V_/_

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642