Sorry, I haven't checked the thread in a while. Honestly, I'm not sure if the nand would be of any help. It seemed like someone had maybe attempted a firmware update that failed or something before I got it. I couldn't get it to boot up. If you are interested in it though, I could probably send it to you if you're in the US.
Because of the behavior of the bootloader -- even bootm start performs the whole boot process on its own -- it's likely a u-boot replacement will be necessary.
That is, unless we can use the "bidio" to tell U-boot how to perform the boot process. Perhaps the addresses of the kernel, dtb and rootfs are defined there somehow? It's very clear that bidio is parsed, because its values determine whether or not u-boot interacts with the secondary serial console.
I will send out a letter to Hewlett Packard this week and see if they respond to snail-mail requests for GPL sources for their U-boot. I'll also look closer at the bidio file to see whether it contains any sort of encoding of the address scheme ...
Because I saw them, and because they were too well-priced to avoid, I purchased 7 of these: https://fccid.io/RTP-MRLBB1003S
So far as I can tell (I haven't received them yet) they are very similar to the prototype described above, but probably without GPS. We'll find out.
Hi hurricane,
Any update?
I can help to test the u-boot.
I really don't want to bother him with it, so I won't @ him, but I did see in blocktrron's staging tree a commit which supposedly provides support for the MSM460: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=commitdiff;h=6644a444807b7762fd5397890a8c6abacb3608cb
In particular, I notice that the device tree specifies a hint for the chosen entry required to get this board to boot:
/* Needed for initramfs */
bootargs-override = "console=ttyS0,115200 ubi.mtd=3,2048";
If that works, fantastic. He's also using a FIT image in the same commit, which I doubt the stock U-Boot supports, but ...
As I've found over the last year from his advice, I'm guessing there only reason the kernel doesn't boot is some early boot issue that can be solved by being more hands-on during the firmware interface between U-Boot and Linux.
blocktrron's staging tree have a new commit for msm460: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=log;h=refs/heads/msm460-2024
1 Like
Yeah, I know that blocktrron (not @ing to avoid notification) was working on this a few years back (check that original author date of Tue, 6 Dec 2022 18:14:21 -0500 (00:14 +0100)).
He mentioned using it for Freifunk, and that its biggest problem is the construction of the power supply for the mPCIe slots; the power supply is/was weak enough that modern Mediatek cards would brown-out, which was difficult to deal with as they were firmware driven.
I believe for a bootloader, he originally built and used a version of u-boot. He shared https://github.com/blocktrron/u-boot-msm/. Looks like that's been bumped recently.
I never attempted to build this u-boot. I know that this Freescale board boots by using the bootrom / eLBC (?) to bootstrap the U-boot loader process from NAND. I don't know how the RCW is configured by the SMD components on the board, but https://github.com/blocktrron/u-boot-msm/commit/15378bc9e0d483a15ae9ab8fe1e712e88308b17f clearly indicates a particular TEXT_BASE for u-boot. I haven't looked back, but again, clearly that's a solved problem.
In terms of getting this U-Boot on, considering it's a NAND BGA, I reckon that, unless the user has a JTAG device like the BDI2000 or BDI3000 and the knowledge required to use it to rewrite NAND (I never got that far https://github.com/Hurricos/openwrt/issues/21), the process must be to use the original exploit we've found to gain shell access, then manually replace u-boot from within the OEM Linux shell.
A problem for OpenWrt supportability is that U-boot replacements generally "should be" maintained in-tree (see all the Marvell devices). I will be the first to admit that I am unqualified, and that I don't want to bother David to ask to maintain the u-boot port under the OpenWrt libc / build system.
That said, the 460 / 560 series are nice APs. I can look back in my email, it's possible he gave me direct instructions for how to build and I just neglected it because I was (and still am) not a great developer :^)