| Message ID | 20210814123356.343682-1-git@aiyionpri.me |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] ath79: add support for onion omega | expand |
Hi Jan, looks pretty solid to me. On 8/14/21 2:33 PM, Jan-Niklas Burfeind wrote: ... > +define Device/onion_omega > + $(Device/tplink-16mlzma) > + SOC := ar9331 > + DEVICE_VENDOR := Onion > + DEVICE_MODEL := Omega > + DEVICE_PACKAGES := kmod-usb-core kmod-usb2 AR9331 uses a different USB2 host controller. It requires the kmod-usb-chipidea2 package instead of kmod-usb2. Also kmod-usb-core can be removed from the package set, as it is a dependency for both. Can you change the package set and verify USB works by plugging in a device? Best David > + SUPPORTED_DEVICES += onion-omega > + KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | uImage lzma > + IMAGE_SIZE := 16192k > + TPLINK_HWID := 0x04700001 > +endef > +TARGET_DEVICES += onion_omega > + > define Device/openmesh_common_64k > DEVICE_VENDOR := OpenMesh > DEVICE_PACKAGES := uboot-envtools >
Hi, one comment inline. W dniu 14.08.2021 o 14:33, Jan-Niklas Burfeind pisze: > The Onion Omega is a hardware development platform with built-in WiFi. > > https://onioniot.github.io/wiki/ > > Specifications: > - QCA9331 @ 400 MHz (MIPS 24Kc Big-Endian Processor) > - 64MB of DDR2 RAM running at 400 MHz > - 16MB of on-board flash storage > - Support for USB 2.0 > - Support for Ethernet at 100 Mbps > - 802.11b/g/n WiFi at 150 Mbps > - 18 digital GPIOs > - A single Serial UART > - Support for SPI > - Support for I2S > > Flash instructions: > The device is running OpenWrt upon release using the ar71xx target. > Both a sysupgrade > and uploading the factory image using u-boots web-UI do work fine. > > Depending on the ssh client, it might be necessary to enable outdated > KeyExchange methods e.g. in the clients ssh-config: > > Host 192.168.1.1 > KexAlgorithms +diffie-hellman-group1-sha1 > > The stock credentials are: root onioneer > > For u-boots web-UI manually configure `192.168.1.2/24` on your computer, > connect to `192.168.1.1`. > > MAC addresses as verified by OEM firmware: > 2G phy0 label > LAN eth0 label - 1 > > LAN is only available in combination with an optional expansion dock. > > Based on vendor acked commit: > commit 5cd49bb067ca ("ar71xx: add support for Onion Omega") > > Partly reverts: > commit fc553c7e4c8e ("ath79: drop unused/incomplete dts") > > Signed-off-by: Jan-Niklas Burfeind <git@aiyionpri.me> > --- > Hello David, > thanks for the review. > I think I got both you as well as Sebastians suggestion patched. > This revision contains them both, compiled without errors this morning > and is currently running on an omega next to me; > dmesg is inconspicuous. > > Thanks > Jan-Niklas/Aiyion > > target/linux/ath79/dts/ar9331_onion_omega.dts | 127 ++++++++++++++++++ > .../generic/base-files/etc/board.d/02_network | 1 + > target/linux/ath79/image/generic.mk | 13 ++ > 3 files changed, 141 insertions(+) > create mode 100644 target/linux/ath79/dts/ar9331_onion_omega.dts > > diff --git a/target/linux/ath79/dts/ar9331_onion_omega.dts b/target/linux/ath79/dts/ar9331_onion_omega.dts > new file mode 100644 > index 0000000000..b08c62221f > --- /dev/null > +++ b/target/linux/ath79/dts/ar9331_onion_omega.dts > @@ -0,0 +1,127 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT > + > +#include <dt-bindings/gpio/gpio.h> > +#include <dt-bindings/input/input.h> > + > +#include "ar9331.dtsi" > + > +/ { > + model = "Onion Omega"; > + compatible = "onion,omega", "qca,ar9331"; > + > + aliases { > + serial0 = &uart; > + led-boot = &led_system; > + led-failsafe = &led_system; > + led-running = &led_system; > + led-upgrade = &led_system; > + }; > + > + leds { > + compatible = "gpio-leds"; > + > + led_system: system { > + label = "amber:system"; > + gpios = <&gpio 27 GPIO_ACTIVE_LOW>; > + }; > + }; > + > + keys { > + compatible = "gpio-keys"; > + poll-interval = <100>; > + > + reset { > + label = "reset"; > + linux,code = <KEY_RESTART>; > + gpios = <&gpio 11 GPIO_ACTIVE_HIGH>; > + debounce-interval = <60>; > + }; > + }; > +}; > + > +&ref { > + clock-frequency = <25000000>; > +}; > + > +&gpio { > + status = "okay"; > +}; > + > +&usb { > + status = "okay"; > + > + dr_mode = "host"; > +}; > + > +&usb_phy { > + status = "okay"; > +}; > + > +ð0 { > + status = "okay"; > + > + compatible = "syscon", "simple-mfd"; > +}; > + > +ð1 { > + status = "okay"; > + > + nvmem-cells = <&macaddr_uboot_1fc00>; > + nvmem-cell-names = "mac-address"; > + mac-address-increment = <(-1)>; > + > + gmac-config { > + device = <&gmac>; > + switch-phy-addr-swap = <4>; > + switch-phy-swap = <4>; > + }; > +}; > + > +&spi { > + status = "okay"; > + > + flash@0 { > + compatible = "jedec,spi-nor"; > + spi-max-frequency = <25000000>; > + reg = <0>; > + > + partitions { > + compatible = "fixed-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + uboot: partition@0 { > + label = "u-boot"; > + reg = <0x000000 0x020000>; Is this really the size of the U-Boot? According to the sources of U-Boot [1] the max size of bootloader is 64KiB. If the sources don't lie, what's between 0x10000-0x20000? Is that some hardcoded data or U-Boot environment? If it's the environment, You can't use static address of the MAC in nvmem-cells, because it can move around if someone modified the environment. For that You'll need to extract it in userspace. 1. https://github.com/OnionIoT/uboot/blob/684829a3a89eabca4b573530e89d60faed277dee/Makefile#L31 > + read-only; > + compatible = "nvmem-cells"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + macaddr_uboot_1fc00: macaddr@1fc00 { > + reg = <0x1fc00 0x6>; > + }; > + }; > + > + partition@20000 { > + compatible = "tplink,firmware"; > + label = "firmware"; > + reg = <0x020000 0xfd0000>; > + }; > + > + art: partition@ff0000 { > + label = "art"; > + reg = <0xff0000 0x010000>; > + read-only; > + }; > + }; > + }; > +}; > + > +&wmac { > + status = "okay"; > + > + mtd-cal-data = <&art 0x1000>; > + nvmem-cells = <&macaddr_uboot_1fc00>; > + nvmem-cell-names = "mac-address"; > +}; [ snip ] Regards
Hey there; answer is inline too. Thanks for picking this up! On 8/14/21 3:54 PM, Tomasz Maciej Nowak wrote: > Hi, > one comment inline. > > W dniu 14.08.2021 o 14:33, Jan-Niklas Burfeind pisze: >> [...] >> + partitions { >> + compatible = "fixed-partitions"; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + >> + uboot: partition@0 { >> + label = "u-boot"; >> + reg = <0x000000 0x020000>; > > Is this really the size of the U-Boot? According to the sources of > U-Boot [1] the max size of bootloader is 64KiB. If the sources don't > lie, what's between 0x10000-0x20000? Is that some hardcoded data or > U-Boot environment? If it's the environment, You can't use static > address of the MAC in nvmem-cells, because it can move around if someone modified the environment. For that You'll need to extract it in > userspace. > > 1. https://github.com/OnionIoT/uboot/blob/684829a3a89eabca4b573530e89d60faed277dee/Makefile#L31 > uboot knows it is 64KiB, printenv yields uboot_size=0x10000 It further knows, firmware starts not before 128Kib: firmware_addr=0x9F020000 these are the last lines of mtd0: 000f8d0 ffff ffff ffff ffff ffff ffff ffff ffff * 001fc00 40a3 6bc1 10b2 ffff ffff ffff ffff ffff 001fc10 ffff ffff ffff ffff ffff ffff ffff ffff * 001fd00 4f4d 4547 41ff ffff ffff ffff ffff ffff 001fd10 ffff ffff ffff ffff ffff ffff ffff ffff * 0020000 The six bytes at 001fc00 are the macaddress. The six bytes at 001fd00 spell OMEGA. >> + read-only; >> + compatible = "nvmem-cells"; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + >> + macaddr_uboot_1fc00: macaddr@1fc00 { >> + reg = <0x1fc00 0x6>; >> + }; >> + }; >> + >> + partition@20000 { >> + compatible = "tplink,firmware"; >> + label = "firmware"; >> + reg = <0x020000 0xfd0000>; >> + }; >> + >> + art: partition@ff0000 { >> + label = "art"; >> + reg = <0xff0000 0x010000>; >> + read-only; >> + }; >> + }; >> + }; >> +}; >> + >> +&wmac { >> + status = "okay"; >> + >> + mtd-cal-data = <&art 0x1000>; >> + nvmem-cells = <&macaddr_uboot_1fc00>; >> + nvmem-cell-names = "mac-address"; >> +}; > > [ snip ] > > Regards >
W dniu 14.08.2021 o 16:37, Jan-Niklas Burfeind pisze: > Hey there; answer is inline too. > Thanks for picking this up! > > On 8/14/21 3:54 PM, Tomasz Maciej Nowak wrote: >> Hi, >> one comment inline. >> >> W dniu 14.08.2021 o 14:33, Jan-Niklas Burfeind pisze: >>> [...] >>> + partitions { >>> + compatible = "fixed-partitions"; >>> + #address-cells = <1>; >>> + #size-cells = <1>; >>> + >>> + uboot: partition@0 { >>> + label = "u-boot"; >>> + reg = <0x000000 0x020000>; >> >> Is this really the size of the U-Boot? According to the sources of >> U-Boot [1] the max size of bootloader is 64KiB. If the sources don't >> lie, what's between 0x10000-0x20000? Is that some hardcoded data or >> U-Boot environment? If it's the environment, You can't use static >> address of the MAC in nvmem-cells, because it can move around if >> someone modified the environment. For that You'll need to extract it in >> userspace. >> >> 1. https://github.com/OnionIoT/uboot/blob/684829a3a89eabca4b573530e89d60faed277dee/Makefile#L31 >> > uboot knows it is 64KiB, printenv yields uboot_size=0x10000 That should be reflected in partitions list and the space between 0x10000-0x20000 partition name should reflect what's inside. If the vendor firmware had a name for this space, use that. > It further knows, firmware starts not before 128Kib: > firmware_addr=0x9F020000 > > these are the last lines of mtd0: > > 000f8d0 ffff ffff ffff ffff ffff ffff ffff ffff > * > 001fc00 40a3 6bc1 10b2 ffff ffff ffff ffff ffff > 001fc10 ffff ffff ffff ffff ffff ffff ffff ffff > * > 001fd00 4f4d 4547 41ff ffff ffff ffff ffff ffff > 001fd10 ffff ffff ffff ffff ffff ffff ffff ffff > * > 0020000 > > The six bytes at 001fc00 are the macaddress. > > The six bytes at 001fd00 spell OMEGA. Is this the only data in 0x10000-0x20000? What's in 0x10000-0x11000? > >>> + read-only; >>> + compatible = "nvmem-cells"; >>> + #address-cells = <1>; >>> + #size-cells = <1>; >>> + >>> + macaddr_uboot_1fc00: macaddr@1fc00 { >>> + reg = <0x1fc00 0x6>; >>> + }; >>> + }; >>> + >>> + partition@20000 { >>> + compatible = "tplink,firmware"; >>> + label = "firmware"; >>> + reg = <0x020000 0xfd0000>; >>> + }; >>> + >>> + art: partition@ff0000 { >>> + label = "art"; >>> + reg = <0xff0000 0x010000>; >>> + read-only; >>> + }; >>> + }; >>> + }; >>> +}; >>> + >>> +&wmac { >>> + status = "okay"; >>> + >>> + mtd-cal-data = <&art 0x1000>; >>> + nvmem-cells = <&macaddr_uboot_1fc00>; >>> + nvmem-cell-names = "mac-address"; >>> +}; >> >> [ snip ] >> Regards
W dniu 2021-08-14 o 17:43, Tomasz Maciej Nowak pisze: > W dniu 14.08.2021 o 16:37, Jan-Niklas Burfeind pisze: >> Hey there; answer is inline too. >> Thanks for picking this up! >> >> On 8/14/21 3:54 PM, Tomasz Maciej Nowak wrote: >>> Hi, >>> one comment inline. >>> >>> W dniu 14.08.2021 o 14:33, Jan-Niklas Burfeind pisze: >>>> [...] >>>> + partitions { >>>> + compatible = "fixed-partitions"; >>>> + #address-cells = <1>; >>>> + #size-cells = <1>; >>>> + >>>> + uboot: partition@0 { >>>> + label = "u-boot"; >>>> + reg = <0x000000 0x020000>; >>> Is this really the size of the U-Boot? According to the sources of >>> U-Boot [1] the max size of bootloader is 64KiB. If the sources don't >>> lie, what's between 0x10000-0x20000? Is that some hardcoded data or >>> U-Boot environment? If it's the environment, You can't use static >>> address of the MAC in nvmem-cells, because it can move around if >>> someone modified the environment. For that You'll need to extract it in >>> userspace. >>> >>> 1. https://github.com/OnionIoT/uboot/blob/684829a3a89eabca4b573530e89d60faed277dee/Makefile#L31 >>> >> uboot knows it is 64KiB, printenv yields uboot_size=0x10000 > That should be reflected in partitions list and the space between > 0x10000-0x20000 partition name should reflect what's inside. If the > vendor firmware had a name for this space, use that. > >> It further knows, firmware starts not before 128Kib: >> firmware_addr=0x9F020000 >> >> these are the last lines of mtd0: >> >> 000f8d0 ffff ffff ffff ffff ffff ffff ffff ffff >> * >> 001fc00 40a3 6bc1 10b2 ffff ffff ffff ffff ffff >> 001fc10 ffff ffff ffff ffff ffff ffff ffff ffff >> * >> 001fd00 4f4d 4547 41ff ffff ffff ffff ffff ffff >> 001fd10 ffff ffff ffff ffff ffff ffff ffff ffff >> * >> 0020000 >> >> The six bytes at 001fc00 are the macaddress. >> >> The six bytes at 001fd00 spell OMEGA. > Is this the only data in 0x10000-0x20000? What's in 0x10000-0x11000? > >>>> + read-only; >>>> + compatible = "nvmem-cells"; >>>> + #address-cells = <1>; >>>> + #size-cells = <1>; >>>> + >>>> + macaddr_uboot_1fc00: macaddr@1fc00 { >>>> + reg = <0x1fc00 0x6>; >>>> + }; >>>> + }; >>>> + >>>> + partition@20000 { >>>> + compatible = "tplink,firmware"; >>>> + label = "firmware"; >>>> + reg = <0x020000 0xfd0000>; >>>> + }; >>>> + >>>> + art: partition@ff0000 { >>>> + label = "art"; >>>> + reg = <0xff0000 0x010000>; >>>> + read-only; >>>> + }; The whole ordeal looks very much like typical pre-safeloader TP-link flash layout, so I expect no writable U-boot environment there, at least for stock U-boot. Of course, it would be best to check if it's possible to write it using serial console, on actual device. >>>> + }; >>>> + }; >>>> +}; >>>> + >>>> +&wmac { >>>> + status = "okay"; >>>> + >>>> + mtd-cal-data = <&art 0x1000>; >>>> + nvmem-cells = <&macaddr_uboot_1fc00>; >>>> + nvmem-cell-names = "mac-address"; >>>> +}; >>> [ snip ] >>> > Regards > Kind regards, Lech
On 8/14/21 5:43 PM, Tomasz Maciej Nowak wrote: > [..] >> uboot knows it is 64KiB, printenv yields uboot_size=0x10000 > > That should be reflected in partitions list and the space between > 0x10000-0x20000 partition name should reflect what's inside. If the > vendor firmware had a name for this space, use that. That's the thing. The stock firmware calls it u-boot, start to finish. root@Omega-10B1:/# cat /proc/mtd dev: size erasesize name mtd0: 00020000 00010000 "u-boot" ... > [...]
On 8/14/21 7:08 PM, Lech Perczak wrote: > [...] >>> >>> The six bytes at 001fd00 spell OMEGA. >> Is this the only data in 0x10000-0x20000? What's in 0x10000-0x11000? >> >>>>> + read-only; >>>>> + compatible = "nvmem-cells"; >>>>> + #address-cells = <1>; >>>>> + #size-cells = <1>; >>>>> + >>>>> + macaddr_uboot_1fc00: macaddr@1fc00 { >>>>> + reg = <0x1fc00 0x6>; >>>>> + }; >>>>> + }; >>>>> + >>>>> + partition@20000 { >>>>> + compatible = "tplink,firmware"; >>>>> + label = "firmware"; >>>>> + reg = <0x020000 0xfd0000>; >>>>> + }; >>>>> + >>>>> + art: partition@ff0000 { >>>>> + label = "art"; >>>>> + reg = <0xff0000 0x010000>; >>>>> + read-only; >>>>> + }; > > The whole ordeal looks very much like typical pre-safeloader TP-link > flash layout, so I expect no writable U-boot environment there, at least > for stock U-boot. > Of course, it would be best to check if it's possible to write it using > serial console, on actual device. > I just tried to copy part of the string "OMEGA" from its current position. > md 0x9F01FD00 9F01FD00: 4F4D4547[...] cp 0x9F01FD00 0x9F01FE00 3 > md 0x9F01FE00 9F01FE00: FFFFFFFF[...] Reading the partition works fine; writing not so much; at least not within uboot. [...]
W dniu 2021-08-15 o 10:30, Jan-Niklas Burfeind pisze: > > On 8/14/21 7:08 PM, Lech Perczak wrote: >> [...] >>>> The six bytes at 001fd00 spell OMEGA. >>> Is this the only data in 0x10000-0x20000? What's in 0x10000-0x11000? >>> >>>>>> + read-only; >>>>>> + compatible = "nvmem-cells"; >>>>>> + #address-cells = <1>; >>>>>> + #size-cells = <1>; >>>>>> + >>>>>> + macaddr_uboot_1fc00: macaddr@1fc00 { >>>>>> + reg = <0x1fc00 0x6>; >>>>>> + }; >>>>>> + }; >>>>>> + >>>>>> + partition@20000 { >>>>>> + compatible = "tplink,firmware"; >>>>>> + label = "firmware"; >>>>>> + reg = <0x020000 0xfd0000>; >>>>>> + }; >>>>>> + >>>>>> + art: partition@ff0000 { >>>>>> + label = "art"; >>>>>> + reg = <0xff0000 0x010000>; >>>>>> + read-only; >>>>>> + }; >> The whole ordeal looks very much like typical pre-safeloader TP-link >> flash layout, so I expect no writable U-boot environment there, at least >> for stock U-boot. >> Of course, it would be best to check if it's possible to write it using >> serial console, on actual device. >> > I just tried to copy part of the string "OMEGA" from its current position. > >> md 0x9F01FD00 > 9F01FD00: 4F4D4547[...] > > cp 0x9F01FD00 0x9F01FE00 3 >> md 0x9F01FE00 > 9F01FE00: FFFFFFFF[...] > > Reading the partition works fine; writing not so much; at least not > within uboot. I rather meant checking if it is possible to 'saveenv' from within stock U-boot, rebooting and seeing if changes to the environment change stay there. Given, that the typical SPI-NOR sector size on this target is 64k, it's very unlikely that there is writable environment there, as the MAC part doesn't follow its format, and U-boot would need to use 4k page erase for that, as does pepe2k's u-boot_mod, but OpenWrt currently cannot reliably support writing such environment. > > [...] > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 8/15/21 11:39 AM, Lech Perczak wrote: > [...] > I rather meant checking if it is possible to 'saveenv' from within stock > U-boot, rebooting and seeing if changes to the environment change stay > there. > Given, that the typical SPI-NOR sector size on this target is 64k, it's > very unlikely that there is writable environment there, as the MAC part > doesn't follow its format, and U-boot would need to use 4k page erase > for that, > as does pepe2k's u-boot_mod, but OpenWrt currently cannot reliably > support writing such environment. The command "saveenv" is not available in the stock uboot.
W dniu 2021-08-15 o 13:03, openwrt@aiyionpri.me pisze: > > On 8/15/21 11:39 AM, Lech Perczak wrote: >> [...] >> I rather meant checking if it is possible to 'saveenv' from within stock >> U-boot, rebooting and seeing if changes to the environment change stay >> there. >> Given, that the typical SPI-NOR sector size on this target is 64k, it's >> very unlikely that there is writable environment there, as the MAC part >> doesn't follow its format, and U-boot would need to use 4k page erase >> for that, >> as does pepe2k's u-boot_mod, but OpenWrt currently cannot reliably >> support writing such environment. > The command "saveenv" is not available in the stock uboot. So, we've got the answer - the flash layout in device tree is then correct. > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
W dniu 15.08.2021 o 13:18, Lech Perczak pisze: > W dniu 2021-08-15 o 13:03, openwrt@aiyionpri.me pisze: >> >> On 8/15/21 11:39 AM, Lech Perczak wrote: >>> [...] >>> I rather meant checking if it is possible to 'saveenv' from within stock >>> U-boot, rebooting and seeing if changes to the environment change stay >>> there. >>> Given, that the typical SPI-NOR sector size on this target is 64k, it's >>> very unlikely that there is writable environment there, as the MAC part >>> doesn't follow its format, and U-boot would need to use 4k page erase >>> for that, >>> as does pepe2k's u-boot_mod, but OpenWrt currently cannot reliably >>> support writing such environment. >> The command "saveenv" is not available in the stock uboot. > So, we've got the answer - the flash layout in device tree is then correct. Yep, and thanks for chiming in. With that the MAC can be safely extracted by nvmem. Reviewed-by: Tomasz Maciej Nowak <tmn505@gmail.com> Regards
diff --git a/target/linux/ath79/dts/ar9331_onion_omega.dts b/target/linux/ath79/dts/ar9331_onion_omega.dts new file mode 100644 index 0000000000..b08c62221f --- /dev/null +++ b/target/linux/ath79/dts/ar9331_onion_omega.dts @@ -0,0 +1,127 @@ +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT + +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/input/input.h> + +#include "ar9331.dtsi" + +/ { + model = "Onion Omega"; + compatible = "onion,omega", "qca,ar9331"; + + aliases { + serial0 = &uart; + led-boot = &led_system; + led-failsafe = &led_system; + led-running = &led_system; + led-upgrade = &led_system; + }; + + leds { + compatible = "gpio-leds"; + + led_system: system { + label = "amber:system"; + gpios = <&gpio 27 GPIO_ACTIVE_LOW>; + }; + }; + + keys { + compatible = "gpio-keys"; + poll-interval = <100>; + + reset { + label = "reset"; + linux,code = <KEY_RESTART>; + gpios = <&gpio 11 GPIO_ACTIVE_HIGH>; + debounce-interval = <60>; + }; + }; +}; + +&ref { + clock-frequency = <25000000>; +}; + +&gpio { + status = "okay"; +}; + +&usb { + status = "okay"; + + dr_mode = "host"; +}; + +&usb_phy { + status = "okay"; +}; + +ð0 { + status = "okay"; + + compatible = "syscon", "simple-mfd"; +}; + +ð1 { + status = "okay"; + + nvmem-cells = <&macaddr_uboot_1fc00>; + nvmem-cell-names = "mac-address"; + mac-address-increment = <(-1)>; + + gmac-config { + device = <&gmac>; + switch-phy-addr-swap = <4>; + switch-phy-swap = <4>; + }; +}; + +&spi { + status = "okay"; + + flash@0 { + compatible = "jedec,spi-nor"; + spi-max-frequency = <25000000>; + reg = <0>; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + uboot: partition@0 { + label = "u-boot"; + reg = <0x000000 0x020000>; + read-only; + compatible = "nvmem-cells"; + #address-cells = <1>; + #size-cells = <1>; + + macaddr_uboot_1fc00: macaddr@1fc00 { + reg = <0x1fc00 0x6>; + }; + }; + + partition@20000 { + compatible = "tplink,firmware"; + label = "firmware"; + reg = <0x020000 0xfd0000>; + }; + + art: partition@ff0000 { + label = "art"; + reg = <0xff0000 0x010000>; + read-only; + }; + }; + }; +}; + +&wmac { + status = "okay"; + + mtd-cal-data = <&art 0x1000>; + nvmem-cells = <&macaddr_uboot_1fc00>; + nvmem-cell-names = "mac-address"; +}; diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network b/target/linux/ath79/generic/base-files/etc/board.d/02_network index 4fe7fbc027..b859c64633 100644 --- a/target/linux/ath79/generic/base-files/etc/board.d/02_network +++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network @@ -45,6 +45,7 @@ ath79_setup_interfaces() netgear,ex7300|\ ocedo,koala|\ ocedo,raccoon|\ + onion,omega|\ openmesh,mr600-v1|\ openmesh,mr600-v2|\ openmesh,mr900-v1|\ diff --git a/target/linux/ath79/image/generic.mk b/target/linux/ath79/image/generic.mk index 2abe1b7307..5b39e89bbb 100644 --- a/target/linux/ath79/image/generic.mk +++ b/target/linux/ath79/image/generic.mk @@ -1653,6 +1653,19 @@ define Device/ocedo_ursus endef TARGET_DEVICES += ocedo_ursus +define Device/onion_omega + $(Device/tplink-16mlzma) + SOC := ar9331 + DEVICE_VENDOR := Onion + DEVICE_MODEL := Omega + DEVICE_PACKAGES := kmod-usb-core kmod-usb2 + SUPPORTED_DEVICES += onion-omega + KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | uImage lzma + IMAGE_SIZE := 16192k + TPLINK_HWID := 0x04700001 +endef +TARGET_DEVICES += onion_omega + define Device/openmesh_common_64k DEVICE_VENDOR := OpenMesh DEVICE_PACKAGES := uboot-envtools
The Onion Omega is a hardware development platform with built-in WiFi. https://onioniot.github.io/wiki/ Specifications: - QCA9331 @ 400 MHz (MIPS 24Kc Big-Endian Processor) - 64MB of DDR2 RAM running at 400 MHz - 16MB of on-board flash storage - Support for USB 2.0 - Support for Ethernet at 100 Mbps - 802.11b/g/n WiFi at 150 Mbps - 18 digital GPIOs - A single Serial UART - Support for SPI - Support for I2S Flash instructions: The device is running OpenWrt upon release using the ar71xx target. Both a sysupgrade and uploading the factory image using u-boots web-UI do work fine. Depending on the ssh client, it might be necessary to enable outdated KeyExchange methods e.g. in the clients ssh-config: Host 192.168.1.1 KexAlgorithms +diffie-hellman-group1-sha1 The stock credentials are: root onioneer For u-boots web-UI manually configure `192.168.1.2/24` on your computer, connect to `192.168.1.1`. MAC addresses as verified by OEM firmware: 2G phy0 label LAN eth0 label - 1 LAN is only available in combination with an optional expansion dock. Based on vendor acked commit: commit 5cd49bb067ca ("ar71xx: add support for Onion Omega") Partly reverts: commit fc553c7e4c8e ("ath79: drop unused/incomplete dts") Signed-off-by: Jan-Niklas Burfeind <git@aiyionpri.me> --- Hello David, thanks for the review. I think I got both you as well as Sebastians suggestion patched. This revision contains them both, compiled without errors this morning and is currently running on an omega next to me; dmesg is inconspicuous. Thanks Jan-Niklas/Aiyion target/linux/ath79/dts/ar9331_onion_omega.dts | 127 ++++++++++++++++++ .../generic/base-files/etc/board.d/02_network | 1 + target/linux/ath79/image/generic.mk | 13 ++ 3 files changed, 141 insertions(+) create mode 100644 target/linux/ath79/dts/ar9331_onion_omega.dts