OpenWrt Forum Archive

Topic: freecom FSG, endianness problem?

The content of this topic has been archived between 16 Apr 2018 and 5 May 2018. Unfortunately there are posts – most likely complete pages – missing.

jr wrote:

Great! One thing I forgot: use no_phy_scan=1 parameter when loading ixp400_eth.ko.

Why? It doesn't seem to make a difference.

BTW, only two out of four ports work for me, is there some magic to manipulate it?

(Last edited by mangoo on 7 Jul 2006, 14:38)

mangoo wrote:
jr wrote:

use no_phy_scan=1 parameter when loading ixp400_eth.ko.

Why? It doesn't seem to make a difference.

BTW, only two out of four ports work for me, is there some magic to manipulate it?

Well you already answered your own question: If you don't use no_phy_scan parameter only two of four ports work. smile

You can manage individual ethernet ports using "mii-diag" and "-p" parameter with port number. Link was posted to this same forum couple days ago. Regular "mii-tool" will work for WAN port, but not for LAN because it's internally connected to switch.


mangoo wrote:

'm getting these from time to time (in dmesg):
Badness in dma_free_coherent at arch/arm/mm/consistent.c:351

There's one match on google when you search for that error saying it's bug in 2.6.15 kernel. Perhaps it's still present in in 2.6.16.

I also get "scheduling while atomic: ifconfig/0x00000001/930" error when running ifconfig with two ethernet interfaces active. Shutting either one of them down with "ifconfig ethx down" silences it. Might be related to netdevice_notifier and code that checks if MAC addresses are valid each time network device is probed as it does when you run ifconfig.


Status of FSG-3 with non-Freecom kernels:

