Debian on Action Tech SG200 and MI424WR-rev-I

bkallus,
Look at my u-boot repo here. I provided a toolchain from marvell. I found this in actiontech official site.
https://github.com/msdos03/avanta-uboot-f660
Whatever, try all the kwboot sources you know, then you are more likely to find a usable one.



Edited 1 time(s). Last edit at 02/07/2022 05:49PM by 8086k.

Hi bodhi
It's me again, I find the cause of realtek chip issue now.
Can you run DSA driver on 88f6560 internal switch now? I don't have much time to read the driver code, but I have read it briefly. Many functions are similar. Have a look on this project, please.

8086k,

I have not revisited this at all. It seems there is always something else more important on my list!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi,

It looks like rtl8192ce card is extremely sensitive to the time of PEX initialization. Adding a little delay could change the problem a lot. For example, before I add the delay, AP mode of channel 1 is unable to transfer data at all. After I add the delay, channel 1 is able to transfer data but there's massive packet loss and delay. I found a factor causing rtl8192ce problem.

bodhi,

Do you know what is 'CPU Streaming' in marvell SoCs? Does it mean hardware decoding or something else?

bodhi,

Hi, now I have made marvell DSA driver work with 88f6560 internal switch. Check the patches in my repo!
link
Please consider add 88f6560 support in your debian.



Edited 1 time(s). Last edit at 11/04/2022 07:56AM by 8086k.

8086k,

My ActionTec MI424WR-rev-I has been put away in a closet. One of these days when nothing else going on, I'll boot it up again.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi,

Also, welcome to create pull request for my repo to make openwrt support MI424WR revi. I don't have it so I can't add it to support.

Perhaps I should make another thread for this, but ...

For booting the AP-135, since it doesn't play nice with kwboot for some reason, we must try the stock bootloader. Its bootloader does not have a proper bootm; its `boot` command will always check[^1] that the image it is booting is signed.

The other option is to use `go` to jump to an image directly; the same idea was used in the ath79-based ap105 and ap175[^2].

I tried the naive way -- `go` a `zImage` directly -- but it triggers a `data abort` and crashes after a few instructions, probably because the MMU is running at that point[^3]. Basically, a few instruction in, the CPU is told to jump to an exception handler in U-Boot.

I think my next step is to fulfill the full requirements of the ARM boot ABI, as cleanup_before_linux does in u-boot. Funny enough, Avanta is Feroceon inside, which is developed atop the xscale architecture, and the Linux kernel has arch/arm/boot/compressed/head-xscale.S which does ALL the same stuff I need. So my next attempt will be to try with either CONFIG_CPU_XSCALE (or similar) enabled. If that works, then I will need to work out a patch for OpenWrt which ensures this loader code is called whenever booting a zImage -- probably easy enough to do, it's a similar idea to target/linux/ath79/image/lzma-loader or target/linux/mpc85xx/image/spi-loader in OpenWrt.

[^1]
According to a friend on the #openwrt-devel IRC:

