|
Re: Aruba AP-135 February 07, 2022 05:39PM |
Registered: 4 years ago Posts: 112 |
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.
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.
|
Re: Debian on Action Tech SG200 and MI424WR-rev-I March 18, 2022 05:12AM |
Registered: 4 years ago Posts: 112 |
|
Re: Debian on Action Tech SG200 and MI424WR-rev-I March 18, 2022 03:17PM |
Admin Registered: 14 years ago Posts: 19,523 |
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)
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)
|
Re: Debian on Action Tech SG200 and MI424WR-rev-I March 26, 2022 10:52PM |
Registered: 4 years ago Posts: 112 |
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.
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.
|
Re: Debian on Action Tech SG200 and MI424WR-rev-I May 14, 2022 11:11PM |
Registered: 4 years ago Posts: 112 |
|
Re: Debian on Action Tech SG200 and MI424WR-rev-I November 04, 2022 07:56AM |
Registered: 4 years ago Posts: 112 |
|
Re: Debian on Action Tech SG200 and MI424WR-rev-I November 04, 2022 05:34PM |
Admin Registered: 14 years ago Posts: 19,523 |
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)
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)
|
Re: Debian on Action Tech SG200 and MI424WR-rev-I November 04, 2022 09:22PM |
Registered: 4 years ago Posts: 112 |
|
Re: Debian on Action Tech SG200 and MI424WR-rev-I April 22, 2023 02:44PM |
Registered: 3 years ago Posts: 7 |
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 ;(
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 ;(
|
Re: Debian on Action Tech SG200 and MI424WR-rev-I April 22, 2023 02:54PM |
Admin Registered: 14 years ago Posts: 19,523 |
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)
> 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)
|
Re: Debian on Action Tech SG200 and MI424WR-rev-I May 06, 2023 12:03PM |
Registered: 3 years ago Posts: 7 |
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.
- 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.
|
Re: Debian on Action Tech SG200 and MI424WR-rev-I May 10, 2023 07:44AM |
Registered: 3 years ago Posts: 7 |
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.
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.
|
kenballus
Re: Debian on Action Tech SG200 and MI424WR-rev-I August 14, 2023 11:21AM |
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.
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.
