działam na virtualboxie 4 jajowiec, no to ładnie sobie poczekam. Co z tym nvram?

Nie kompilowałem jeszcze jądra, ale zastanawia mnie jedno, Po zmianie board_id na 96368MVWG też wywala kernel panic, czy samo jądro wyciągnięte z sdk z trunka nie ma zdefiniowanych żadnych platform? W hexedytorze spradzwiłem ten kernel i kilka razy występuje nazwa 96863MVWG, ale nie wiadomo do czego się odnosi. Jeszcze jedna sprawa Dlaczego wywala mi kominikat o nvram tj.

[    0.000000] bcm63xx_nvram: nvram checksum failed, contents may be invalid (expected 00000000, got 189e4e90)
[    0.000000] board_bcm963xx: unknown bcm963xx board:

Czy nie jest przypadkiem właśnie tutaj problem? Skoro nie odczytuje NVRAm to nie wie jaka platforma jest i dlatego wywala kernel panic? Bo może kompilacja nic tu nie da skoro jest problem z odczytaniem nvram. Czy on nie ma nic do rzeczy?

No to czym mam skompilować jądro?

Dobra już wiem, SDK potrzebuję. Tylko widzę, że jest do 12.09. Sam toolchain nie wystarczy pewnie OpenWrt-Toolchain-brcm63xx-for-mips_mips32-gcc-4.6-linaro_uClibc-0.9.33.2.tar.bz2

Rozumiem, że jakbym dorobił to wtedy odpali sam kernel tak? Wtedy mógłbym wgrać openwrt sobie? W bootloaderze nie zmienię, ale dziwne, że nie zna platformy 96368MVWG.

Nvram bcm63xx_nvram: nvram checksum failed, contents may be invalid (expected 00000000, got 189e4e90) nie ma tutaj żadnego związku z kernel panic?

CFE sprawdza chyba tylko sam tag sumę CRC

Jak będę miał wolny czas to posiedzę nad tym jeszcze. Chociaż jestem początkujący w tym temacie
Rozgryzłem które wpisy odpowiadają za to gdzie szuka obrazu, kernela. Na samym początku się znajduje w tagu. Nie rozgryzłem jeszcze co oznaczają te wpisy co dałem wyżej. Są tylko w obrazach od dgt, w każdym i czy mają jakieś znaczenie.
A i doszedłem, że u mnie jest BigEndian, nawet w CFE na początku się wyświetla BE, a nie LE.

/***************************************************************************
 * Function Name: verifyTag
 * Description  : check on the input file by tag verification
 * Returns      : 0 - ok, -1 bad input image file
 ***************************************************************************/
int verifyTag(PFILE_TAG pTag)
{
    UINT32 crc;
    int status = 0;

    // check tag validate token first
    crc = CRC32_INIT_VALUE;
    crc = getCrc32((char*) pTag, (UINT32)TAG_LEN-TOKEN_LEN, crc);
    crc = htonl(crc);

    if (crc != (UINT32)(*(UINT32*)(pTag->tagValidationToken)))
    {
        printf("Illegal image ! Tag crc failed.\n");
        status = -1;
    }

    return status;
}

Znalazłem na https://github.com/guillaumelecerf/cfe_ … reateimg.c

Według tego wszystko się zgadza, ale do momentu tych krzaków, chyba dgt sobie własny system sprawdzania opracowało, nie wiem.

http://wiki.openwrt.org/doc/techref/brcm63xx.imagetag

Ktoś ma jakiś pomysł, co się kryje pod tym?

Co ciekawe mój bootloader też ma inaczej rozplanowany chociażby adres ip, serial itp. Prawie pod sam koniec i nie zajmuje 64kb tylko 132kb, a bez obcinania niezapisanego miejsca ( kończy się przed obrazem ) 256kb. A i jeszcze zauważyłem ciekawą rzecz, otóż obraz oczywiście jest taki sam po wgraniu na pamięć jak ten co się wrzuca, natomiast za obrazem jest niezapisana pamięć i dalej są jakieś bzdety bliżej nie określone. Podejrzewam, że to konfiguracja routera bo po flashu konfiguracja zostaje.

To muszę kombinować z tą kompresją,  żeby początek nagłówka był shsq to wtedy ruszy bo już mi zaczyna brakować pomysłów a na pomoc DGT nie ma co liczyć bo nawet na żadnego maila o ori firmware nie odpisali.

I jeszcze coś. Sprawdziłem jeszcze w 7zipie firmware od dgt po obcięciu nagłówka ( to co się daje wypakować ) i kompresja LZMA ZLIB
Bigendian-
System plików SquashFS-LZMA 4.0
Czyli dobrze pokazuje FMK, tylko skąd mu się ten gzip wziął. Zresztą firmware musi być spakowany skoro po rozpakowaniu zajmuje 34mb a po spakowaniu 9,50mb

