Hi Waylon, glad I could help! superelchiby superelchi - Displays
@ravishankarrs bad news. Your dpf is not supported by dpf-ax. The dpf needs to be based on the Buildwin SDK for AX206. Yours is based an the SDK for AX208 (even if it's an AX206): $ hexdump -n 128 -C fulldump_20150903-182531.bin 00000000 00 00 42 4c 20 76 32 2e 30 38 15 55 aa 00 00 00 |..BL v2.08.U....| 00000010 1d 7d 00 01 00 00 00 80 40 00 18 20 00 00 00 00 |.}......@.. ...by superelchi - Displays
Hi waylon, good news. I'm getting: $ ./identify.py fulldump_win_20150903-000212.bin Looking for firmware.............: Found (buildwin, 128x128 px). Looking for Openwin..............: Found. Looking for LcdIniTbl............: Found. Looking for backlight & contrast.: Found, Found. Looking for known signatures.....: Found. Your dpf is compatible with model ['dx27893by superelchi - Displays
Hi waylon, as identify.py said: "This in no known firmware!". Your dpf is not an AX206 or it's firmware is not based on the Buildwin SDK for this chip. And dpf-ax only works with AX206 chips based on the Buildwin SDK. Sorry, nothing I can do. But if you can upload the firmware somewhere I will have a look. Just to be sure... superelchiby superelchi - Displays
KritixChoyce Wrote: ------------------------------------------------------- > Ok, I couldn't wait that long. I tried it and it > worked!!! You are welcome. :) Can you tell me what worked? Reflashing the original fw or one from dpf-ax? superelchiby superelchi - Displays
Wow! A (new) 240x320 ax206! Haven't seen one for quite a while. :) I know gettin started is hard - but you are almost there. Looks like your flash chip is not supported by ProgSPI.exe. Please try the FlashLib.ini from here. Should work. Can you upload your original fw? I will have a look.... superelchiby superelchi - Displays
bodhi Wrote: ------------------------------------------------------- > Nice script! I agree it would be ideal to make it > run like you've coded (# Default-Start: S). But > you could also solve this in slightly different > approach: If you execute it as a normal script > (not run level) in /etc/default/rcS it will be > early enough in the boot process to bring up theby superelchi - Debian
@bodhi FYI: UART booting the stock u-boot works here also. But - as expected - still no link. I've tried to execute the phy init script during the boot process. But no luck so far. Works after boot (executed in rc.local) but not during boot. Here is my script: #!/bin/sh -x ### BEGIN INIT INFO # Provides: nsa310s-phyup ### Required-Start: $local_fs $network # Requiredby superelchi - Debian
Not working. :( Same as before. Link is not comming up. root@debian:~# ethtool eth0 Settings for eth0: Supported ports: [ TP AUI BNC MII FIBRE ] Supported link modes: Not reported Supported pause frame use: No Supports auto-negotiation: No Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotby superelchi - Debian
osa Wrote: ------------------------------------------------------- > Hi! > 22 = 0x16 so try > > phypoke 1 16 3 > > > I have tried on my box > > phypoke 1 16 3 > phypoke 1 16 0 > > My network works after restart ( patch hacks regs > earier so it works "at boot") > > I have posted this patch for nsa325 but get no > responby superelchi - Debian
Yeah, noticed this also. There is more: mvEthPhyRegWrite(mvBoardPhyAddrGet(ethPortNum),22 ,0x0); mvEthPhyRegWrite(mvBoardPhyAddrGet(ethPortNum),18,0x80); /* Page 0 Register 18 = 0x80 */ mvEthPhyRegRead(mvBoardPhyAddrGet(ethPortNum), 18, &phy_reg); mvEthPhyRegRead(mvBoardPhyAddrGet(ethPortNum), 13, &phy_reg); printk(KERN_ERR"reg(0, 18) = 0x%x\n", phy_reg);by superelchi - Debian
This is what I get on shutting down the stock OS: / # /sbin/halt save exit: isCheckpointed 1 led_state_map_addr = 4e Jan 1 00:02:10 NSA310S linuxrc: starting pid 2603, tty '': '/etc/init.d/rc.shutdown' / # Starting "/etc/init.d/zypkg_controller.sh". Stopping all zypkgs via "/etc/init.d/zypkg_controller.sh" ... - shutdowning package "NFS"by superelchi - Debian
Sorry. No luck at all. Called it with: $ kwboottool/kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.2014.07-tld-3.nsa310.uart.kwb Stops after sending the image: . . 92 % [......................................................................] 94 % [......................................................................] 96 % [..............................................................by superelchi - Debian
bodhi Wrote: ------------------------------------------------------- > @superelchi, > > > Can we persuade the driver somehow to tell us > > which chip it detected? > > I looked at Marvell latest driver in Linux 4.1. > Looks like it does not have the exact 88e1318 in > the list of chips that needs special care (using > reg-init). We'll have to useby superelchi - Debian
bodhi Wrote: ------------------------------------------------------- > Now since it's working with the work around. I'd > suggest the next step is to look at the DTS. > > In the DTS, these register values were specified > already in eth PHY. What would be the difference > that caused Debian to ignore these values? Good that I hadn't seen this DTS beforby superelchi - Debian
Success! What I have done: Copied /sbin/phypoke from ZyXel OS to Debin /sbin. Created nsa310s-init.sh #!/bin/sh ## for LED settings /sbin/phypoke 1 16 3 /sbin/phypoke 1 10 1017 /sbin/phypoke 1 11 4408 #The MCU set the phy to 10-Mb mode as low-power status. #We have to set it back when booting up. /sbin/phypoke 1 16 0 /sbin/phypoke 1 4 1e1 /sbin/phypoke 1 9 300 ## Downshiby superelchi - Debian
I agree that we may have a differnet hardware version. I'm currently also looking into the GPL sources. What I found so far (maybe totally useless/wrong - doing this for the first time): The "NSA-310S" is internally names "STG315" and I assume it's mapped to a #define "CONFIG_MitraStar_STG315" (didn't find out where this is done so far). As yby superelchi - Debian
Not working here. I put a call to the script in rc.local and it's executed at startup: root@debian:~# ls /sys/class/gpio/ . .. export gpio47 gpio49 gpiochip0 gpiochip32 unexport root@debian:~# cat /sys/class/gpio/gpio47/direction out root@debian:~# cat /sys/class/gpio/gpio47/value 1 root@debian:~# cat /sys/class/gpio/gpio49/direction out root@debian:~# cat /sys/clasby superelchi - Debian
pengu Wrote: ------------------------------------------------------- > when booting into debian .. the green LED is still > on .. after a while it goes of and the amber LED > turns on. > now the lan connection is back on 1000 baseT-FD > and fully working. Yeah. That's the difference. Somehow your phy is correctly initialized on boot and ours are not... @JohnnyUSA:by superelchi - Debian
I don't think it's the switch. I have a manageable HP ProCurve switch, JohnnyUSA something completely different. Never had problems with mine and both connect just fine when booting to Zyxel OS. Can you have a look at the LEDs on your LAN port? After coldboot I have the GREEN LED blinking and after the first successful connect (in Zyxel OS) it changes to the AMBER LED. If I do a coldby superelchi - Debian
Fits my findings. Same behavior. Only difference:Quotepengu now booting debian ... still 10bseT-HD .. while the driver is loaded this changes to 1000 baseT-FD that's not happening here - link stays at 10HDX. Argh!by superelchi - Debian
No, I did "poweroff". Thought that's the same in this case (I kown there are subtle differences). Here is the log for "shutdown -h now" with "NETDOWN=no" and logging enabled shutdown -h now Broadcast message from root@debian (ttyS0) (Fri Jul 17 07:15:20 2015): The system is going down for system halt NOW! INIT: Switching to run IN[[36by superelchi - Debian
#! /bin/sh -x ### BEGIN INIT INFO # Provides: halt # Required-Start: # Required-Stop: # Default-Start: # Default-Stop: 0 # Short-Description: Execute the halt command. # Description: ### END INIT INFO NETDOWN=no No change. After poweroff link changes to 10HDX and is not coming up on next boot. Besides - wouldn't be of any use on coldboot...by superelchi - Debian
bodhi Wrote: ------------------------------------------------------- > All, > > How about doing this test. We should compare the > Debian shutdown sequence between the box that > worked (pengu's) and the boxes that did not work > (superlechi's, Johnny's). > Debian poweroff: poweroff Broadcast message from root@debian (ttyS0) (Fri Jul 17 02:5by superelchi - Debian
bodhi Wrote: ------------------------------------------------------- > All, > > How about doing this test. We should compare the > shutdown sequence between the box that worked > (pengu's) and the boxes that did not work > (superlechi's, Johnny's). Just to be sure I understand you correctly: shutdown sequence of Debian or Zyxel OS?by superelchi - Debian
I can confirm JohnnyUSA's findings: no link with new DTB. Switch still says "Link Up, 10HDX". Here is my Zyxel OS boot & schutdown log. EDIT: Just got a download link for the NSA301S GPL sources. Veeeeery slow ftp connection - will take around 12 hours. :Oby superelchi - Debian
Fresh from the WebIF: Modellname: NSA310S Firmware-Version: V4.70(AALH.0)by superelchi - Debian
I had a closer look at the ZyXel OS boot log and found this: Boot from RAM disk [033mMount system disk image ...[0m yaffs: dev is 32505860 name is "mtdblock4" yaffs: passed flags "" yaffs: Attempting MTD mount on 31.4, "mtdblock4" yaffs: restored from checkpoint yaffs_read_super: isCheckpointed 1 /etc/zyxel/conf exist.. /etc/init.d/rcS: line 406: canby superelchi - Debian
Okay, send an request for the GPL sources to ZyXel GPL-OSS Software Notice Thank you for sending a message to ZyXEL; this is an automated response to acknowledge that we received your email. Your message will be forwarded to the appropriate department and should be answered within the next 2 business days. Due to some email spam blockers, please be sure to check your junk or spam email sby superelchi - Debian
bodhi Wrote: ------------------------------------------------------- > That's why I've suggested to use static IP only, > so to eliminate any other misleading errors! You are absolutely right. One less thing to worry about. Changed to static IP - same as before. No link. That's what I expected because I can see in the WebIF of my switch that the link is not correctlyby superelchi - Debian