Son kullanma tarihi geçmiş, bayatlamış bir tarayıcı kullanıyorsanız, Mercedes kullanmak yerine tosbağaya binmek gibi... Web sitelerini düzgün görüntüleyemiyorsanız eh, bi' zahmet tarayıcınızı güncelleyiniz. Modern Web standartlarını karşılayan bir tarayıcı alternatifine göz atın.
H3601P V9 OpenWrt süreci ve UART kilidi kırılmış bootloader (U-Boot) imajı
Bu cihaza OpenWrt portlamak için uzun zamandır UART tarafında incelemeler yapıyordum. Ancak uboot ve kernel tarafında uart konsolu fiilen kapalıydı; tek UART çıktısı cihaz açıldığı andaki BootROM satırlarıydı (Boot SPI NAND / Jump / non secure uboot). Ondan sonra uart tamamen susuyordu, uboot ve kernel çıktısı yoktu. Sorun kablo veya pinler değil, stok uboot’un seri tablosuydu.
PC’de TFTPD64 Konfigürasyonunda: Current Directory’de mtdflash ve mtd1_Bootloader_1MiB_uartfix.bin içeren klasör seçilecek.
Bu patch tamamen deneyseldir. Yamayı ana router olarak kullananların, aktif kiralama süreci devam edenlerin ve temel düzeydeki kullanıcıların denemesi tavsiye edilmez. Uygulamadan doğabilecek tüm riskler ve sorumluluk tamamen yöntemi uygulayan kişiye aittir.
Bu SoC üzerinde OpenWrt'i boot etmeyi başardıktan sonra Ethernet ve PCIe sürücülerini halledebilirsem, sorunsuz çalışan bir port ortaya çıkabilir. ZXIC gibi kaynak/dokümantasyon bulunmayan bir HiSilicon SoC barındıran HG255S için de çoğu şeyi reverse engineering yaparak sıfırdan sürücü yazmış ve sorunsuz çalışan bir port ortaya çıkarmıştım. (Huawei HG255s OpenWrt) Port sürecinde H3601P için de benzer bir yol izlenecek; zira bu SoC OpenWrt tarafından desteklenmiyor.
Hello, I also have an H3621P with the same UART behavior. If you'd like, I can share the dump I got from the SPI NAND for you to examine. However, I haven't been able to get the TFTP connection to work. Can you help me?
Merhaba, bende de aynı UART davranışına sahip bir H3621P var. İsterseniz incelemeniz için SPI NAND'den aldığım dökümü (dump) paylaşabilirim. Ancak TFTP bağlantısını bir türlü çalıştıramadım. Yardımcı olabilir misiniz?
Hello, I also have an H3621P with the same UART behavior. If you'd like, I can share the dump I got from the SPI NAND for you to examine. However, I haven't been able to get the TFTP connection to work. Can you help me?
Merhaba, bende de aynı UART davranışına sahip bir H3621P var. İsterseniz incelemeniz için SPI NAND'den aldığım dökümü (dump) paylaşabilirim. Ancak TFTP bağlantısını bir türlü çalıştıramadım. Yardımcı olabilir misiniz?
if you upload that spi dump, i will inspect the bootloader partition for patching. It might take me a few days to look at the dump, bc im busy these days.
Eğer tam dump'ı paylaşırsan, bootloader partisyonunu yamalamak için inceleyebilirim. Ancak birkaç gün sürer, zira şu sıralar meşgulüm.
H3601P OpenWrt portundan haber var: NAND açılışı, NPU ve Wi-Fi tamam.
İlk mesajda UART konsolunu açmış, bu cihazda OpenWrt çalıştırmak için uğraştığımı yazmıştım. Son durumu da aynı konuya bırakayım: H3601P artık kendi NAND belleğinden OpenWrt açıyor. LuCI, kablolu ağ, iki Wi-Fi bandı ve NPU hızlandırması çalışıyor.
Kendi cihazımda kullandığım LAN/WAN, kablosuz bağlantı ve NAT tarafında stok yazılımdaki gibi sorunsuz çalışıyor. Cihazı kapatıp açınca doğrudan OpenWrt geliyor; her seferinde UART'tan imaj yüklemek gerekmiyor. Ayarlar ve kurulan paketler de kalıcı.
Hız tarafında geldiğim nokta:
Kablolu: Gigabit bağlantı sorunsuz. Kendi testlerimde 1 Gbit hattın beklenen aktarım seviyesine ulaşabiliyorum.
5 GHz / 160 MHz: Uygun istemciyle, NPU hızlandırması devredeyken gigabit seviyesinde veri aktarımı yapabiliyorum.
2.4 GHz ve 5 GHz: İki radyo birlikte çalışıyor. İstemci bağlandığında uygun akışların hızlandırmaya alınması otomatik.
Bunlar veri aktarımında gördüğüm sonuçlar. Aşağıdaki LuCI ekranındaki “RX Rate / TX Rate” ise istemcinin o andaki kablosuz bağlantı hızı; hız testi sonucu değil. Ekran görüntülerini 80 MHz kullanırken aldım, 160 MHz testini ayrı yaptım.
Buraya nasıl geldik?
Bu SoC için elimde hazır bir OpenWrt portu veya register'ları baştan sona açıklayan bir üretici kılavuzu yoktu. Cihazdan aldığım tam NAND dump'ı, bootloader, stok kernel ve sürücü modülleri üzerinden ilerledim. İlgili fonksiyonları disassemble/decompile ederek hangi register'a ne yazıldığını, DMA ring'lerinin nasıl kurulduğunu ve paketlerin hangi yoldan geçtiğini çıkardım. Sonra bunları güncel Linux/OpenWrt tarafına uyarlayıp cihaz üzerinde denedim.
Donanım da kısaca şöyle: Sanechips/ZTE ZX279128S, 1 GHz çift çekirdek Cortex-A9, 256 MiB RAM, 256 MiB Winbond SPI-NAND ve MediaTek MT7916 Wi-Fi 6. Üç Gigabit Ethernet portu var: iki LAN, bir WAN. İşlemci tarafında soft-float kullanılıyor.
İki çekirdek ve PCIe: İkinci çekirdeğin açılışını IRAM'deki küçük başlangıç kodu ve SCU üzerinden hazırladım. Sonrasında iki çekirdek açıkken Wi-Fi bağlantısında oluşan kilitlenmelerle uğraştım. Stok kernel'de PCIe register okumalarıyla PL310 cache bakım işlemlerinin aynı kilit altında yapıldığını görünce eksik kalan taraf ortaya çıktı. Cache-sync ve hizasız erişimlerin sınır işlemlerini de kapsayacak şekilde bu davranışı uyarladım. Şu an iki çekirdek de açık; cihaz tek çekirdeğe düşürülmüş bir şekilde çalışmıyor.
Ethernet ve NPU: TM, buffer manager, DMA, MDIO ve PHY tarafı için cihazın donanımına uygun sürücü kodu yazıldı. IPv4 NAT akışlarını izleyip uygun bağlantıları SoC'nin classifier ve packet modifier tablolarına yerleştiren bölüm de bu çalışmanın parçası. Hızlandırmaya uygun olmayan paketler normal Linux ağ yolundan devam ediyor.
Wi-Fi: Burada OpenWrt'nin mt76 sürücüsünü temel aldım. Sıfırdan bütün bir Wi-Fi sürücüsü yazdığımı söylemiyorum. MT7916'nın iki PCIe arayüzü, firmware yükleme sırası, kesmeler ve NAPI tarafı bu platforma uyarlandı. SoC'nin IDM DMA birimiyle kablosuz gönderim yolu arasında da bağlantı kuruldu. Kuyruk sırası, paket belleğinin kime ait olduğu, TX tamamlanmaları ve istasyon ayrıldığında eski akışların temizlenmesi özellikle uğraştırdı. Sonuçta kablosuz tarafta da NPU'dan yararlanan yol çalışır hâle geldi.
NAND ve açılış: Stok CSPBOOT'un beklediği başlıkları, CRC'leri ve banka seçimini çözerek OpenWrt imajını kabul ettiği biçimde paketledim. İlk başta NAND'dan initramfs açtırdım; ardından kalıcı depolamayı ve normal imajı hazırladım. Sistem artık Bank B'deki kernel ve UBI içindeki SquashFS kök dosya sistemiyle açılıyor.
Depolama için eski Bank A'nın 80 MiB alanını, sondaki 87 MiB alanla birleştirdim. Böylece 167 MiB'lık kalıcı yazılabilir alan oluştu. Bu bölüm JFFS2 kullanıyor. İlk denemede OOB cleanmarker yüzünden ECC hatası çıkınca, marker'ı tam bir NAND veri sayfasına yazan in-band düzenini ekledim. Yeniden bağlama ve yeniden başlatma sonrasında dosyaların kaldığını da kontrol ettim. Bank A artık depolama alanı; eski stok yedek firmware bankası olarak durmuyor.
Son olarak LuCI içeren normal SquashFS imajını ve cihaza özel sysupgrade yolunu hazırladım. sysupgrade -n ile initramfs ortamından normal sisteme temiz kurulumu cihaz üzerinde yaptım. Kurulum kernel'i ve kök dosya sistemini yazıp geri okuyarak karşılaştırıyor; bootloader'ın göreceği başlığı en son yazıyor.
Ne kadar kod çıktı?
Güncel platformun C, header ve assembly kısmı 22 dosyada 12.420 fiziksel satır. Bunun içinde Ethernet/TM 4.128, NPU/L3 3.016, IDM donanım sürücüsü 1.450 ve WLAN fast-path 1.345 satır. Bunlara ek olarak mt76 tarafında 30 yama dosyası var: toplam 5.047 satır patch metni, seri boyunca 2.187 eklenen ve 374 çıkarılan satır.
Satır sayıları yorum ve boş satırları da içeriyor. Patch dosyasındaki bağlam satırlarıyla Linux/OpenWrt'nin mevcut kodunu “benim yazdığım kod” diye toplamadım. Sonraki yamalar önceki denemeleri değiştirebildiği için patch toplamı da tek seferde eklenmiş benzersiz kod sayısı değil. Derleme, depolama, kurulum ve yardımcı dosyaları da aşağıda dosya dosya bıraktım.
Bu liste güncel uygulama ve destek dosyalarının sayımıdır. Eski sürücü kopyaları, önceki depolama denemeleri ve üretilmiş yapılandırmalar da ayrı başlıklarla görünür. Bunların tamamını toplayıp benzersiz yeni kod miktarı olarak kullanmıyorum. Normal sürümde SFC için out/r241-normal altındaki 555 satırlık dosya kullanılıyor; eski 540 ve 547 satırlık kopyalar aynı sürücüye tekrar eklenmemeli.
Platform sürücüleri, hedef tanımları ve kernel yamaları openwrt/target/linux/zte/
Üretilmiş normal imaj paket yapılandırması — yeni kaynak kod toplamı değil out/r241-normal/
Kod:
openwrt-normal-packages.config — 3.898 satır
Upstream tabanlı derleme dosyaları — tamamı bana ait yeni kod değil openwrt/
Kod:
h3601p.config — 14 satır
openwrt/include/
Kod:
feeds.mk — 68 satır
openwrt/package/kernel/mt76/
Kod:
Makefile — 793 satır
openwrt/target/linux/generic/
Kod:
config-6.18 — 8.269 satır
Upstream tabanlı üç dosyanın sabit OpenWrt commit’ine göre gerçek farkı: feeds.mk +5/-10, mt76 Makefile +1/-0, generic config-6.18 +4/-2. Büyük dosyaların tüm uzunluğunu yeni kod saymadım.
Güncel ekran görüntüleri
1. Sistem durumu
Kernel 6.18.44, çift Cortex-A9 bilgisi ve 167 MiB depolama LuCI'de görünüyor. Bu görüntüyü aldığımda cihazın çalışma süresi 11 saati geçmişti.
2. LAN / WAN arayüzleri
OpenWrt üzerinden yönetilen ağ arayüzleri ve trafik sayaçları.
3. Kablosuz ağ
İki radyo, bağlı istemci ve 80 MHz bağlantının o andaki PHY hızları. MAC/BSSID değerlerini paylaşım için kapattım.
Register adreslerini, bootloader başlığını, NAND yerleşimini ve hangi sürücünün ne yaptığını daha ayrıntılı okumak isteyenler için proje adresi: github.com/wmemcmp/h3601p
Bu, H3601P için hazırladığım bağımsız bir port; resmî OpenWrt cihaz imajı değil. Şu anki sonuç kendi cihazımdaki testlerime dayanıyor. Başka bir donanım revizyonunda deneyecek olanların özellikle NAND yedeğini ve kurtarma yolunu hazırlaması gerekir.
