You'll need to create a basic DTS to start with, and build a ramdisk image with that so you can boot off that and work towards full support (booting from RAM won't break stuff, writing broken images to flash will).
You'll need to find out things like GPIOs used (reset button e.g. but not just that), it helps if your device was supported on ar71xx because that would mean there's a machine file that would already contain a lot of info.
No, you do need the correct flash layout, lest you overwrite radio calibration data and other configuration stuff the OEM might have implemented. So you need to figure out how your flash chip is 'partitioned'. /proc/mtd on the OEM firmware should show you the names & sizes of partitions. That's what you'll build on. That is part of the first link@frollic gave you. The pages might be dense but they're so for a reason, you need to read them thoroughly.
Look at similar hardware already supported (starting with the same SoC), check the makefiles in target/linux/ath79/image/ for pointers. DTS files are also sorted by SoC. Wikidevi often has technical info on what's inside. And based on /proc/mtd contents of the OEM firmware you write the flash part of your DTS.
P.S. You might want to untick your own post as 'solution', your topic will automatically close with a solution selected and your own post doesn't really look like the answer to your question.
Are you sure? I'm finding this page... Gives you something to go on at least, looks like it's a family of APs with similar hardware.
dmesg also contains a lot of useful info (SoC e.g.), you can look at the QCA9558 DTSes for pointers, and check the ath79 Makefiles to see if Engenius uses some custom magic e.g. for its firmware images - OpenWrt needs to mimick that for factory images.
@niklasarnitz I have ENS1750 which is same hardware (and same FCC ID) and I will be adding it when I have the time. When I am at the point of testing images we can work together fo see if theres any differences other than the image preparation (I have already grabbed the OEM firmware downloads and unpacked them to compare the stored "modelname" for the OEM sysupgrade
Nice!
That sounds great.
I have several of them here so I can test without having to fear bricking one of them.
They should be pretty easily recoverable over TFTP tho.
I have compiled some information extracted from the running device here:
I never had a POE power supply that could power this thing and I have been busy with other things, but I'm about to get one that should work and probably within 2 weeks I'm going to publish a pull request for this device.
however like I mentioned, the different model names for the same hardware situation means the factory.bin must be different, because of how Engenius does firmware upgrades, so we will technically be adding 2 devices, even though they are the same. Either you can work on the second one yourself based on mine or I can, and you would test some images.
unfortunately my board is fried, not sure how, it seems to have a very sophisticated POE controller that handles failures and overcurrent, but it's dead and replacing it didn't work either. I cannot figure out where to inject voltage to do normal power instead of POE. i did get it for really cheap so that might have something to do with it... maybe my board was hit by lightning or something....
anyway I can still work with you to add this thing