Edit:

No wreszcie udało mi się spakować rootfs openwrt jak w oryginale! Co prawda w squashfs 3.1 ale początek jest shsq i można go otworzyć w 7zipie pod windą. Dodałem nagłówek na chama w hexedytorze, ale nie ruszyło. Próbuję dalej. Jutro zrobię mixa z firmwareami od dgt, dam nagłówek z jednego do drugiego i zobaczymy czy ruszy, jeżeli nie to znaczy, że nagłówek zawiera coś co blokuje wgranie firmwaru ( suma kontrolna crc? skoro wywala błąd Illegal image ! Image crc failed.) i może to nie o to shsq chodzi.

Exportable Little endian filesystem, data block size 65536, compressed data, compressed metadata, compressed fragments, duplicates are removed
lzmadic 65536

Jeszcze jedna sprawa, zmodyfikowałem jeden bit w firmwarze dgt, zmieniłem w nagłówku z 1 na 2 i zapisałem, rozmiar taki sam, nie przyjął, więc zmieniłem spowrotem z 2 na 1 i przyjął fimware. Wsadziłem jeszcze nagłówek z jednego firmware od dgt do drugiego, też nie przyjął. Chociaż wykrył najpierw invalid image format jak zmieniłem z 1 na 2, a ten drugi to obcięty nagłówek z jednego firmware i wklejony do 2 i co dziwne wywaliło to co widać, albo błąd po prostu. Firmware wrzucałem przez stronę cfe.

CFE> 
web info: Upload 11393142 bytes, invalid image format.

CFE> 
web info: Waiting for connection on socket 0.

CFE> 
web info: Waiting for connection on socket 1.

CFE> 
web info: Upload 11393142 bytes, Broadcom image format.

CFE>  Illegal image ! Image crc failed.

Resetting board...˙

zmiana z 2 na 1 jak w ori i przyjął.

CFE> 
web info: Upload 11393142 bytes, Broadcom image format.

CFE> 
Flashing root file system and kernel at 0xb8040000: .......................................................................................

.
*** Image flash done *** !

To oznacza, że w tym przypadku nie chodzi o kompresje tylko w nagłówku jest zaszyta jakaś suma którą najpierw sprawdza, żeby to ruszyło dalej. Sprawdza wielkość pliku i coś jeszcze. wydaje mi się, że to o to chodzi, ale jak to rozszyfrować.

