with some patience, tricks and manually commanding u-boot I've got a device that is currently not supported by openwrt to boot into a openwrt initrd.
It is a very nice device. It has 256M NAND flash 128M RAM, ARM926EJ-S CPU, 2 ethernet ports, 4G LTE, 3x RS232-, 1x RS485, 1x USB Ports, 2x SMA plugs for antennas and 6 LEDs.
I think is is worth to add support in openwrt.
I have already a git clone of openwrt and compiled something with it.
My questions:
How do I tweak compiler directives (ifdefs) for the "u-boot-nand" ? The architecture/board that I have chosen is missing watchdog and SPI-flash support. I've had a hard time to get my "bricked" device working again. I've not found special options for the u-boot in the "main menuconfig". When I do "make menuconfig" in the u-boot subdirectory I can find these options but it does not recompile.
How do I get the devicetree that I obtained from a partition of that device into the kernel build of openwrt ? Maybe with creating a new defconfig section or creating a new "board" in the kernel tree ? How gets this applied via patch or direct editing Kconfig file.
(PS: the luci running from initrd shows me already board "R3000", where did it got that info ?)
How can I flash an initial OpenWRT root filesystem in the first UBIFS partition.
may I directly use files found in
build_dir/target-arm_arm926ej-s_musl_eabi/root-at91
for (3) ?
How do I instruct the kernel to boot from that ubifs partition instead of the internal initrd ? Or is it "somehow" automatic with changing root dir in the boot script ?
How should the MTD partition layout look like for stock openwrt firmware upgrade to work? I have "firmware" for the kernel+initrd and "user" for the 2 partitions of UBIFS
Do I need to rename (delete/recreate) MTD partitions ?
No, "R3000" is just some name the manufacturer has given it. It has an ATMEL CPU.
The mainboard is called "eg9012". It seems to have a predecessor "eg9011".
cat /proc/cpuinfo
processor : 0
model name : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 195.58
Features : swp half fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5
You need bootloader access via same console and replicate kernel entrypoint in your kernel mtd partition content.
uboot is part of SoC bringup, you need lots of glue to compile it from zero
2
dump OEM partitions or binwalk OEM firmware upgrade file
3
if OEM bootloader is of no help you need SPI programmer
4
first ramdisk without programming
5
have you booted anything? kind of you will figure answer by the time all hardware is supported by your initrd
6
you need to determine OEM upgrade to device block mapping and basically provide hacked together file that replaces OEM to OpenWRT
You can name mtd partitions way you like. Just dont overwrite OEM partitions with IMEI, MAC, bootloaders, serials etc.
to (5): I solved this problem by patching the /init script from the initrd.
There I included "ubiattach" and "mount" commands together with
"switch_root" command. Now my patched installation is installed permanently on the device.
That's a pretty old CPU core, not really in line with "256M NAND", "128M RAM" and LTE capabilities, but your cpuinfo and the bogomips (that is in the ballpark of the original wrt-54g, over two decades ago!) affirm the situation.
It's not going to be fun[0], and the SOC must be offloading a lot of capabilities to hardware IP blocks, which is not really promising in terms of getting driver support. So you'd be looking at bootstrapping a new target and getting a lot of rather specific drivers working for your hardware, 'possible', but not very realistic (unless you you love a steep learning curve, a real challenge and have years+ of development time at your disposal).
--
[0] even just running luci will be slooow and 'not fun'.
Well at least the SAM9x25 data sheet / reference manual is not behind NDA. The whole ~1100 page document is on microchip's website =P
But yeah I see limited application on this from a "router" perspective. Great from an IoT perspective with all those serial ports, 4G modem capability, can do bonding between two ethernet ports etc.
Edit:
Had a look on eBay. This is used as an elevator controller?
Of course my time is not endless, but I think it should be possible with just "ticking" the "right options" before compilation. The OEM software on this device looks very likely to be an older fork of openwrt. There are mostly open-source and well known programs and directory layouts in the base file-system. Also "uci" is used. I guess(hope) all the needed drivers are already in the kernel mainline.
Realistically, chances of success are low - and the resulting device will be barely usable due to the abysmally slow CPU, based on the original usage scenario, I'd guess the 4g module is only accessed via serial (enough to send command codes, but not fast enough to get reasonable speeds) as well). If you want to spend the time necessary for SOC bringup (mainline linux) and then work on the new target and device support, all the more power to you - I just don't think this is a realistic endeavour, especially not given the ancient ARM SOC and its extremely low speed.
What's the OEM firmware running, kernel 2.2, 2.4 or 2.6?
Adding device information only becomes sensible, once you'd have the device (almost) working with current OpenWrt. For the very first device investigation, things like https://wikidevi.wi-cat.ru/ tend to be a better option (or using this thread), but the wiki is only meant for devices that are supported by official OpenWrt (respectively close to becoming officially supported).
All OEM firmwares use OpenWrt to some extent (that doesn't make your task any easier), but rip out the kernel and replace that (and many other things) with the proprietary vendor kernel.