> The AP-135['s stock U-Boot] can self-modify the signature check and use the original wrapper code

- OK. I think I see the way through the first option. I think Aruba
`boot` command lets you feed a header type not signing the image.

- OK. AP-135 (arran) uses __ENFORCE_SIGNED_IMAGES__ 1:
https://github.com/shalzz/aruba-ap-310/blob/master/platform/bootloader/apboot-11n/include/configs/arran_config.h#L15

- image_verify checks this to see whether to fall through when an
image header indicates an image is unsigned:
https://github.com/shalzz/aruba-ap-310/blob/master/platform/bootloader/apboot-11n/xyssl-0.9/image_verify.c#L168

- even if I satisfy the header requirement from
aruba_basic_image_verify:
https://github.com/shalzz/aruba-ap-310/blob/master/platform/bootloader/apboot-11n/common/apboot-util.c#L98
...

- .... still, image_verify, the caller of aruba_basic_image_verify,
will bail when it sees I do not have a signature.

- image_verify is called in the process of the `boot` command.

- So, I must either binary patch the code for image_verify to ignore
that or accept a signature corresponding to a cert not originally
intended, or I must ignore `boot` entirely and perform the ARM
`cleanup_before_linux` routine to satisfy the boot ABI per
https://www.kernel.org/doc/Documentation/arm/Booting before simply
running `go` on the zImage.

[^2]: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=e11d00d44c66b1534fbc399fda55951cd0a2168a

[^3]: . It crashes immediately if fed a zImage
(https://paste.c-net.org/OccasionExtended), which tells me that `go`
misses a requirement from
https://www.kernel.org/doc/Documentation/arm/Booting

- The obvious problem is that zImage and lzma-loader are extremely
similar but don't perform identical roles

- arch/arm/boot/compressed/head.S !=
target/linux/ramips/image/lzma-loader/src/head.S

- Yes. I get this exception https://paste.c-net.org/OccasionExtended
because my MMU is running (go does nothing to disable it), and the
faulting instruction at offset 0x28 must do some kind of memory access
which is invalid and triggers an exception from the MMU ...

- and https://www.kernel.org/doc/Documentation/arm/Booting tells me I
can't have my MMU running ;(

hurricos,

> For booting the AP-135, since it doesn't play nice
> with kwboot for some reason, we must try the stock
> bootloader.

kwboot works with the MI424WR-rev-I. So perhaps the Aruba uses a different u-boot or bootROM version? which u-boot image are you using for kwboot?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I actually used the image for the MI424WR-rev-I. I think the issue is interference on the serial line: either

- there is a level converter between the serial console which is not active until the bootROM is done, or

- the serial console on the outside of the AP135 is ttyS1, not ttyS0.

I know there's a level converter because the serial console is an external RS232-compatible one -- so, 12~15V instead of 3v3.

Edit: to be clear, kwboot never even reaches the handshake point on this board.



Edited 1 time(s). Last edit at 05/06/2023 12:03PM by hurricos.

My current problem is the same as the one I have been getting since my Apr 22 post above: when I `go` this zImage:

https://downloads.laboratoryb.org/ap135/openwrt-avanta-generic-aruba_ap-135-initramfs-uImage

.... that at the first real instruction, a `050000ea` (which is a 5-word branch from 0x20 to 0x3c), I get a data abort from the MMU: https://paste.c-net.org/OccasionExtended (it shows at 0x28 because of pipelining). I think the MMU doesn't believe I should be able to execute 0x3c:

```console
[mkennedy@genie Downloads]$ rasm2 -D -B -a arm -b 32 -c arm -f openwrt-avanta-generic-aruba_ap-135-initramfs-uImage | head -20
0x00000000 4 0000a0e1 mov r0, r0
0x00000004 4 0000a0e1 mov r0, r0
0x00000008 4 0000a0e1 mov r0, r0
0x0000000c 4 0000a0e1 mov r0, r0
0x00000010 4 0000a0e1 mov r0, r0
0x00000014 4 0000a0e1 mov r0, r0
0x00000018 4 0000a0e1 mov r0, r0
0x0000001c 4 0000a0e1 mov r0, r0
0x00000020 4 050000ea b 0x3c
0x00000024 4 18286f01 invalid
0x00000028 4 00000000 andeq r0, r0, r0
0x0000002c 4 f8bb4700 strdeq fp, ip, [r7], -0xb8
0x00000030 4 01020304 streq r0, [r3], -0x201
0x00000034 4 45454545 strbmi r4, [r5, -0x545]
0x00000038 4 9c740000 muleq r0, ip, r4
0x0000003c 4 00900fe1 mrs sb, apsr
0x00000040 4 0170a0e1 mov r7, r1
```

This beginning segment corresponds to this part of head.S:

```assembly
start:
.type start,#function
/*
* These 7 nops along with the 1 nop immediately below for
* !THUMB2 form 8 nops that make the compressed kernel bootable
* on legacy ARM systems that were assuming the kernel in a.out
* binary format. The boot loaders on these systems would
* jump 32 bytes into the image to skip the a.out header.
* with these 8 nops filling exactly 32 bytes, things still
* work as expected on these legacy systems. Thumb2 mode keeps
* 7 of the nops as it turns out that some boot loaders
* were patching the initial instructions of the kernel, i.e
* had started to exploit this "patch area".
*/
__initial_nops
.rept 5
__nop
.endr
#ifndef CONFIG_THUMB2_KERNEL
__nop
#else
AR_CLASS( sub pc, pc, #3 ) @ A/R: switch to Thumb2 mode
M_CLASS( nop.w ) @ M: already in Thumb2 mode
.thumb
#endif
W(b) 1f

.word _magic_sig @ Magic numbers to help the loader
.word _magic_start @ absolute load/run zImage address
.word _magic_end @ zImage end address
.word 0x04030201 @ endianness flag
.word 0x45454545 @ another magic number to indicate
.word _magic_table @ additional data table

__EFI_HEADER
1:
ARM_BE8( setend be ) @ go BE8 if compiled for BE8
AR_CLASS( mrs r9, cpsr )
```

... the branch is used to jump past these early .word setups.

So, I have to figure out why I'm getting a data abort -- assuming it's the MMU, why the MMU doesn't like the branch -- assuming because 0x3c isn't executable, how to mark that ahead of time -- assuming that I can't do that after running `go`, how to mark it up before I do.

Hey hurricos,

I'm interested in picking this up again. I'm guessing from your download link that you're in Burlington, VT. I'm down in Hanover, NH, and I would definitely make the drive up to Burlington to work on this with you at the hackerspace.

Shoot me an email (email address at the bottom of the page on my website) if you're up for it.