If I boot in "failsafe" mode as suggested by @mk24 , then I get :
Host is up (0.000062s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
21/tcp open ftp
3306/tcp open mysql
Connecting on FTP gives :
ftp> rstatus
211-FTP server status:
Connected to 192.168.0.141
Logged in as ftp
TYPE: BINARY
No session bandwidth limit
Session timeout in seconds is 300
Control connection is plain text
Data connections will be plain text
At session startup, client count was 1
vsFTPd 3.0.3 - secure, fast, stable
211 End of status
Somehow, when I boot it connected to the wan port, the device replies on HTTP port, exactly on the "PRE INIT" IP address I configured in my compilation, then send BOOTP/DHCP messages
So, somehow, my built is starting (at least in preinit state, then fails)
11:40:50.836136 ARP, Reply 192.168.1.49 is-at 44:d1:fa:68:e5:be (oui Unknown), length 48
11:40:50.836183 IP gjlaptop.56846 > 192.168.1.49.http: Flags [S], seq 436947348, win 65535, options [mss 1460,sackOK,TS val 443801040 ecr 0,nop,wscale 9], length 0
11:40:50.836219 IP gjlaptop.56844 > 192.168.1.49.http: Flags [S], seq 1511438825, win 65535, options [mss 1460,sackOK,TS val 443801040 ecr 0,nop,wscale 9], length 0
11:40:50.836231 IP gjlaptop.56848 > 192.168.1.49.http: Flags [S], seq 2506509040, win 65535, options [mss 1460,sackOK,TS val 443801280 ecr 0,nop,wscale 9], length 0
11:40:50.836515 IP 192.168.1.49.http > gjlaptop.56846: Flags [R.], seq 0, ack 436947349, win 0, length 0
11:40:50.836517 IP 192.168.1.49.http > gjlaptop.56844: Flags [R.], seq 0, ack 1511438826, win 0, length 0
11:40:50.836518 IP 192.168.1.49.http > gjlaptop.56848: Flags [R.], seq 0, ack 2506509041, win 0, length 0
ANy clue how to get the error messages from the PRE INIT state on a console ?
For the BOOTP part, I have:
11:55:21.735459 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 44:d1:fa:68:e5:be (oui Unknown), length 300
but my DHCP server seems not sending anything to the client
always-broadcast on;
allow bootp;
option domain-name-servers 8.8.8.8, 8.8.4.4;
option subnet-mask 255.255.0.0;
option routers 192.168.1.1;
subnet 192.168.0.0 netmask 255.255.0.0 {
range dynamic-bootp 192.168.0.25 192.168.0.55;
}
Would have to know the partition scheme of the Yuncore to see if it is the same and thus if that firmware could possibly work.
By interact with the bootloader I mean over serial. Development of a new device is always going to need serial both to see what is going on and to try corrections.
The partition is already known :
[ 0.720000] Creating 6 MTD partitions on "spi0.0":
[ 0.720000] 0x000000000000-0x000000040000 : "u-boot"
[ 0.730000] 0x000000040000-0x000000050000 : "u-boot-env"
[ 0.740000] 0x000000050000-0x000000e80000 : "rootfs"
[ 0.740000] mtd: partition "rootfs" set to be root filesystem
[ 0.750000] mtd: partition "rootfs_data" created automatically, ofs=920000, len=560000
[ 0.760000] 0x000000920000-0x000000e80000 : "rootfs_data"
[ 0.760000] 0x000000e80000-0x000000ff0000 : "kernel"
[ 0.770000] 0x000000ff0000-0x000001000000 : "art"
[ 0.780000] 0x000000050000-0x000000ff0000 : "firmware"
I managed to open the box and here the platform. How to figure out where to connect my serial-to-usb device ?
I would guess (and you'll need at least a DMM to have some confidence)
Warning -- See following post! POE is a better fit on second examination.
Usually when you see four empty holes like that it's a serial port but in this case it looks like there is space for an optional PoE converter module (full 802.3af compliant, instead of 24V passive) and those are pins that link the Ethernet ports to it.
Maybe it is inside the shield box with the CPU or that fine pitch connector site on the top edge of the board near the shield box.
@grosjo that is the partition scheme of the KuWifi; we need to know the partition scheme of the Yuncore to see if it matches.
1 Like
So far, not able to find the serial connectirs
What I get is the "pre-init" IP from my own compilation (Qualcom Platform 147 - Git master) is reached for few seconds then disappear
22:35:06.610095 IP 192.168.0.141 > 192.168.1.49: ICMP echo request, id 3130, seq 43, length 64
22:35:06.610106 IP 192.168.0.141 > 192.168.1.49: ICMP echo request, id 3130, seq 44, length 64
22:35:06.610124 IP 192.168.0.141 > 192.168.1.49: ICMP echo request, id 3130, seq 45, length 64
22:35:06.610356 IP 192.168.1.49 > 192.168.0.141: ICMP echo reply, id 3130, seq 44, length 64
22:35:06.610357 IP 192.168.1.49 > 192.168.0.141: ICMP echo reply, id 3130, seq 45, length 64
22:35:07.573420 IP 192.168.0.141 > 192.168.1.49: ICMP echo request, id 3130, seq 46, length 64
Finally cracked the root password (fund an old commercial firmware which allows "backup" and therefore acces to /etc/shadow)
Here the data I get from dmesg. SO this is AP147. But the AP147 firmware does not want to boot.
[ 0.000000] Kernel command line: board=AP147 console=ttyS0,115200 mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),14528k(rootfs),1472k(kernel),64k(art),16000k@0x50000(firmware) rootfstype=squashfs,jffs2 noinitrd
[ 0.700000] 0x000000000000-0x000000040000 : "u-boot"
[ 0.710000] 0x000000040000-0x000000050000 : "u-boot-env"
[ 0.710000] 0x000000050000-0x000000e80000 : "rootfs"
[ 0.720000] mtd: partition "rootfs" set to be root filesystem
[ 0.730000] mtd: partition "rootfs_data" created automatically, ofs=B20000, len=360000
[ 0.740000] 0x000000b20000-0x000000e80000 : "rootfs_data"
[ 0.740000] 0x000000e80000-0x000000ff0000 : "kernel"
[ 0.750000] 0x000000ff0000-0x000001000000 : "art"
[ 0.750000] 0x000000050000-0x000000ff0000 : "firmware"
[ 0.780000] ag71xx_mdio: probed
[ 0.810000] ar8216: Unknown Atheros device [ver=2, rev=1, phy_id=004dd042]
[ 0.840000] ar8216: Unknown Atheros device [ver=2, rev=1, phy_id=004dd042]
[ 0.860000] ar8216: Unknown Atheros device [ver=2, rev=1, phy_id=004dd042]
[ 0.890000] ar8216: Unknown Atheros device [ver=2, rev=1, phy_id=004dd042]
[ 0.910000] ar8216: Unknown Atheros device [ver=2, rev=1, phy_id=004dd042]
[ 0.920000] ag71xx_mdio: probed
[ 0.920000] eth0: Atheros AG71xx at 0xb9000000, irq 4
[ 1.480000] ag71xx ag71xx.0: eth0: connected to PHY at ag71xx-mdio.1:04 [uid=004dd042, driver=Generic PHY]
[ 1.490000] eth1: Atheros AG71xx at 0xba000000, irq 5
[ 2.050000] eth1: Found an AR934X built-in switch
What I mean is "if I recompile the firmware from git (using AP147) (partitions being the same, and I selcet ext4, and other file formats compiled in), or even the firmware from the downloads.openwrt.org, the new firmware does not boot". SO I am missing something in the compilation but what ?
Additional data from teh console :
root@CPE830D:~# fw_printenv
bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),14528k(rootfs),1408k(uImage),64k(mib0),64k(ART)
bootcmd=bootm 0x9fe80000
bootdelay=2
baudrate=115200
ethaddr=0x00:0xaa:0xbb:0xcc:0xdd:0xee
dir=
lu=tftp 0x80060000 ${dir}u-boot.bin&&erase 0x9f000000 +$filesize&&cp.b $fileaddr 0x9f000000 $filesize
lf=tftp 0x80060000 ${dir}ap152${bc}-jffs2&&erase 0x9f050000 +0xE30000&&cp.b $fileaddr 0x9f050000 $filesize
lk=tftp 0x80060000 ${dir}vmlinux${bc}.lzma.uImage&&erase 0x9fe80000 +$filesize&&cp.b $fileaddr 0x9fe80000 $filesize
stdin=serial
stdout=serial
stderr=serial
ethact=eth0
ipaddr=192.168.0.144
serverip=192.168.0.141
mode=0
sname=austin
It turns out that the partition scheme is the same as the Yuncore 830, so I would expect that firmware to be usable with little or no modification.
It is an unconventional scheme with the kernel placed near the end of the flash instead of at the beginning.
If you can get serial you can see the bootloader log and usually find why it is not booting.
These are squashfs / jffs2 filesystems not ext4. If you want to compile yourself you should look at the Yuncore 830 as a basis.
bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),14528k(rootfs),1408k(uImage),64k(mib0),64k(ART)
bootcmd=bootm 0x9fe80000
@mk24 Should I also change those 2 parameters ?
I am thinking of
bootargs=console=ttyS0,115200 rootfstype=squashfs,jffs2 noinitrd
bootcmd=bootm 0x9fe80000 || bootm 0x9f050000
OpenWrt generally ignores any kernel command line sent from the bootloader. The options are hard-coded into the build.
bootm should be pointed at the kernel partition, so 9fe80000 is correct.
Do you have serial? What does it say when it doesn't boot? Does a manual bootm 0x9fe80000 work?
There is no serial connector on the board.
If I do sysupgrade, the device is not booting
Does "mtd -e firmware -r write xxx.bin firmware" have a better chance of working ?
Finally worked this out !
Details here :
2 Likes