Z openwrt się chwilowo poddaje, pytanie z innej beczki. Czy jest możliwość zmiany koloru led w aktualnym firmwarze? Szukałem katalogu z ledami, w openwrt jest ścieżka ładna, ale tutaj niestety brak. Te diody są 2 stanowe, stan niski świecą na czerwono, stan wysoki na zielono. Podczas wciśnięcia przycisku wps dioda miga czerwono zielono. Mnie interesowałby kolor czerwony. Będzie z tym problem?

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ć.

Będę próbował, ale najpierw muszę znaleźć jak wyedytowć ten plik w tym busybox.

Idąc tym tropem znalazłem plik dgtioctl Niestety, ale zawartość wygląda to prakytycznie same krzaki, chociaż widzę nazwy GPIO, więc już coś, może w hexedytorze coś wynajdę.

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.

Ok rozumiem.

Nowe wieści, udało mi się rozpakować ori firmware za pomocą firmware mod kit, tak samo z openwrt. Nie musiałem usuwać żadnych linijek w hexeditorze jak pod windowsem. Teraz spróbuję porównać co i jak i zobaczymy co z tego wyjdzie. Może się uda ruszyć w końcu openwrt.

Log z openwrt

Scan Time:     2014-01-05 23:07:50
Signatures:    193
Target File:   /home/xxx/Pulpit/fmk/openwrt.bin
MD5 Checksum:  01ecb2396ca003727c1010196cd753d9

DECIMAL       HEX           DESCRIPTION
-------------------------------------------------------------------------------------------------------
1179648       0x120000      Squashfs filesystem, little endian, version 4.0, compression:  size: 1757818 bytes,  622 inodes, blocksize: 262144 bytes, created: Sun Jan  5 02:17:15 2014 

config.log z openwrt

FW_SIZE='2949124'
HEADER_TYPE=''
HEADER_SIZE=''
HEADER_IMAGE_SIZE='1179648'
HEADER_IMAGE_OFFSET='0'
FOOTER_SIZE='96'
FOOTER_OFFSET='2949028'
FS_TYPE='squashfs'
FS_OFFSET='1179648'
FS_COMPRESSION='lzma'
FS_BLOCKSIZE='262144'
ENDIANESS='-le'
MKFS="./src/others/squashfs-4.2-official/mksquashfs"

log z dgt

Scan Time:     2014-01-05 23:09:48
Signatures:    193
Target File:   /home/xxx/Pulpit/fmk/bcm.1609.bin
MD5 Checksum:  e9bfeff7ae8ecd7b49e1d1e944e6cd58

DECIMAL       HEX           DESCRIPTION
-------------------------------------------------------------------------------------------------------
1024          0x400         Squashfs filesystem, little endian, non-standard signature,  version 4.0, compression:gzip, size: 10001068 bytes,  1225 inodes, blocksize: 65536 bytes, created: Wed Jul 18 16:33:34 2012 
10003468      0x98A40C      LZMA compressed data, properties: 0x6D, dictionary size: 4194304 bytes, uncompressed size: 4134144 bytes
10758211      0xA42843      Broadcom header, number of sections: 1160982971,

config.log z dgt

FW_SIZE='11393142'
HEADER_TYPE=''
HEADER_SIZE=''
HEADER_IMAGE_SIZE='1024'
HEADER_IMAGE_OFFSET='0'
FOOTER_SIZE='2736'
FOOTER_OFFSET='11390406'
FS_TYPE='squashfs'
FS_OFFSET='1024'
FS_COMPRESSION='gzip'
FS_BLOCKSIZE='65536'
ENDIANESS='-le'
MKFS="./src/others/squashfs-4.2/mksquashfs"

Spróbuję jeszcze z innym firmwarem od dgt i openwrt, żeby można było wykluczyć jakieś pomyłki.

Ok log z dgt stara wersja

Scan Time:     2014-01-05 23:58:40
Signatures:    193
Target File:   /home/xxx/Pulpit/fmk/bcm.old1.bin
MD5 Checksum:  825b8dbab3e498b71d46e6124ce8e327

DECIMAL       HEX           DESCRIPTION
-------------------------------------------------------------------------------------------------------
1024          0x400         Squashfs filesystem, little endian, non-standard signature,  version 4.0, compression:gzip, size: 8918004 bytes,  825 inodes, blocksize: 65536 bytes, created: Mon Oct 18 13:25:38 2010 
8922124       0x88240C      LZMA compressed data, properties: 0x6D, dictionary size: 4194304 bytes, uncompressed size: 3360340 bytes

config.log dgt

FW_SIZE='10042885'
HEADER_TYPE=''
HEADER_SIZE=''
HEADER_IMAGE_SIZE='1024'
HEADER_IMAGE_OFFSET='0'
FOOTER_SIZE='2720'
FOOTER_OFFSET='10040165'
FS_TYPE='squashfs'
FS_OFFSET='1024'
FS_COMPRESSION='gzip'
FS_BLOCKSIZE='65536'
ENDIANESS='-le'
MKFS="./src/others/squashfs-4.2/mksquashfs"

i openwrt inna wersja

Scan Time:     2014-01-06 00:06:19
Signatures:    193
Target File:   /home/xxx/Pulpit/fmk/openwrt.bin
MD5 Checksum:  b842725e933871669d2b1975dd31d3bc

DECIMAL       HEX           DESCRIPTION
-------------------------------------------------------------------------------------------------------
1179648       0x120000      Squashfs filesystem, little endian, version 4.0, compression:  size: 1757498 bytes,  618 inodes, blocksize: 262144 bytes, created: Tue Dec 17 19:37:02 2013

config.log

FW_SIZE='2949124'
HEADER_TYPE=''
HEADER_SIZE=''
HEADER_IMAGE_SIZE='1179648'
HEADER_IMAGE_OFFSET='0'
FOOTER_SIZE='96'
FOOTER_OFFSET='2949028'
FS_TYPE='squashfs'
FS_OFFSET='1179648'
FS_COMPRESSION='lzma'
FS_BLOCKSIZE='262144'
ENDIANESS='-le'
MKFS="./src/others/squashfs-4.2-official/mksquashfs"

Próbowałem rozpakowany firmware od dgt ponownie spakować, ale wywala

New firmware image will be larger than original image!
       Building firmware images larger than the original can brick your device!
       Try re-running with the -min option, or remove any unnecessary files.
       REFUSING to create new firmware image.

       Original file size: 11393142
       Current file size:  12493824 (plus footer of 2736 bytes)

       Quitting...

Nawet nie sprawdzam bo na bank nie ruszy. Coś inaczej chyba trzeba go spakować. Próbwałem z opcją -min, ale to samo. W przypadku openwrt to samo.

Udało mi się rozpakować i spakować ponownie firmware DGND3700_2013-12-20_A_D.chk, sprawdzałem w hexedytorze wsio się zgadza. Będę próbował dalej.

Co ciekawe w przypadku dgt header jest strasznie mały zajmuje ok 1kb, natomiast w openwrt waży ok 1mb.

Inna kolejność bajtów? sqsh jest dla cpu z big endian, hsqs jest dla little endian

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ąć?

Tyle to i ja wiem Pytanie tylko czy rootfs w dgt jest faktycznie skompresowany jako gzip i dlatego go przyjmuje a lzma nie rusza poprzez f, może jakby była komenda flash to by działało.

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.

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.

Bi nie zna. Albo sobie w bootloaderze zmień na coś co openwrt zna, albo sobie do kernela dorób nowe oznaczenie platformy.