Hey guys, I also have a ap3825i, now I successfully installed openwrt(BTW thank guys porting this device) now I have problem, I tried to run debootstrap to make a powerpc Debian root, and using chroot, but chroot said "Illegal instruction" , I tried to switch to other distro, like ubuntu 16.04, but chroot is still say that, is this kernel not support chroot? what should I do ?
Hey there -- try starting with an OpenWrt or Alpine Linux chroot. I'm gonna guess there are some compilation differences that have come up recently.
1 Like
Yes, you are right, I'm try to chroot to /rom, and it's successed XD
Guys, I am trying the chroot Gentoo ppc musl, but there is still a problem with the "Illegal Instruction". "cat", "uname" commands can be executed normally, but "ping", "bash", "top" still prompts "Illegal Instruction", I am shown in the screenshot. What should I do?
Definitely look into the portage scripts for the binaries. Gentoo is probably using different compiler options. Can you share how you're doing this?
All - I am running into a curl error (132) when using ddns on a ws-ap3825i (using recent stable release 22.03). I have posted it here:
Any suggestions?
I've found that the time is basically always incorrect on first boot. There's some bug in sysntpd startup that I have not tracked down.
I will pull on that - so because the time is off, the cert generated at first boot by uhttpd uses the incorrect date/time, and then it is rejected when presented for the TLS handshake? (correct me where I am off here).
I have tried to regenerate the uhttpd cert with its defaults and use that for curl in ddns.
Not sure about DDNS' use of client-side certs, I thought DDNS only used the remote's cert.
I've also run into that ddns issue (with the ws-ap3825i, but it would surprise me if that's specific to this device). It broke in one of the later RCs. It did work at the beginning.
Thanks for confirming that. I am going to switch back to another head end router (TP-Link 4300) to get the ddns stable again. Will continue to monitor and experiment with using 3825 in the future.
I had switched my head end router to the 3825 to have a little more processing power with the two cores and more memory. Plus the wifi radios were not working / being detected by OpenWRT on this particular AP out of the lot that I bought.
I downloaded the gentoo powerpc musl stage3 version, I extracted the .tar.xz to my USB disk and tried to chroot it, I just tried it again via RJ45-CONSOLE, it outputs some error messages that seem to be about libc.so, and I also readelf the gentoo "sh" for reference. What is the problem?
Thanks for the context. I can reproduce. Trying with gdb.
You may want to recompile your Gentoo with a bit less optimization. Here's what I'm getting, with my rootfs mounted at /tmp/chroot:
root@ap3825i3:/tmp/chroot# gdb --args `which chroot` /tmp/chroot bash
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc-openwrt-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/chroot...
(No debugging symbols found in /usr/sbin/chroot)
(gdb) run
Starting program: /usr/sbin/chroot /tmp/chroot bash
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
process 13765 is executing new program: /tmp/chroot/bin/bash
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
Program received signal SIGILL, Illegal instruction.
0xb7fb1268 in setjmp () from /tmp/chroot/usr/lib/libc.so
(gdb) bt
#0 0xb7fb1268 in setjmp () from /tmp/chroot/usr/lib/libc.so
#1 0x0040fbb4 in ?? ()
#2 0xb7f41724 in ?? () from /tmp/chroot/usr/lib/libc.so
#3 0xb7f4178c in __libc_start_main () from /tmp/chroot/usr/lib/libc.so
#4 0x00411438 in ?? ()
#5 0x004113fc in ?? ()
Quick search points to setjmp hackery making musl unhappy. Have you tested this powerpc musl stage3 on another ppc32?
Here's the relevant bit of setjmp disassembled:
0xb7fb120c <+0>: mflr r0
0xb7fb1210 <+4>: stw r0,0(r3)
0xb7fb1214 <+8>: stw r1,4(r3)
0xb7fb1218 <+12>: mfcr r0
0xb7fb121c <+16>: stw r0,8(r3)
0xb7fb1220 <+20>: stw r14,12(r3)
0xb7fb1224 <+24>: stw r15,16(r3)
0xb7fb1228 <+28>: stw r16,20(r3)
0xb7fb122c <+32>: stw r17,24(r3)
0xb7fb1230 <+36>: stw r18,28(r3)
0xb7fb1234 <+40>: stw r19,32(r3)
0xb7fb1238 <+44>: stw r20,36(r3)
0xb7fb123c <+48>: stw r21,40(r3)
0xb7fb1240 <+52>: stw r22,44(r3)
0xb7fb1244 <+56>: stw r23,48(r3)
0xb7fb1248 <+60>: stw r24,52(r3)
0xb7fb124c <+64>: stw r25,56(r3)
0xb7fb1250 <+68>: stw r26,60(r3)
0xb7fb1254 <+72>: stw r27,64(r3)
0xb7fb1258 <+76>: stw r28,68(r3)
0xb7fb125c <+80>: stw r29,72(r3)
0xb7fb1260 <+84>: stw r30,76(r3)
0xb7fb1264 <+88>: stw r31,80(r3)
=> 0xb7fb1268 <+92>: .long 0xd9c30058
0xb7fb126c <+96>: .long 0xd9e30060
0xb7fb1270 <+100>: .long 0xda030068
0xb7fb1274 <+104>: .long 0xda230070
0xb7fb1278 <+108>: .long 0xda430078
0xb7fb127c <+112>: .long 0xda630080
0xb7fb1280 <+116>: .long 0xda830088
0xb7fb1284 <+120>: .long 0xdaa30090
0xb7fb1288 <+124>: .long 0xdac30098
0xb7fb128c <+128>: .long 0xdae300a0
0xb7fb1290 <+132>: .long 0xdb0300a8
0xb7fb1294 <+136>: .long 0xdb2300b0
0xb7fb1298 <+140>: .long 0xdb4300b8
0xb7fb129c <+144>: .long 0xdb6300c0
0xb7fb12a0 <+148>: .long 0xdb8300c8
0xb7fb12a4 <+152>: .long 0xdba300d0
0xb7fb12a8 <+156>: .long 0xdbc300d8
0xb7fb12ac <+160>: .long 0xdbe300e0
0xb7fb12b0 <+164>: li r3,0
0xb7fb12b4 <+168>: blr
0xb7fb12b8 <+172>: li r0,119
0xb7fb12bc <+176>: sc
0xb7fb12c0 <+180>: li r0,172
0xb7fb12c4 <+184>: sc
Here is musl's setjmp. I can't disassemble 0xd9c30058, but maybe it's doing some 64-bit vector register tickling RE evstdd? That is, maybe the compiler is targeting a machine that this is not.
It's even not working on my iBOOK G4 
maybe this package no one use it and no one check it 
Hey pros, Have you encountered this situation? I tried USB boot in U-boot, but I can't activate the USB hub, I input
usb start or usb reset
commands and u-boot will said
USB: WARNING: USB phy type not defined !!
Error, couldn't init Lowlevel part
How to solve it? thanks!
Okay, I solved this problem, Now I log it how to work out.
WS-AP3825i using the "Freescale P1020" Soc, The P1020 processor uses the "e500v2" microarchitecture, according to Wikipedia, e500 does not have a traditional FPU but an SPE (Signal Processing Engine), which has floating point capabilities and some special SIMD instructions, but its SPE instructions are not compatible with the "Standard PowerPC". This is the reason why my PowerPC program crashed when I tried to run it before.
Because of the incompatibility with some of the PowerPC instructions, e500/e500v2 compatible systems and compilers have a separate ABI for it. For example debian and freebsd set it to "powerpcspe".
OpenWRT is a special case, because OpenWRT itself does not need much floating point, and the GCC compiler lost support for powerpcspe in 9.2 version, so OpenWRT uses a "soft floating point" PowerPC toolchain, treating the e500 as a "Standard PowerPC" without fpu, and simulating float point operations through software. So e500 SPE's floating point instructions and SIMD became unavailable, This is not exactly "compatible".
I tried to find a powerpcspe compatible linux for chroot, and found that only debian used to support (until 2019.5.19) powerpcspe, FreeBSD still does, but it's not Linux so I can't use it
Debian moved powerpcspe out of the mirrors, so I used the last snapshot in the debian snapshot that supported ppcspe:
https://snapshot.debian.org/archive/debian-ports/20190519T171610Z/
use debootstrap make rootfs
debootstrap --arch=powerpcspe unstable debian https://snapshot.debian.org/archive/debian-ports/20190519T171610Z/
and chroot it
chroot debian bash
That's all, and I attach a picture of my successful debian chroot, hope it helps you 
1 Like
Hi guys,
im trying to get Luci running on the AP3825i.
OpenWrt is working fine.
It seems to be that the related Luci Package is currently unavailable. Is there any workaround?
opkg update
Downloading https://downloads.openwrt.org/snapshots/packages/powerpc_8548/luci/Packages.gz
*** Failed to download the package list from https://downloads.openwrt.org/snapshots/packages/powerpc_8548/luci/Packages.gz
Try Release Channel? snapshot is not very stable.
Hi, I checked your GPL dump for 3825, I noticed that in p1020_sku.c there are only definitions for AP3710 and AP3725
#ifdef CHANTRY
#define AP_NUM_PCI_BUSES 7
#define AP3710_NUM_PCI_DEVICES 4
#define AP3710_NUM_PCI_ATHEROS 2
#define AP3725_NUM_PCI_DEVICES 8
#define AP3725_NUM_PCI_ATHEROS 3
#define AP_NUM_PCI_BUS_DEVICES (AP3725_NUM_PCI_DEVICES+2)
also 3825 calls itself as p1020_rdb not sku, and there is no p1020_rdb file, have you confirmed that this u-boot can be compiled and run on AP3825? Thanks!