{íĎáŃů .ŞÓjÂ.ŹËăŻÔÁøb»nY.Ăř%._‰,‰ďŮ0¤Á‰4Xś.«Ř`GÄŔ.ü{ĽĎ4$[`2[ Ć6\/ŕ2çn0.ÄxâMŕ„ń..đńű`â˙,¤:§.6şt"ü”nP%>9Ű<9ŐkK_XŁÂq•,Bh<}ěx‚Tŕ_)[o‡égAµÖ2W‡eŠ^EÔ®.Xů~¸G|đ´Słé.®šf+í€?tń”›¸.úW±.üPR˛ĹOă~«.ňÉ!TáͲđH2Ü}l©3ă6ć}żŞ4AÚyżrV…7˛H-b.@.°@MŐj8Ur.d®.ëĘPç.9.Ű.ë?ýλšđá·–1Öö0759.;0730.;0776. 

i końcówka przed rootfs

úO&.ą–¦%ħńq.........Á]¤

No cóż muszę dalej szukać i czytać.

Stwierdziłem, że nie będę się bawił w edycję hexeditorem, znalazłem coś takiego bcm963xx_4.06L.03_consumer_release.tar.gz Zobaczymy co tam ciekawego jest, tym bardziej, że firmware 2 pierwsze dostali od Broadcoma z tego co sami napisali w pliku, więc musieli mieć sdk, zobaczymy co z tego wyjdzie.

Z ciekawości przeglądam sobie pdf odnośnie cfe od broadcoma. Znalazłem na necie coś co mnie zastanawia. Otóż u mnie nie ma komendy flashimage jest tylko f a to nie to samo
Przykład z innego cfe

Czyli ten firmware od dgt nie jest skompresowany? skoro daje się wypakować przez 7zipa po usunięciu nagłówka?
Jutro zrobię chyba kabel do jtaga i zgram na wszelki wypade bootloader.
I jeszcze sprawa po wypakowaniu firmware`u od dgt w logu pojawia się info o kompresji gzip? W openwrt tego nie ma.

dgt

Nie wierzę, że tylko w tym routerze jest problem z wgraniem openwrt. Nikt się nie spotkał z podobnym problemem? Najłatwiej byłoby wgrać inny bootloader, ale skąd taki wziąć?

Doszedłem mniej więcej do tego, że być może problem leży w kompresji. Po rozpakowaniu firmwaru od dgt początek rootfs w hex edytorze to shsq9 ( w każdym firmwarze) można go 7zipem spokojnie rozpakować, natomiast w przypadku openwrt to hsqs i jego 7zipem nie da rady. Następnie po spakowaniu ori firmwaru od dgt FMK wychodzi większy rozmiar i co ciekawe  już jest spakowany inaczej bo początek rootfs to hsqs jak w przypadku openwrt. 7zip nie daje rady wypakowac rootfs. Oczywiście squashfs-4.2-official daje sobie radę z obydwoma. Następnie bawiłem się próbując odpalić zmodowany firmware czyli nagłówek z dgt + rootfs z openwrt spakowany FMK, ale nie ruszył komunikat jak wcześniej. Próbowałem jeszcze odpalić poprzez komendę r i co ciekawe to rootfs z openwrt niby zdekompresował, ale dalej nic.
odpalenie samego rootfs.img po wypakowaniu FMK. Sam rootfs.img zarówno od dgt jak i openwrt utworzony przy pomocy FMK też nie idzie przy komendzie r. Natomiast co ciekawe po spakowaniu wypakowanego rootfs 7zipem nie całego na dodatek, chodzi o sam początek bo pod windą nie da rady tego spakować niby dekompresuje co pokazałem niżej.

 CFE> r rootfs.img
Retry loading it as a compressed image.
Loading 192.168.1.100:rootfs.img ...
Finished loading 11392118 bytes
Code Address: 0x73687371, Entry Address: 0xc9040000
LZMA: Prossible old LZMA format, trying to decompress..
**Exception 8: EPC=806132B8, Cause=000005EA (Exc26    )
                RA=8073D5D8, VAddr=00000000

        0  ($00) = 8061EFB0     AT ($01) = 8073D2F4
        v0 ($02) = 806135AC     v1 ($03) = 80800011
        a0 ($04) = 73687371     a1 ($05) = 80800011

i tak byle jak spakowany rootfs od openwrt po wypakowaniu fmk i spakowaniu jako zip jak widać niby go przyjmuje

r rootfs.zip
Retry loading it as a compressed image.
Loading 192.168.1.100:rootfs.zip ...
Finished loading 2404514 bytes
Code Address: 0x504B0304, Entry Address: 0x14000000
Decompression OK!
Entry at 0x14000000
Closing network.
Disabling Switch ports.
Flushing Receive Buffers...
0 buffers found.
Closing DMA Channels.
Starting program at 0x14000000
**Exception 8: EPC=8061EFB0, Cause=806210BC (FPUExc   )
                RA=20323430, VAddr=8073D313

        0  ($00) = 14000000     AT ($01) = 80611BCC
        v0 ($02) = 00000000     v1 ($03) = 14000000
        a0 ($04) = 53746172     a1 ($05) = 2070726F

W oryginalne boot wygląda tak

Booting from latest image (0xb9000000) ...
Code Address: 0x80010000, Entry Address: 0x80014230
Decompression OK!
Entry at 0x80014230
Closing network.
Disabling Switch ports.
Flushing Receive Buffers...
0 buffers found.
Closing DMA Channels.
Starting program at 0x80014230
Linux version 2.6.30 (krom@krom) (gcc version 4.4.2 (Buildroot 2010.02-git) ) #2 Mon Oct 18 13:10:16 CEST 2010

Parallel flash device: name AM29LV320MT

i nowsza wersja fw

CFE> r
Booting from latest image (0xb9000000) ...
Code Address: 0x80010000, Entry Address: 0x803127f0
Decompression OK!
Entry at 0x803127f0
Closing network.
Disabling Switch ports.
Flushing Receive Buffers...
0 buffers found.
Closing DMA Channels.
Starting program at 0x803127f0
Linux version 2.6.30 (krom@krom) (gcc version 4.4.2 (Buildroot 2010.02-git) ) #1 SMP PREEMPT Wed Jul 18 16:15:00 CEST 2012

Parallel flash device: name AM29LV320MT

Gdyby udało mi się spakować ten firmware jak w oryginale tzn żeby początek był shqs a nie hsqs to może go przyjmie. Aktualnie nic z tego jak widać.  Chyba, że to chodzi jeszcze o coś innego. Jakieś pomysły? Bo być może problem jednak leży gdzie indziej.

Właśnie zacząłem sprawdzać te polecenia i dająć dgtioctl clr 22;sleep 1 zgasła dioda power dająć dgtioctl set 22;sleep 1 zapaliła się. Próbuję dalej

Haha udało mi się zapalić czerwoną diodę od power. Zaraz zrobię podsumowanie co i jak działa Nawet można tymi poleceniami rozjaśniać te diody.

Ok tak na szybko to co mi się udało:

dgtioctl clr 2 od adsl zapala zieloną/ set ją gasi
dgtioctl clr 5 zapala czerwoną od internetu /set zapala poprzednią
dgtioctl clr 10 zapala zieloną od voip ( podniesiona słuchawka) /set gasi
dgtioctl set 22 zapala pomarańczową diodę od power/ clr zapala poprzednią
dgtioctl set 23 zapala czerwoną od wifi / clr zapala zieloną
dgtioctl set 24 też zapala czerwoną od power / polecenie  clr zapala zieloną 
dgtioctl clr 26 zapala zieloną od voip/ set ją gasi
dgtioctl set 31 zapala pomarańczową od internetu / clr zapala zieloną

dgtioctl clr 34 przycisk reset, nie używać

Trzeba to teraz dodać do firmwaru, żeby się tak odpalały przy restarcie. Może z tym rc.test. leds trzeba pokombinować? Zmienić tylko board na moją i zobaczyć lub jakiś skrypt, który po uruchomieniu je odpali.

Zaraz, zaraz, ale jakie polecenie to co jest w tych skryptach? dgtioctl set 4;sleep 1 itp? Kilka próbowałem i nic. Dzisiaj coś mi głowa nie pracuje.

Znalazłem tylko 2 pliki powiązane bezpośrednio z ledami, nie wiem na ile są potrzebne. Są to rc.led_test1 i rc.led_test2
ich zawartość. Jednak to raczej nie to. Nie bardzo wiem jak szukać i pod jakimi nazwami.

#!/bin/sh

SERIAL=`cat /proc/nvram/DGTserial`
BOARD=`awk '// {print substr($1,1,4) }' /proc/nvram/DGTserial`

if [ "$BOARD" = "0776" ];then
dgtioctl clr 22
dgtioctl clr 24
dgtioctl set 2
dgtioctl set 4
dgtioctl set 11
dgtioctl clr 5
dgtioctl clr 31
dgtioctl set 25
dgtioctl set 21
dgtioctl set 14
dgtioctl set 26
dgtioctl set 27
dgtioctl set 12
sleep 1

dgtioctl set 22
dgtioctl set 24
dgtioctl clr 2
dgtioctl clr 4
dgtioctl clr 11
dgtioctl set 5
dgtioctl set 31
dgtioctl clr 25
dgtioctl clr 21
dgtioctl clr 14
dgtioctl clr 26
dgtioctl clr 27
dgtioctl clr 12
fi

#!/bin/sh

SERIAL=`cat /proc/nvram/DGTserial`
BOARD=`awk '// {print substr($1,1,4) }' /proc/nvram/DGTserial`

if [ "$BOARD" = "0776" ];then
dgtioctl clr 22;sleep 1
dgtioctl clr 24;sleep 1
dgtioctl set 2;sleep 1
dgtioctl set 4;sleep 1
dgtioctl set 11;sleep 1
dgtioctl clr 5;sleep 1
dgtioctl clr 31;sleep 1
dgtioctl set 25;sleep 1
dgtioctl set 21;sleep 1
dgtioctl set 14;sleep 1
dgtioctl set 26;sleep 1
dgtioctl set 27;sleep 1
dgtioctl set 12;sleep 1

dgtioctl set 22;sleep 1
dgtioctl set 24;sleep 1
dgtioctl clr 2;sleep 1
dgtioctl clr 4;sleep 1
dgtioctl clr 11;sleep 1
dgtioctl set 5;sleep 1
dgtioctl set 31;sleep 1
dgtioctl clr 25;sleep 1
dgtioctl clr 21;sleep 1
dgtioctl clr 14;sleep 1
dgtioctl clr 26;sleep 1
dgtioctl clr 27;sleep 1
dgtioctl clr 12;sleep 1
fi

Co zauważyłem, przy zmianie board id np na ten 96368 dioda od wifi jest czerwona, ale wifi działa, czyli jakby nie było to skonfigurowane i jakby jej nie widział firmware wtedy. Ogólnie to ten CFE jest okrojony, nawet nie można zmienić mac adresu na inny ( w sensie inny producent niż dgt bo wywala info ).
Jeszcze znalazłem jakiś plik ledctl, ale on chyba nie ma tu nic do gadania.

Z tymi ledami to chyba łatwiej będzie kupić niebiesko czerwone i wlutować niż się z tym bawić.

W sumie nie. Ja swoje przykleiłem na klej termoprzewodzący, który jest mega mocny i teraz bez podgrzania suszarką się nie obejdzie :E