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!
@hurricos
Looks like the same error as Aerohive AP330
## Booting kernel from FIT Image at 02000000 ...
Using 'config-1' configuration
Trying 'kernel-1' kernel subimage
Description: POWERPC OpenWrt Linux-5.15.98
Type: Kernel Image
Compression: lzma compressed
Data Start: 0x020000ec
Data Size: 3289114 Bytes = 3.1 MiB
Architecture: PowerPC
OS: Linux
Load Address: 0x00000000
Entry Point: 0x00000000
Hash algo: crc32
Hash value: 5593af3b
Hash algo: sha1
Hash value: ff4819ce70d208eedf6b91dcfb12c06d09ca3b04
Verifying Hash Integrity ... crc32+ sha1+ OK
## Flattened Device Tree from FIT Image at 02000000
Using 'config-1' configuration
Trying 'fdt-1' FDT blob subimage
Description: POWERPC OpenWrt extreme-networks_ws-ap3825i device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x02323258
Data Size: 20480 Bytes = 20 KiB
Architecture: PowerPC
Hash algo: crc32
Hash value: 7aba8381
Hash algo: sha1
Hash value: ca269898fae5ab7fb45ecec33edfe9fcf5a32113
Verifying Hash Integrity ... crc32+ sha1+ OK
Booting using the fdt blob at 0x2323258
Uncompressing Kernel Image ... OK
WARNING: could not set reg FDT_ERR_NOSPACE.
ft_fixup_cpu: FDT_ERR_NOSPACE
ft_fixup_l2cache: FDT_ERR_NOTFOUND
WARNING: could not set reg FDT_ERR_NOSPACE.
WARNING: could not set bootargs FDT_ERR_NOSPACE.
WARNING: could not set linux,stdout-path FDT_ERR_NOSPACE.
It's a different issue from the AP330: on the AP330, we don't have enough partition space to store the kernel uncompressed; when we use compression, the stock U-boot is unable to decompress the image because its gzip implementation fails on large images.
In your example, the AP3825i is decompressing things just fine. However, after the FDT is copied into RAM, U-boot has to make some changes and is failing because it isn't aware it is allowed to expand into slightly higher (+4K) memory.
Could you show us your setenv, and give me a download link to the sysupgrade image you used to install your exact version of OpenWrt shown here?
I have not.
Check your PM.
OK, I can confirm snapshot doesn't boot right now.
I can confirm there is a regression somewhere here:
[labby@hashtag openwrt]$ git bisect log
git bisect start
# status: waiting for both good and bad commits
# bad: [a7a3de5edb142c7cefdb6e810cc07a6222f7541d] ath79: fix user LED glow on Mikrotik 911 Lite boards
git bisect bad a7a3de5edb142c7cefdb6e810cc07a6222f7541d
# status: waiting for good commit(s), bad commit known
# good: [595509cc781e7d45d19ddead24a0c424c610b5c0] openssl: fix powerpc & arc libatomic dependencies
git bisect good 595509cc781e7d45d19ddead24a0c424c610b5c0
The regression does not affect us if we setenv bootm_size 0x3000000;.
Bisecting now, but honestly, I'm sure it's the bump from 5.10 to 5.15. The way we boot is very fragile.
Once I confirm that the 5.10->5.15 bump is the culprit, I'll use the __log_buf scraping process I worked up here to find where we're crashing. Since both the initramfs and sysupgrade images crash on boot, it isn't an issue of the kernel size, but since limiting bootm_size below 48M fixes it, it has to be some early arch-specific stuff; maybe a change in some options during the 5.10 -> 5.15 port?
1 Like
@hurricos
hi, I am testing my AP and need to see how to speed port up:100mb, 1000mb or 10mb
on tp-link c6 with switch, i write comand:
Tp-Link-C6:~# swconfig list
Found: switch0 - mdio.0
Tp-Link-C6:~# swconfig dev switch0 show | grep port:4
link: port:4 link:up speed:1000baseT full-duplex txflow rxflow auto
but on 3825i does not switch
root@AP3825i:~# swconfig list
root@AP3825i:~#
how see port speed on 3825i board or how see this with additional commands?
i test iperf3 serwer on two ports and see port status
i use two comands:
root@AP3825i:~#iperf3 -s -D
root@AP3825i:~#iperf3 -s -p 5001 -D
local iperf3 test
root@AP3825i:~# iperf3 -c x.x.x.x
Connecting to host x.x.x.x, port 5201
[ 5] local x.x.x.x port 37144 connected to x.x.x.x port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 145 MBytes 1.21 Gbits/sec 0 1.94 MBytes
[ 5] 1.00-2.00 sec 142 MBytes 1.20 Gbits/sec 0 1.94 MBytes
[ 5] 2.00-3.01 sec 144 MBytes 1.20 Gbits/sec 0 1.94 MBytes
[ 5] 3.01-4.01 sec 142 MBytes 1.19 Gbits/sec 0 1.94 MBytes
[ 5] 4.01-5.01 sec 142 MBytes 1.20 Gbits/sec 0 1.94 MBytes
[ 5] 5.01-6.00 sec 142 MBytes 1.20 Gbits/sec 0 1.94 MBytes
[ 5] 6.00-7.00 sec 142 MBytes 1.20 Gbits/sec 0 1.94 MBytes
[ 5] 7.00-8.01 sec 144 MBytes 1.20 Gbits/sec 0 1.94 MBytes
[ 5] 8.01-9.00 sec 142 MBytes 1.20 Gbits/sec 0 1.94 MBytes
[ 5] 9.00-10.00 sec 142 MBytes 1.20 Gbits/sec 0 1.94 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.40 GBytes 1.20 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.40 GBytes 1.20 Gbits/sec receiver
thank you very much
root@AP3825i:~# ethtool eth1 | grep Speed
Speed: 1000Mb/s
root@AP3825i:~# ethtool eth0 | grep Speed
Speed: 1000Mb/s
root@AP3825i:~#
@hurricos Hello!
There a new bug,system sees only one core with 1000 mHz freq
cat /proc/cpuinfo
processor : 0
cpu : e500v2
clock : 1000.000000MHz
revision : 5.1 (pvr 8021 2051)
bogomips : 250.00
total bogomips : 250.00
timebase : 125000000
platform : P1020 RDB
model : Extreme Networks WS-AP3825i
Memory : 256 MB
Dmesg:
mpic: Resetting
[ 0.000000] mpic: Setting up MPIC " OpenPIC " version 1.2 at ffe40000, max 2 CPUs
[ 0.000000] mpic: ISU size: 256, shift: 8, mask: ff
[ 0.000000] mpic: Initializing for 256 sources
[ 0.000000] WARNING: Estimating decrementer frequency (not found)
[ 0.000000] WARNING: Estimating processor frequency (not found)
[ 0.000000] time_init: decrementer frequency = 125.000000 MHz
[ 0.000000] time_init: processor frequency = 1000.000000 MHz
[ 0.000002] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x39a85c4118, max_idle_ns: 881590405314 ns
[ 0.000008] clocksource: timebase mult[4000000] shift[23] registered
[ 0.000018] clockevent: decrementer mult[20000000] shift[32] cpu[0]
[ 0.000056] pid_max: default: 32768 minimum: 301
[ 0.000126] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.000135] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.000515] mpic: requesting IPIs...
[ 0.000928] rcu: Hierarchical SRCU implementation.
[ 0.001021] dyndbg: Ignore empty _ddebug table in a CONFIG_DYNAMIC_DEBUG_CORE build
[ 0.001102] smp: Bringing up secondary CPUs ...
[ 0.001316] No cpu-release-addr for cpu 1
[ 0.001324] smp: failed starting cpu 1 (rc -2)
[ 0.001344] smp: Brought up 1 node, 1 CPU
[ 0.002310] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
Yup, this is a known issue. See this Github thread.
To summarize the above thread, something broke during 5.10 -> 5.15; we're not sure what. To handle that, we allowed U-Boot to relocate the DTB, and used a simpleImage boot wrapper so we could ignore the U-Boot modified DTB, instead providing a patched DTB which contains the fixes U-Boot should have done. We weren't as particularly careful there as we should have been :^)
@blocktrron has fixes in his staging tree (note to late readers: his staging tree had the fix at time of writing; no guarantees later): https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=shortlog;h=refs/heads/master
... the fixes handle some other quirks that the stock U-Boot's firmware interface expect Linux to be able to deal with.
I'm gonna test these fixes in the next couple of days as I work on the outdoor WS-AP3865e.
P.S. The core doesn't actually run at 1GHz, funny enough -- at least not as far as I can tell (a single threaded process is still just as slow as it is on 2C@800MHz).
If you need testers,just let me know.