logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Jak skompilować i uruchomić własny firmware dla ALI M3801 i innych układów z tunerów?

p.kaczmarek2 08 Gru 2025 10:37 3588 45

TL;DR LABEL_AI_GENERATED

  • Minimalistyczne demo firmware dla ALI M3801 w tunerze Comsat TE 1050 HD uruchamia „Hello World” na UART i stanowi bazę do dalszego rozwoju.
  • Kompilacja działała tylko na Ubuntu z własnym toolchainem zbudowanym przez crosstool-NG, a obsługę GPIO dopisano przez analizę rejestrów i skan przycisków.
  • Odczyt identyfikatora układu zwrócił 0x3811, choć sprzęt ma ALI M3801, więc możliwa jest wewnętrzna rewizja chipu.
  • UART sprawia problemy: CH341 nie radzi sobie poprawnie z bitem parzystości even, a blokujący odczyt gubi znaki i wymaga przejścia na przerwania.
Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
Słuchaj:
  • #31 21803405
    p.kaczmarek2
    Moderator Smart Home
    Posty: 14794
    Pomógł: 659
    Ocena: 12943
    A nie wystarczy dać nagłówka tak jak w moim iterate.cpp? CRC już możemy policzyć. Mówię o partycji maincode. Muszę sprawdzić dekompilatorem mips, czy po tym nagłówku są normalnie rozkazy.
    Pomogłem? Kup mi kawę.
  • #32 21803726
    maciej_333
    Poziom 38  
    Posty: 4249
    Pomógł: 488
    Ocena: 1609
    Należałoby jeszcze wiedzieć gdzie do RAM bootloader ładuje aplikację z tych partycji we flash. Jakby to wiedzieć, to wystarczy w SDK zmienić adres pod jakim jest kod i może dodać tylko stosowny nagłówek. CRC faktycznie już wiemy jak liczyć. Aplikacja nie jest skompresowana?
  • #33 21804202
    p.kaczmarek2
    Moderator Smart Home
    Posty: 14794
    Pomógł: 659
    Ocena: 12943
    Masz na myśli fragment z un7zip?
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Na razie nie udało mi się odtworzyć tego u mnie w programie C. Znalazłem jeszcze natomiast inny trop - funkcja test_rsa_ram

    Added after 11 [minutes]:

    Tu jest użyty biblioteka LZMA: https://github.com/erwinbsbqq/PDK_GoDroid/blo...65fd0ff291e9a3263f95/uboot/lib/lzma/LzmaDec.c
    Pomogłem? Kup mi kawę.
  • #34 21812801
    p.kaczmarek2
    Moderator Smart Home
    Posty: 14794
    Pomógł: 659
    Ocena: 12943
    @maciej_333 jakieś postępy?

    Z mojej strony składam emulator dla Ali, mój Hello World bin już wyświetla tekst:
    Konsola terminala z logami emulatora i błędem odczytu pamięci
    Najpierw przez hook printf a potem normalnie już - odczytując z rejestru do wysyłania przez UART.

    Udało mi się też przejść pierwszy bootloader, pseudokod C:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Kopiuje on dane do pamięci RAM o adresie 81e8e170 i potem wykonuje tam funkcje:
    Zrzut ekranu z emulatora MIPS pokazujący pomyślną modyfikację pamięci
    Niby korzystam z gotowego silnika CPU ale on ma dużo popsute i muszę ręcznie obsługiwać instrukcje:
    Fragment kodu Pythona obsługującego instrukcje ładowania MIPS w emulatorze

    Nie wiem na ile to będzie funkcjonalne, czas pokaże.
    Pomogłem? Kup mi kawę.
  • #35 21812810
    maciej_333
    Poziom 38  
    Posty: 4249
    Pomógł: 488
    Ocena: 1609
    p.kaczmarek2 napisał:
    Masz na myśli fragment z un7zip?

    Tak, o tym właśnie myślałem.

    p.kaczmarek2 napisał:
    @maciej_333 jakieś postępy?

    Niestety nie zajmowałem się tym od tamtego czasu.

    Gratuluję dużych postępów w pracach nad Ali.
  • #36 21812926
    p.kaczmarek2
    Moderator Smart Home
    Posty: 14794
    Pomógł: 659
    Ocena: 12943
    Próbowałem jeszcze wtedy przekopiować te unzip do mojego projektu i wywołać na zrzucie pamięci flash, ale nie działało.

    Co do prób robienia emulatora, to napotkałem na kolejną niespodziankę. Tu są mieszane komendy 32 i 16 bitowe. Np:
    Zrzut ekranu z deasemblowanego kodu z mieszanymi instrukcjami 16- i 32-bitowymi
    A chwilkę później:
    Zrzut ekranu z deasemblowanego kodu MIPS z mieszanymi instrukcjami 16- i 32-bitowymi
    Pomogłem? Kup mi kawę.
  • #37 21932968
    JacekTorun
    Poziom 18  
    Posty: 244
    Pomógł: 7
    Ocena: 34
    Dzień dobry.
    Czy mógłbym prosić o podzielenie się skompilowanym bootem w wersji binarnej?

    Mam dekoder globo z procesorem ALI3801 i chciałem zrobić na nim kilka testów.
    Najważniejszą częścią testu będzie próba odpalenia małego kawałka programu z innego dekodera. (jakiś loader) Na oryginalnym sprzęcie nie wyświetla się log z tego loadera, a widać w plikach, że powinny, więc chcę sprawdzić czy tu się coś wyświetli.
    Jeśli jest komenda go xxxxx, to sprawdzę. Jak nie ma, to się tym pobawię.
  • #38 21932983
    maciej_333
    Poziom 38  
    Posty: 4249
    Pomógł: 488
    Ocena: 1609
    JacekTorun napisał:
    Jeśli jest komenda go xxxxx, to sprawdzę. Jak nie ma, to się tym pobawię.

    Nie ma czegoś takiego. Tu jest bardzo prymitywna konsola UART. Jednak jakieś komendy są i nawet udało mi się to rozpracować. Takie luksusy jak modyfikacja pamięci RAM przez UART, help, opis komend i go są na Mstar np. dla MSD7818.

    Odnośnie skompilowanego kodu jest w tym poście: >>21797094 . Obraz ten zrobił kolega @p.kaczmarek2 . Zastępuje to oryginalny bootloader i nawet działa, ale słabo. Można to wgrać przez UART: >>21797468 .

    Z kolei, jeżeli potrzebujesz całego obrazu flash, to jest tutaj.
  • #39 21932991
    p.kaczmarek2
    Moderator Smart Home
    Posty: 14794
    Pomógł: 659
    Ocena: 12943
    @JacekTorun daj znać o rezultatach. Czy masz może kopię oryginalną wsadu ze swojego tunera? Od jakiegoś czasu męczę emulator dla ALI i mi by się przydało do testów.
    Pomogłem? Kup mi kawę.
  • #40 21933067
    JacekTorun
    Poziom 18  
    Posty: 244
    Pomógł: 7
    Ocena: 34
    Dopiero zaczynam testy i na początek jak zwykle mam problem z komunikacją.
    Hyperterminal nie pokazuje logu. na cccc reaguje.
    Inny program pokazał log ze startu dekodera:
    APP init!
    bl_panel_init!
    bl_flash_init!
    bl_verify_sw
    success!
    MC: APP init ok
    << SDK4.0ba.4.0_20101217 >>
    Libcore version 8.13.0(_at_)SDK4.0bd.8.13_20130731(gcc version 3.4.4 mipssde-6.06.01-20070420)(Vic.Wang@ Thu Aug 1 15:38:18 2013)
    Application version 1.0.0(_at_)SDK4.0ba.7.4_20120227


    Odczyt pamięci mam i załączam.

    Pamięć mam wylutowaną, wstawiłem podstawkę i pamięć na osobnej płytce, żeby łatwo i szybko programować ją zewnętrznie. Mam kilka pomysłów co sprawdzić i dam znać jak pójdzie.
    (Dekoder z procesorem MSD7818 też mam i planuję sprawdzić czy globo ruszy na boocie z tamtego dekodera.)
    Załączniki:
    • Ali_3801_Globo_DVBT_dump SPI 4mb.bin (4 MB) Musisz być zalogowany, aby pobrać ten załącznik.
  • #41 21933125
    JacekTorun
    Poziom 18  
    Posty: 244
    Pomógł: 7
    Ocena: 34
    p.kaczmarek2 napisał:
    daj znać o rezultatach.


    1. Log w hyperterminalu już działa, miałem źle ustawioną parzystość.
    2. Wsad do dekodera z procesorem MSD7818, (też Mipsel), nie rusza. albo raczej nie daje żadnych oznak życia, bo nie wiem czy próbuje ruszyć, czy już na sprawdzeniu CHIP-ID kończy próbę uruchomienia. (RAM jest w tych dekoderach inny, i pewnie nie tylko.)
    3. Mini boot testowy wgrałem, sprawdziłem i w logu widzę tylko serię UP UP UP.
    Pozostała część tego co powinno się pokazać, w tym globo z procesorem ALI3801, nie działa. Ale ważna, że widać, że coś działa.
    Może procesor czymś się jednak różni.
  • #42 21934390
    JacekTorun
    Poziom 18  
    Posty: 244
    Pomógł: 7
    Ocena: 34
    Mini boot udało mi się odpalić, ale sposobem.

    Najpierw start na sofcie oryginalnym i podmiana wsadu pamięci na boot i po resecie boot pokazywał log,

    Po komendzie reboot, mini boot ruszył, ale resetował się w koło po odczytaniu ID procesora. Zrobiłem szybki reset zasilaniem i ruszył tak jak trzeba, ale udało się tylko jeden raz, bo przerwa w zasilaniu musi być prawie zerowa. Albo muszę dodać przycisk do resetowania dekodera bez zaniku zasilania.

    Log:
    APP init!
    bl_panel_init!
    bl_flash_init!
    bl_verify_sw
    success!
    MC: APP init ok

    << SDK4.0ba.4.0_20101217 >>
    Libcore version 8.13.0(_at_)SDK4.0bd.8.13_20130731(gcc version 3.4.4 mipssde-6.06.01-20070420)(Vic.Wang@ Thu Aug 1 15:38:18 2013)
    Application version 1.0.0(_at_)SDK4.0ba.7.4_20120227

    CCCCCCCCCCCCC: Unknown command!
    >help
    DELETE TOUCH READ RCU FLAG PWMGPIO MAINCODE CHANNELS VERSION CLS HEAP SENDMSG HMSG TIME GPIOCONFIG ADDDUMMY HELP EXIT REBOOT
    >reboot
    Rebooting...

    Booting...
    Main function

    stack end: 82000000

    stack start: 82008000

    heap start: 8100093c

    heap end: 8100893c

    cause: 10000000

    x: 1.230000 y: 1.250000

    result: 25.729999

    cause: 10000000

    chip id raw: 3811

    Booting...

    Po drugim resecie ruszył dobrze.

    Booting...
    Main function

    stack end: 82000000

    stack start: 82008000

    heap start: 8100093c

    heap end: 8100893c

    cause: a0000008

    x: 1.230000 y: 1.250000

    result: 25.729999

    cause: a0000008

    chip id raw: 3811
    UP

    Pin 9 is now UP!
    UP

    Pin 13 is now UP!
    UP

    Pin 14 is now UP!
    UP

    Pin 21 is now UP!
    UP

    Pin 23 is now UP!
    UP

    Pin 24 is now UP!
    UP

    Pin 25 is now UP!
    UP

    Pin 26 is now UP!
    UP

    A normalnie uruchamia się tak:
    UP
    UP
    UP
    UP
    UP
    UP
    UP

    Ewidentnie brakuje jakiegoś wpisu w konfiguracji Uart, że nie wyświetla danych.
    Ciekawe, że napisy UP pokazuje. A zamiast innych danych, są chyba tylko zera, bo te napisy UP wypadają w połowie linii, więc jakieś dane tam jakby lecą, ale ich nie widać.
    Logowałem binarnie i też ich nie widać. Może inna prędkość transmisji danych się ustawia?.

    add.

    Przez przypadek odkryłem co zrobić, żeby pokazywał się log z mini uboota.
    Przytrzymałem enter i włączyłem wtyczkę zasilania. Wtedy log z mini boota się wyświetlił. Tylko nie mam jeszcze echa przy wpisaniu czegokolwiek z klawiatury.
    Test robię starym komputerem i on dobrze działał z wieloma dekoderami, a tu jest jakiś problem.
    Sprawdzałem jeszcze programem do logowania w bin (np. log karty) i też nie pokazywał logu, więc dekoder go nie wysyłał. To nie jest problem tylko z odbiorem danych, bo jednak po sofcie oryginalnym log był.
    (Echo nadal nie działa.)
  • #43 21938303
    JacekTorun
    Poziom 18  
    Posty: 244
    Pomógł: 7
    Ocena: 34
    Dzień dobry.
    Uboot dla procesorów ALI będzie ciekawym narzędziem do napraw dekoderów, tylko niestety jest problem z komunikacją przez UART.

    Kupiłem drugi dekoder żeby sprawdzić, czy to wina ustawień procesora i chyba jednak to nie to. Opiszę testy w punktach, żeby łatwiej było się połapać w problemie.
    1. Dekoder Globo N3 wyświetla napisy po uruchomieniu oryginalnego softu i po resecie i podmiana napięci z ubootem bez wyłączania zasilania. Czyli działa jeśli zostają jakieś wpisy w rejestrach.
    2. Dekoder Globo czasem napisy z uboota wyświetliły się jeśli przed właczeniem dekodera z ubootem, na klawiaturze komputera trzymałem enter, który wysyłał do dekodera Hyperterminal. Ta metoda działa rzadko i tylko na Globo. Na drugim dekoderze nie udało się ani razu.
    3. Dokupiłem dekoder cabletech 195 z tym samym procesorem. NIe ma on klawiszy na panelu dekodera. Na tym dekoderze nie ma testtoola. Odpalenie uboota po resecie nie wyświetla napisów innych niż UP.
    4. Sprawdziłem deasemblerem jak działa uboot i wychodzi na to że wyświetla on tylko napis UP, bo jest on wyświetlany komendą 0x2573. czyli %s.
    inne komendy 2566, 2578, 2561, które są używane nie wyświetlają.
    Obstawiam, że w rejestrach do których są zapisywane adresy danych do wyświetlenia, jest jakiś błąd. Jeśli soft oryginalny coś tam wpisze, to napis się wyświetla, a jak nie to nie.

    Napis UP jest wyświetlany trochę inaczej, bo zapis jest do rejestru nr2, nie do 0.
    ROM:AFC04FF0 C1 AF 02 3C 40 94 42 24 la $v0, aUp # "UP"
    ROM:AFC04FF8 03 00 00 10 b loc_AFC05008 # Branch Always
    ROM:AFC04FFC 00 00 00 00 nop
    ROM:AFC05000 # ---------------------------------------------------------------------------
    ROM:AFC05000
    ROM:AFC05000 loc_AFC05000: # CODE XREF: sub_AFC04E0C+1DCj
    ROM:AFC05000 C1 AF 02 3C 44 94 42 24 la $v0, aDown # "DOWN"
    ROM:AFC05008
    ROM:AFC05008 loc_AFC05008: # CODE XREF: sub_AFC04E0C+1ECj
    ROM:AFC05008 25 30 40 00 move $a2, $v0 <<<<<<<<<<<<<< Tu przepisanie adresu napisu UP do rejestru 2 i to się wyświetla, a dane z 0 tylko czasami.
    ROM:AFC0500C 18 00 C5 8F lw $a1, 0x70+var_58($fp) # Load Word
    ROM:AFC05010 C1 AF 02 3C lui $v0, 0xAFC1 # Load Upper Immediate
    ROM:AFC05014 4C 94 44 24 addiu $a0, $v0, (aPinDIsNowS - 0xAFC10000) # "Pin %d is now %s!\n\r"
    ROM:AFC05018 25 01 F0 0F jal sub_AFC00494 # Jump And Link
    ROM:AFC0501C 00 00 00 00 nop

    Można spróbować skopiować rejestr który otrzymuje podprogram do wyświatlania napisów gdzieś do RAM i porównać to co się zapisuje bez softu oryginalnego z tym co się zapisze po resecie..
    Nie potrafię tego teraz znaleźć. Za mało znam MIPS.

    5. Udało mi się uzyskać coś co można nazwać echem po wysłaniu danych.
    Jeśli po starcie nic nie dotykam to po kilku minutach naciśnięcie klawisza w górę powoduje wyświetlenie UP.
    Jeśli jednak po włączeniu nacisnę i przytrzymam jakiś znak na klawiaturze, około 10-20 sekund. To naciśnięcie klawisza na panelu już nie wyświetli napisu UP, ale "krzaczki w hex".
    To zapis z logera binarnego.
    FF E0 FF FF
    00 00 FF FF FF FF FF
    FF FF FF
    FF FF FF FF FF FF
    E0 FF FF
    FF FF FF FF FF FF
    C0 FF
    FF FF E0
    00 FF FF FF 00 00
    Ewidentnie wciśnięcie klawisza powoduje odpowiedź, ale już nie wyświetla napisu UP.


    Prosiłbym autora tematu o dodanie do uboota odczytu przy starcie rejestru procesora B8000000 wielkość może 0x100. Skoro wyświetlają się stany pinów PIO, to i można dać listę i niech odczyta te 40 pozycji. Adres odczyt można później zmienić hex edytorem i odczytać coś innego, czyli rejestr UART, czy I2c itp. Albo można zapisać dane z rejestrów wyświetlających napisy, do RAM i podmienić uboot na taki, który pokaże ten wynik i jakoś dojść do tego co jest problemem.
    Boot oryginalny sprawdza wersję sprzętu właśnie gdzieś pod B80000xx.
  • #44 21938823
    JacekTorun
    Poziom 18  
    Posty: 244
    Pomógł: 7
    Ocena: 34
    Mam pewien pomysł co może być przyczyną problemu.

    Może przy kompilacji trzeba wybrać inny typ procesora MIPS ?
    Używałem deasemblera i on nie rozumiał kilku komend które są użyte w programie. Może dekoder też tego nie rozumie i dlatego nie wypełnia rejestrów tak jak trzeba i później wszystko działa "losowo", a po restarcie z softu oryginalnego widać logi tak jak trzeba, bo soft oryginalny wpisał to co trzeba.
    Pamiętam, że około 20 lat temu program kompilowany na komputerach z procesorem Intel, nie chciał działać na AMD, bo intel dodał kilka nowych komend. Tu też może być podobni dość banalny problem.
  • #45 21938857
    maciej_333
    Poziom 38  
    Posty: 4249
    Pomógł: 488
    Ocena: 1609
    Z tego, co rozumiem, to pozostawiłeś oryginalny bootloader w pamięci flash. Z jakim zatem offsetem wgrałeś kod programu do flash? Masz ten sam kod, jaki tu jest, czy coś w nim zmieniałeś i to kompilowałeś? Skoro jest oryginalny bootloader (tak wygląda z logu), to przecież on powinien ustawić już całkiem sporo w rejestrach. Zatem aplikacja powinna jakoś tam działać.

    Też kiedy dekompilowałem w Ghidrze kod z MIPS (jednak Mstar), to część rozkazów mi nie rozpoznawało. W zasadzie producent mógł nawet dodać rozkazy jakiegoś swojego pomysłu. Tylko, że te standardowe z MIPS powinny działać i powinno to do wszystkiego wystarczyć. Przynajmniej na Mstar tak było. Zatem moim zdaniem to nie to, tylko coś jest źle w rejestrach.
  • #46 21939788
    JacekTorun
    Poziom 18  
    Posty: 244
    Pomógł: 7
    Ocena: 34
    Mogę zamienić program, bo mam pamięci w podstawkach i wkładam w dekoder inną pamięć i po resecie ruszy na innym boocie. (Zmieniam pamięć w czasie pracy dekodera. Może dorobię 2 pamięci na jednej płytce i zmiana tylko linii sterujących, ale na dziś są osobne pamięci na osobnych płytkach. załączam zdjęcie. Nie ma rewelacji, podstawka w dekoder wlutowana na drucikach, ale działa.)
    Jak skompilować i uruchomić własny firmware dla ALI M3801 i innych układów z tunerów?

    Boot oryginalny i ten testowy są przypisane do tego samego adresu AFC00000. Nie jestem w stanie go przesunąć.
    Przy testach zmieniałem tylko kombinacje znaków %d, %s, %x, i %, a, b, f, żeby zobaczyć co działa a co nie działa.
    Wpis jako %s działa, a udało mi się też wyświetlić coś binarnego (4F0101), ale wpisałem wtedy kilka nowych komend i nie wiem czy to był odczyt z adresów B8xxxxxx, czy coś losowego.
    Poza dopisaniem kilku wyświetlań nic nie zmieniałem.

    https://obrazki.elektroda.pl/6393353600_1784226089.jpg
