Hi @c-mauderer, full bootlog from 2.5.0 stock firmware:
https://ybin.me/p/6a91c99dba0adb9f#hPSAdudwiUbXjt/J3Dw0a2At94M0Kv4oTveglwTRlxE=
In fact there are different clock speeds:
[ 0.000000] Clocks: CPU:560.000MHz, DDR:450.000MHz, AHB:225.000MHz, Ref:40.000MHz
[ 0.000000] clocksource MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6825930166 ns
[ 0.000009] sched_clock: 32 bits at 280MHz, resolution 3ns, wraps every 7669584382ns
What is a lot more interesting: It's a completely different SOC:
From my ISP boot log:
[ 0.000000] SoC: Qualcomm Atheros QCA9533 ver 2 rev 0
From your AC boot log:
[ 0.000000] SoC: Atheros AR9342 rev 2
Seems that the AC is an earlier version (still a "Atheros" without "Qualcomm"). So I assume they designed that board first and created a cost down version of it later and called it "ISP".
So porting to the AC most likely needs nearly everything that was necessary for the ISP too. Basically that has been the following patch: https://github.com/openwrt/openwrt/commit/8a4dc6f48c0a4503b655195846ae1bff9a691a40
more precisely, it is somewhat different. when you compare registers in datasheets of both it becomes clear.
Yes right. It was a bit exaggerated to tell it "completely" different. Most likely it's the same family but a different generation.
@hrns: Do you have enough experience to try to adapt it for yourself? Otherwise: Do you have enough patience for a lot of questions and trial and error via the forum?
@c-mauderer I will try to figure something out based on your work. So how does ubiquiti build one image both for ISP and AC?
Hi, I've done the following:
Everything is OK except LED. Is there simple way to completely switch off LED?
Great. Don't hesitate to ask if you are stuck.
Like @psyborg mentioned: The SOCs are only "somewhat different". They have the same core and most likely very similar peripherals. Maybe some more or some less or at other addresses but similar enough. Ubiquiti doesn't use a device tree. Most likely they just check which SOC they are on and initialize slightly different based on the result.
For FDT based systems it would be possible to let U-Boot load the one or the other FDT based on the detected SOC and start the same binary too.
Sorry, but currently there is no simple method. I implemented a driver for the LED controller but it turned out that the GPIO-SPI is too fast and it doesn't accept a slower baudrate. The slower baudrate needs an adaption of the driver in the Linux Kernel. But that touches well optimized code and it's difficult to not have a performance impact for all other targets.
It maybe could work with some tricks in the U-Boot environment. But I would only suggest to touch that if you have access to a serial console and if you have at least some experience with U-Boot. Otherwise it's easy to brick your device.
@c-mauderer I have a very early alpha version of a build that boots on ACB AC, but I'm getting some errors while tftboot procedure. I can see in your notes that your firmware build for ACB ISP was smaller than my current build:
ISP:
ath> setenv serverip 192.168.1.100
ath> help tftpboot
tftpboot [loadAddress] [bootfilename]
ath> tftpboot 0x81000000 openwrt-ath79-generic-ubnt_acb-isp-squashfs-sysupgrade.bin
eth0 link down
enet1 port1 up
dup 1 speed 1000
Using eth1 device
TFTP from server 192.168.1.100; our IP address is 192.168.1.20
Filename 'openwrt-ath79-generic-ubnt_acb-isp-squashfs-factory.bin'.
Load address: 0x81000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#######
done
Bytes transferred = 2031620 (1f0004 hex)
ath> erase 0x9f050000 0x9ffaffff
Erasing flash...
First 0x5 last 0xfa sector size 0x10000
250
Erased 246 sectors
ath> cp 0x81000000 0x9f050000 ${filesize}
Copy to Flash... write addr: 9f050000
done
ath> reset
AC:
ar7240> tftpboot 0x81000000 openwrt-ath79-generic-ubnt_acb-ac-squashfs-sysupgrade.bin
Using eth0 device
TFTP from server 192.168.1.10; our IP address is 192.168.1.20
Filename 'openwrt-ath79-generic-ubnt_acb-ac-squashfs-sysupgrade.bin'.
Load address: 0x81000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##########################
done
Bytes transferred = 4457217 (440301 hex)
ar7240> erase 0x9f050000 0x9ffaffff
............................................................................................................................................................................................e
Erased 246 sectors
ar7240> cp 0x81000000 0x9f050000 ${filesize}
Copy to Flash... Outside available Flash
ar7240> echo ${filesize}
440301
My guess is that I didn't erase enough memory. If so, how did you calculate the upper address for erase command?
Great.
That's odd. Your firmware shouldn't be much bigger. You only have one additional driver. That should be far less then 100 or 200kByte. Do you have your patch uploaded somewhere so that I can take a look at it?
Be very careful with the erase command. There is a calibration data section at the end of the flash. If you overwrite that you will brick your device.
Regarding the sizes: There are multiple possibilities: One is to take a look at the mtd partitions. In U-Boot:
ath> mtdparts
device nor0 <spi0.0>, # parts = 6
#: name size offset mask_flags
0: u-boot 0x00040000 0x00000000 0
1: u-boot-env 0x00010000 0x00040000 0
2: kernel 0x00400000 0x00050000 0
3: rootfs 0x00b60000 0x00450000 0
4: cfg 0x00040000 0x00fb0000 0
5: EEPROM 0x00010000 0x00ff0000 0
active partition: nor0,0 - (u-boot) 0x00040000 @ 0x00000000
defaults:
mtdids : nor0=spi0.0
mtdparts: mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),4096k(kernel),11648k(rootfs),256k(cfg),64k(EEPROM)
ath>
Note that the addresses are from start of flash. To get the start address you can use the U-Boot command bdinfo.
u-boot and u-boot-env are for U-Boot. EEPROM contains calibration data and must not be removed. I would expect that cfg contains the original firmware configuration but I'm not entirely sure. Therefore I wouldn't suggest to remove that.
If you want to make sure that you don't loose the calibration data: Make a backup. The original U-Boot isn't very well equipped. So I think the only possibility for the backup is to use memory dump (md) of big blocks and save the output to a text file. In the worst case you can convert that to something useful.
But anyway: Your image has 4457217 Bytes (0x440301). If you add that to the start address you get 0x9f490301 which is still not outside of your flash. So the error is odd. Make sure that your start addresses are all the same.
Ok so I think that start address is the same as ISP:
ar7240> bdinfo
boot_params = 0x83F77FB0
memstart = 0x80000000
memsize = 0x04000000
flashstart = 0x9F000000
flashsize = 0x01000000
flashoffset = 0x0002AABC
ethaddr = 00:AA:BB:CC:DD:EE
ip_addr = 192.168.1.20
baudrate = 115200 bps
I also downloaded the firmware for ISP from openwrt site (https://openwrt.org/toh/ubiquiti/ubiquiti_aircube_isp) and compared the sizes:
-rw-r--r-- 1 root root 7368738 lut 20 20:34 ACB.ar934x.v2.5.0.be3e459.190520.1449.bin
-rw-r--r-- 1 root root 4784792 lut 19 22:59 openwrt-ath79-generic-ubnt_acb-ac-squashfs-factory.bin
-rw-r--r-- 1 root root 4784897 lut 19 23:04 openwrt-ath79-generic-ubnt_acb-ac-squashfs-sysupgrade.bin
-rw-r--r-- 1 root root 4194968 lut 20 20:35 openwrt-ath79-generic-ubnt_acb-isp-squashfs-factory.bin
-rw-r--r-- 1 root root 4194577 lut 20 20:50 openwrt-ath79-generic-ubnt_acb-isp-squashfs-sysupgrade.bin
Except for the original firmware it seems that AC build and ISP build are quite similar. I can't reproduce the tftboot procedure with any of them. @c-mauderer in your notes the image is smaller than the one uploaded to openwrt site, maybe I should use other tool (like fwgen from your github) to build the image?
It has 16 MB of flash. You aren't anywhere close to running out of space.
Always use cp.b to copy in terms of bytes. I think u-boot with a regular cp assumes the size is in 32-bit words, which is going to exceed the flash (and if you're really unlucky, clobber the ART).
To back up the ART, boot stock firmware and run cat /dev/mtd5 > /tmp/art.bin This should produce a file of exactly 65536 bytes. SCP the file to your PC and save it in a safe place.
It seems that this is a bug in my notes and in the guide in the OpenWRT wiki. I'll fix that.
Maybe you are aware of it, but I found that calibration is made accessible from /lib/firmware/ath10k/cal-pci-0000:00:00.0.bin which is a symbolic link to /tmp/ath10k/cal-pci-0000:00:00.0.bin.
That file is exactly 2116 bytes long and it is an extract from /dev/mtd5 at offset 0x5000
I don't know how that file is created with stock firmware nor needed with OpenWrt.
Finally got serial console working (thanks rpi). I made a custom OpenWrt sysupgrade image derivated from your work.
MTD are the same, making job easier. Unfortunately, kernel failed on SPI probing:
[ 0.424895] m25p80 spi0.0: unrecognized JEDEC id bytes: 00, 00, 00
[ 0.431203] m25p80: probe of spi0.0 failed with error -2
Can someone points me in a good direction for solving this issue?
I tried modifying DTS but no luck...
David
Hello @davidb2111,
it's been a while since I last had a look at this.
From the message: The air cube ISP would print the following two lines:
[ 0.789618] m25p80 spi0.0: found mx25l12805d, expected m25p80
[ 0.796785] m25p80 spi0.0: mx25l12805d (16384 Kbytes)
That's basically the information what kind of SPI flash has been connected. It seems that your system received a 00 00 00 when it tried to read the ID of the flash chip. That means that there is nothing connected. 3 possible reasons:
There really is no SPI flash. In that case the AC maybe boots from some other source. Take a look at the PCB whether there is a SPI flash or not.
The flash is connected to another SPI peripheral. That's not unlikely.
The controller uses different pins for the SPI. Also not unlikely.
2 and 3 would point toward a bug in the FDT. You maybe have to adapt it to fit the AC. Best guess is to compare it to FDTs of other routers with the same chip like used on the AC.
Best regards
Christian
PS: Seems that the mail reply I tried first didn't work. If you get the same response twice it maybe worked a bit later 
Hello @davidb2111,
it's been a while since I last had a look at this.
From the message: The air cube ISP would print the following two lines:
[ 0.789618] m25p80 spi0.0: found mx25l12805d, expected m25p80
[ 0.796785] m25p80 spi0.0: mx25l12805d (16384 Kbytes)
That's basically the information what kind of SPI flash has been
connected. It seems that your system received a 00 00 00 when it tried
to read the ID of the flash chip. That means that there is nothing
connected. 3 possible reasons:
There really is no SPI flash. In that case the AC maybe boots from
some other source. Take a look at the PCB whether there is a SPI flash
or not.
The flash is connected to another SPI peripheral. That's not unlikely.
The controller uses different pins for the SPI. Also not unlikely.
2 and 3 would point toward a bug in the FDT. You maybe have to adapt it
to fit the AC. Best guess is to compare it to FDTs of other routers with
the same chip like used on the AC.
Best regards
Christian
Hi!
Thank you very much for your time!
I flashed official f/w from Ubiquiti. The SPI is well detected:
[ 0.595428] m25p80 spi0.0: found mx25l12805d, expected m25p80
[ 0.602388] m25p80 spi0.0: mx25l12805d (16384 Kbytes)
[ 0.607562] 6 cmdlinepart partitions found on MTD device spi0.0
[ 0.613612] Creating 6 MTD partitions on "spi0.0":
[ 0.618482] 0x000000000000-0x000000040000 : "u-boot"
[ 0.624527] 0x000000040000-0x000000050000 : "u-boot-env"
[ 0.630763] 0x000000050000-0x000000450000 : "kernel"
[ 0.636708] 0x000000450000-0x000000fb0000 : "rootfs"
[ 0.642614] mtd: device 3 (rootfs) set to be root filesystem
[ 0.648378] 0x000000fb0000-0x000000ff0000 : "cfg"
[ 0.654041] 0x000000ff0000-0x000001000000 : "EEPROM"
I will make additional tests tonight.
David.
OK. So you can skip possibility 1. Leaves 2 (wrong SPI) and 3 (wrong pins). Like I said: Take a look at some other FDTs for the chip of the AC.
Hello!
I wanted to share my experience. Finally I managed to boot a brand new OpenWrt firmware on Aircube AC. The DTS was almost good, I just updated OpenWrt to 19.07.3 (was on your experimental branch as of now) and the SPI Flash was detected.
I had to modify the eth0 definition in the DTS.
So far, almost everything is working, except blinking led, as you pointed already.
For this last point, uboot is capable of managing the led when in urescue mode (the speed is changing), so I think the definition to that led should not be so "exotic".
Again, thank you for initiating the port to Aircube as my work was utterly based on yours.
David