* Board support: Ok with slightly modified NSLU2 patches (Machine ID, GPIO mapping, PCI INTs)
* IDE: Ok with slightly modified patch from VIA. Both SATA and PATA working.
* USB: Ok with stock 2.6.16 drivers. All ports work.
* Ethernet: Ok with driver from Intel and few patches. MAC address setup fixed based on NSLU2 code.
* I2C: Ok based on NSLU2 sources (GPIO's are 12/SDA and 13/SCL)
* RTC: Ok with single line patch to fix typo on original driver. Driver was posted to LKML couple weeks ago.
* FAN control and sensors: Ok with stock 2.6.16 drivers. lm-sensors report sensible values and I can control fan RPM thru pwm1 (0-255).
* Buttons: Not tested. I have made list of GPIO's and there's code I can copy from NSLU2 patches.
* Mini-PCI: Not tested. WLAN card on Mini-PCI slot detected, but haven't tried with drivers yet.
* LEDs: Not working, connected to IXP4XX_EXP_BUS_CS2. Seems led driver included with kernel doesn't support it yet (only GPIO leds). There's "ledman" from Snapgear for 2.6 that Freecom uses with 2.4 kernel, but I'd rather used standard interface.
* HW Crypto: Not tested. Sources downloadable from Intel, but I don't know if they work in little-endian mode at all.
* Kernel args: Kernel crashes on boot if trying to pass arguments to it.

Buttons shouldn't be a problem, but I'm not capable of writing LED support part. Also finding out why passing arguments to kernel causes crash is beyond my skills. I can try compiling hw crypto support but if it doesn't work as is then there's nothing I can do.

So far everything has been just taking code from here and there, fixing typos, offsets and machine specific mappings based on samples - that's easy part. Rest requires actual knowledge so someone else has to take care of them.

(Last edited by jr on 10 Jul 2006, 07:21)

jr wrote:
mangoo wrote:
jr wrote:

use no_phy_scan=1 parameter when loading ixp400_eth.ko.

Why? It doesn't seem to make a difference.

BTW, only two out of four ports work for me, is there some magic to manipulate it?

Well you already answered your own question: If you don't use no_phy_scan parameter only two of four ports work. smile

You can manage individual ethernet ports using "mii-diag" and "-p" parameter with port number. Link was posted to this same forum couple days ago. Regular "mii-tool" will work for WAN port, but not for LAN because it's internally connected to switch.

Hi,

It seems that everything works fine if I just load the module with "modprobe ixp400_eth", without giving any parameters.

It didn't work before for me because the switch was keeping an old arp cache or something, and all ports began to work after we lost power here smile

jr wrote:

I also get "scheduling while atomic: ifconfig/0x00000001/930" error when running ifconfig with two ethernet interfaces active. Shutting either one of them down with "ifconfig ethx down" silences it. Might be related to netdevice_notifier and code that checks if MAC addresses are valid each time network device is probed as it does when you run ifconfig.

It also happens for other programs during normal activity (here for cups):

scheduling while atomic: cupsd/0x00000002/609

jr wrote:

* Kernel args: Kernel crashes on boot if trying to pass arguments to it.

Buttons shouldn't be a problem, but I'm not capable of writing LED support part. Also finding out why passing arguments to kernel causes crash is beyond my skills. I can try compiling hw crypto support but if it doesn't work as is then there's nothing I can do.

I don't know why kernel crashes, but it's not so problematic - normally, you compile command line arguments in the kernel, and forget about them.

Just update RedBoot config, and modify the startup ("fis load kern2; exec" as the script entered, for the rest, I used defaults):

RedBoot> fconfig
Run script at boot: true
Boot script:
.. fis load kern1
.. exec -c "console=ttyS0,115200 root=/dev/hda1 mem=64M@0x00000000"
Enter script, terminate with empty line
>> fis load kern2
>> exec
>>
Boot script timeout (1000ms resolution): 1
Use BOOTP for network configuration: true
Console baud rate: 115200
DNS server IP address:
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Default network device: npe_eth0
Network hardware address [MAC] for NPE eth0: 0x00:0x01:0xDB:0x00:0x44:0x9E
Network hardware address [MAC] for NPE eth1: 0x00:0x01:0xDB:0x00:0x44:0x9F
Update RedBoot non-volatile configuration - continue (y/n)? y
... Unlock from 0x503c0000-0x503c1000: .
... Erase from 0x503c0000-0x503c1000: .
... Program from 0x03fd2000-0x03fd3000 at 0x503c0000: .
... Lock from 0x503c0000-0x503c1000: .


BTW, you wrote to load the kernel with "fis load -b 0x00020000 kern2".
It loads fine with just "fis load kern2".
Is there a difference?

I don't know why kernel crashes, but it's not so problematic - normally, you compile command line arguments in the kernel, and forget about them.
Just update RedBoot config, and modify the startup ("fis load kern2; exec" as the script entered, for the rest, I used defaults):

Yes that works, but you need serial console or have to mangle RedBoot config partition from OS. There's code on NSLU2 patches to ignore kernel arguments passed from RedBoot that might help with FSG. However, since it works with 2.4 kernel would be nice to get it working with 2.6 too.


BTW, you wrote to load the kernel with "fis load -b 0x00020000 kern2".
It loads fine with just "fis load kern2".
Is there a difference?

I had problems with kernels hanging after Uncompressing text that were solved with that. If it works without great.


It also happens for other programs during normal activity (here for cups):
scheduling while atomic: cupsd/0x00000002/609

Hmm. Well it's not from mac address patch then - assuming you don't have own version of that running. I'll try update patches for NSLU2-Linux version of 2.6.17 at some point to see if it helps.

jr wrote:

BTW, you wrote to load the kernel with "fis load -b 0x00020000 kern2".
It loads fine with just "fis load kern2".
Is there a difference?

I had problems with kernels hanging after Uncompressing text that were solved with that. If it works without great.

I see, after a couple of reboots, randomly I too get kernel panics when I don't use -b 0x00020000.

jr wrote:

I don't know why kernel crashes, but it's not so problematic - normally, you compile command line arguments in the kernel, and forget about them.
Just update RedBoot config, and modify the startup ("fis load kern2; exec" as the script entered, for the rest, I used defaults):

Yes that works, but you need serial console or have to mangle RedBoot config partition from OS. There's code on NSLU2 patches to ignore kernel arguments passed from RedBoot that might help with FSG. However, since it works with 2.4 kernel would be nice to get it working with 2.6 too.

I think it won't work reliably without messing with RedBoot config.

By default, RedBoot loads the kernel and continues after one second.

It looks that it's too fast for the hard drive to get recognized by the kernel, and increasing rootdelay doesn't help - I mean when we poweron the device.

If I ctrl+C in RedBoot, and then wait some time, the drive gets recognized:

ata3: dev 0 ATA-5, max UDMA/100, 40132503 sectors: LBA
ata3: dev 0 configured for UDMA/33
scsi2 : sata_via
  Vendor: ATA       Model: QUANTUM FIREBALL  Rev: A1Y.
  Type:   Direct-Access                      ANSI SCSI revision: 05
ata4: PATA max PIO4 cmd 0xC4852003 ctl 0xC485201D bmdma 0x0 irq 12
scsi3 : ixp4xx
SCSI device sda: 40132503 512-byte hdwr sectors (20548 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back
SCSI device sda: 40132503 512-byte hdwr sectors (20548 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back
sda: sda1 sda2
sd 2:0:0:0: Attached scsi disk sda


If I don't wait, the drive doesn't appear, and I can't access it even when I boot from some other media (usb-stick).

(Last edited by mangoo on 10 Jul 2006, 15:35)

Seen same problem with too fast boot using stock Freecom firmware. Perhaps adding some delay to kernel init prior driver loading would work.

Some more trouble: I noticed the uptime is always above 1 when ixp modules are loaded:

fsg:~# ps aux|grep " D "
root       683  0.0  0.0      0     0 ?        D    01:03   0:00 [IxOsal 1]

Doesn't look healthy at all. Solutions?

Some more info here:

http://www.nabble.com/Big-endian-vs-Lit … 60398.html

The load of a slug at rest is at least 1.00
                               because the ixp400_eth.ko module is badly written
                               and causes a 1.00 load always, although the CPU
                               usage is nil. Zero, nothing, not a single cycle
                               used, but a 1.00 load nonetheless... :-( Go into
                               CSR code to understand that if you can. I resigned.
                               So remove this 1.00 in later calculations.

(Last edited by mangoo on 10 Jul 2006, 16:44)

This issue causes the device to work slower.

If you write a simple script:

#!/bin/bash

i=0

while [ $i -lt 100000 ]

do

i=$((i+1))

done


And run it with the modules loaded, and without them, you will notice over 10% speed difference:

1) ixp400 and ixp400_eth modules unloaded, script executes faster:

fsg:~# time ./script.sh

real    0m54.650s
user    0m52.160s
sys     0m2.480s
fsg:~# time ./script.sh

real    0m54.106s
user    0m52.220s
sys     0m1.880s
fsg:~# time ./script.sh

real    0m53.986s
user    0m52.330s
sys     0m1.650s


2) ixp400 and ixp400_eth modules loaded, script executes over 10% slower:

fsg:~# time ./script.sh

real    1m1.944s
user    0m51.990s
sys     0m9.950s
fsg:~# time ./script.sh

real    1m1.814s
user    0m52.010s
sys     0m9.800s
fsg:~# time ./script.sh

real    1m1.984s
user    0m51.770s
sys     0m10.200s

I just got some hints on linux-arm-kernel mailing list about high system load with ixp400_eth module [1]:


Try adding this lines to modules.conf/modprobe.conf

options ixp425_eth datapath_poll=0
# Note that "datapath_poll=0" will only be usefull if ixp400_eth is compiled w/o NAPI.
# If NAPI support is compiled in, this is ignored.
options ixp400_eth datapath_poll=0 npe_learning=0

Intel Ethernet driver has a couple of working models (polling, interrupt, etc) and in polling mode it uses performance counter's irq to call polling code.. This allows a somewhat "high" performance, at the cost of so many ISRs.. (you can check /proc/interrupts)


[1] See http://lists.arm.linux.org.uk/pipermail … html#35203 - "IXP4XX NPE network driver" thread - although most posts didn't appear yet in the archive

jr wrote:

You can manage individual ethernet ports using "mii-diag" and "-p" parameter with port number. Link was posted to this same forum couple days ago. Regular "mii-tool" will work for WAN port, but not for LAN because it's internally connected to switch.

It seems to me that mii-diag only allow to view the status of the port, and optionally, change its speed (10/100 etc.).

Do you know if it's possible to make vlans on each LAN port here? i.e., I'd like to have two separate networks connected to port 1 and port 2, and I would like to disallow to send packets from one to another.

(Last edited by mangoo on 14 Jul 2006, 10:04)

mangoo wrote:

It seems to me that mii-diag only allow to view the status of the port, and optionally, change its speed (10/100 etc.).

Yes you can view current link status and change speed, duplex, etc. That's exactly what it's supposed to do.

mangoo wrote:

Do you know if it's possible to make vlans on each LAN port here? i.e., I'd like to have two separate networks connected to port 1 and port 2, and I would like to disallow to send packets from one to another.

What you're looking for is tool to configure VLANs on RTL8305SB. As it's configured 3 port LAN switch + 1 port WAN at bootup unless you hack RedBoot to configure it differently there's no much use for such tool. Otherwise those two networks will be bridged together until your userspace tool configures it differently.

If I understood correctly newest firmware from Freecom has option to turn WAN port to 4th LAN port. This is exactly opposite what you're trying to do, but you might want to check how they implemented it. Either switch is reconfigured and secondary ethernet port is disabled or they're bridging both ethernet interfaces together on OS side.

There's tool to configure RTL8305SB/RTL8309SB switch from Linux, but haven't found sources for it. It's included in firmware of some SnapGear VPN devices and Billion BiGuard 2/5/10. Both platforms are bigendian XScales so you might be able to re-use it with FSG in armeb mode. However both binary compatibility and licensing are issues. SnapGear sources are available, but apparently this tool isn't GPL licensed by them. Billion is OpenRG based. Good luck trying to get Billion to release any sources and honor GPL - they just couldn't care less.

I asked Realtek about the software for it, and they sent me some sources:

# ls -l 8305
total 476
-rw-r--r-- 1 root root 329728 Sep  3  2004 Rtl8305SXDriverSpec.doc
-rw-r--r-- 1 root root  13091 Sep  3  2004 rtl8305s.c
-rw-r--r-- 1 root root   1466 Jan  1  1970 rtl8305s.h
-rw-r--r-- 1 root root  17632 Sep  3  2004 rtl8305s_cmd.c
-rw-r--r-- 1 root root    707 Sep  3  2004 rtl8305s_cmd.h
-rw-r--r-- 1 root root   1182 Sep  1  2004 rtl8305sb.c
-rw-r--r-- 1 root root    391 Sep  1  2004 rtl8305sb.h
-rw-r--r-- 1 root root  25448 Sep  3  2004 rtl8305sc.c
-rw-r--r-- 1 root root   2791 Sep  3  2004 rtl8305sc.h
-rw-r--r-- 1 root root  61107 Sep  3  2004 rtl8305sxApi.doc


However, the package is incomplete, everything needs "rtl_types.h" to compile... I asked about that file, but they didn't reply anymore neutral

jr wrote:

* RTC: Ok with single line patch to fix typo on original driver. Driver was posted to LKML couple weeks ago.

Umm, I can't find it anywhere on lkml, at least not in June/July, when looking for "rtc typo" or "rtc patch"?

Or, is that it: http://marc.theaimsgroup.com/?l=linux-k … 46&w=2

Doesn't look like a one-liner smile

(Last edited by mangoo on 17 Jul 2006, 14:07)

That's the old version requiring one line patch: regs[ISL1208_REG_YR] = BIN2BCD(tm->tm_wday & 7);
-> regs[ISL1208_REG_DW] = BIN2BCD(tm->tm_wday & 7);

There's new version that fixes typo and has some other changes as well. I haven't tried it, but at least old version works after above change.

http://marc.theaimsgroup.com/?l=git-com … 4318903767

Hmm, I patched the file from the first link with the patch from Andrew Morton.
But I see your link is from two days ago.

Anyway, how did you get this to work? I can only build this as a module, so it can't be inserted before the rootfs mounts.
And I get when kernel loads/executes (before mounting rootfs):

drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

and 1970-year date as a result.

mangoo wrote:

Anyway, how did you get this to work? I can only build this as a module, so it can't be inserted before the rootfs mounts.

You added I2C GPIO configuration, enabled IXP4XX I2C support and rest of I2C stuff? After that it'll work just fine. You can compile it as part of kernel too if I2C is built-in instead of modules. Same goes for sensors and fan control - after I2C functions kernel driver for that winbond chip works ok.

jr wrote:
mangoo wrote:

Anyway, how did you get this to work? I can only build this as a module, so it can't be inserted before the rootfs mounts.

You added I2C GPIO configuration, enabled IXP4XX I2C support and rest of I2C stuff? After that it'll work just fine. You can compile it as part of kernel too if I2C is built-in instead of modules. Same goes for sensors and fan control - after I2C functions kernel driver for that winbond chip works ok.

For some reason, it just doesn't work for me.

I tried the first patch, the second patch, in the kernel, as a module, and still nothing.


During bootup, kernel logs:

drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

If I want to use hwclock manually, it doesn't work either:

# hwclock --debug
hwclock from util-linux-2.12r
hwclock: Open of /dev/rtc failed, errno=19: No such device.
No usable clock interface found.
Cannot access the Hardware Clock via any known method.


The node is there:

# ls -l /dev/rtc
crw-r--r-- 1 root root 10, 135 Jul 19 13:28 /dev/rtc

Could you post your .config file for the kernel?

Sounds like you only have patches I uploaded my site some time ago. Those don't contain I2C parts nor reading ethernet mac from flash. You can copy+paste them from any IXP4XX platform and just change GPIOs + flash offsets. I published necessary GPIOs somewhere. Wiki, this forum, OpenFSG or something can't remember. As I wrote on email I sent to you about week ago I'm leaving for vacation (4 weeks) and don't have time to play with FSG nor WL700 at the moment.

Other than short "GPIO's known" on http://wiki.openwrt.org/FreecomFSG3, I can't find anything else anywhere in the internet.

Anyway, happy holiday smile

jr: I'm considering whether buy FSG-3 or WL700gE. I don't mind some extra work on porting to armeb arch
and I like bigger flash and both serial and parallel ATA in FSG.
I googled some measured speed of WL700gE: http://wl700g.info/showthread.php?t=5650
but google did not find anything similar for FSG-3.
Can you please give some comparison of network file serving speeds? Is there a noticeable difference between arm
and mips?

What's the status of the FSG-3 support? I can't get the patches (from http://80.81.183.101/fsg3/le-debian/, gives 404).

I'd like to get 2.6 running, preferrably with the new open source IXP network driver we're trying out on the NSLU2 (and  other ixp4xx devices).

With some work, you can run FSG-3 using NSLU2 buildroot.

The discussion might have continued from here.