Słuchaj:

Podsumowanie tematu

LABEL_AI_GENERATED
Dyskusja dotyczy uruchamiania własnego, minimalistycznego firmware dla procesorów ALI M3801/M3801A z tunerów DVB oraz budowy prostego środowiska do kompilacji i wgrywania kodu przez UART. Opisano start od projektu ali_sdk na Ubuntu, problemy z kompilacją pod Cygwin i WSL, a także użycie programatora CH341 i odczytu/zapisu pamięci flash. W kolejnych etapach rozpracowano fabryczny bootloader: zatrzymanie startu przez wysłanie „c”, wejście w konsolę ASH, komendy comtest, address, transfer, dump i burn, format pakietów 1024 B + CRC oraz sposób zapisu obrazu do flash. Dużo uwagi poświęcono obliczaniu CRC, endianess, formatowi nagłówka partycji maincode, lokalizacji skoku bootloadera do aplikacji oraz możliwości uruchamiania programu z offsetu zamiast nadpisywania bootloadera. Pojawiły się też testy z LabVIEW jako narzędziem do automatyzacji komunikacji UART i zapisu flash, a także analiza układów pokrewnych z tunerów, takich jak M3100/M3101, MxL5007T i AV2012, oraz próby budowy emulatora i odtworzenia działania bootloadera.
Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
REKLAMA