Marek <f...@f...com> napisał(a):
> To wiem, ale czy kod stosu tcpip jest linkowany za każdym razem z usercode
> i tak całość flashowana czy usercode jest osobno flashowany?

Jest linkowany razem.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 30.10.2018 11:52, cezar wrote:

> Jeszcze jedna zabawka, którą się bawiłem i działa wyśmienicie:
>
> https://labs.mediatek.com/en/chipset/MT7688#HDK

Znam. Całkiem fajnym modułem tego rodzaju jest też Onion Omega (z tym,
że posiada złącze w mniejszym rastrze, niekompatybilne z płytkami
stykowymi). Przy czym jednak tego typu płytki nie zawsze są sensowną
alternatywą dla mikrokontrolera z modułem WiFi (tudzież modułu WiFi ze
zintegrowanym mikrokontrolerem). Czasem ważne jest to, żeby układ po
resecie podniósł się jak najszybciej, bez potrzeby uruchamiania systemu
operacyjnego.

do góry

Atlantis <m...@w...pl> napisał(a):
> Pierwsze pytanie, a raczej wątpliwość: czy stosowane przeze mnie
> biblioteki (przede wszystkim ta do serwera http) będą zgodne z
> alternatywnym SDK?

To alternatywne bazuje w dużym stopniu na oficjalnym więc ewentualne
przeportowanie nie powinno być trudne.

> Po drugie, czy ta modyfikacja dotyczy tylko kodu użytkownika? Bo z tego
> co widzę, to u mnie głównym źródłem problemu są biblioteki z SDK, które
> linker umieszcza w RAM-ie.

Dotyczy kodu użytkownika, bo brane są oryginalne skrypty linkera. Nie bałbym
się jednak tych skryptów edytować ani tym bardziej z ich względu zmieniać w
ogóle platformę :) Jako przykład wziąłem ten projekt:
https://github.com/QB4-dev/esp_nano_httpd_basic_exam
ple Po kompilacji
sprawdzam rozmiar sekcji:
.irom0.text 203076 1075908608
.text 25796 1074790400
Nie jest źle, większość poszła do Flasha. Jednak IRAM jest w większości
zapełniony i trzeba coś z tym zrobić. Komendą readelf sprawdzam co poszło do
IRAMu. Okazuje się, że mnóstwo znajdujących się tam funkcji pochodzi z
biblioteki libpp. Trzeba by ją przenieść do Flasha. Zaglądam do skryptu
linkera (eagle.app.v6.old.1024.app1.ld) i widzę, że są już tam linijki
przenoszące niektóre biblioteki do sekcji irom0.text. Dodałem więc
analogiczną linijkę dla libpp:
*libpp.a:(.literal.* .text.*)
Niestety nic to nie dało. Szybkie googlanie podpowiedziało, że trzeba
przenieść też sekcje bez kropki w środku nazwy. Dopisana linijka będzie więc
miała postać:
*libpp.a:(.literal.* .text .literal .text.*)
Rekompilacja i... sukces!
.irom0.text 218020 1075908608
.text 10628 1074790400
Zaoszczędzone 15 kB :) Google podpowiada, że mozna jeszcze przenieść libm.
Wtedy mamy:
.irom0.text 223188 1075908608
.text 3496 1074790400
Jeszcze lepiej, zużyte tylko nieco ponad 10% IRAMu a prawie wszystko mamy we
Flashu. Wystarczyło dopisać dwie linijki. I pewnie obejdzie sę bez zmiany
SDK. Być może właśnie na te modyfikacje skryptu linkera natrafiałeś.
A jeśli nie chcesz modyfikować skryptu linkera, to możesz zrobić z drugiej
strony: zmodyfikować bibliotekę zmieniając w niej nazwy sekcji. Mozna to
zrobić komendą objcopy:
xtensa-lx106-elf-objcopy --rename-section .text=.irom0.text --rename-section
.literal=.irom0.literal libpp.a

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 31.10.2018 14:20, Grzegorz Niemirowski wrote:

> Niestety nic to nie dało. Szybkie googlanie podpowiedziało, że trzeba
> przenieść też sekcje bez kropki w środku nazwy. Dopisana linijka będzie
> więc miała postać:
> *libpp.a:(.literal.* .text .literal .text.*)

Gdzie dokładnie trzeba umieścić tę linijkę?
Modyfikuję skrypt eagle.app.v6.ld, używany w moim projekcie.

Zmodyfikowany fragment wygląda następująco:

.irom0.text : ALIGN(4)
{
_irom0_text_start = ABSOLUTE(.);

*libmbedtls.a:(.literal .text .literal.* .text.*)
*libpp.a:(.literal.* .text .literal .text.*)
*libm.a:(.literal.* .text .literal .text.*)

*(.irom0.literal .irom.literal .irom.text.literal .irom0.text
.irom.text)
_irom0_text_end = ABSOLUTE(.);
} >irom0_0_seg :irom0_0_phdr

Niestety nie pomogło - projekt ciągle nie chce się kompilować,
wyrzucając te same błędy...

do góry

Atlantis <m...@w...pl> napisał(a):
> Gdzie dokładnie trzeba umieścić tę linijkę?

W definicji sekcji .irom0.text, tak jak zrobiłeś, bo chcemy aby objęła
większy fragment linkowanego kodu.

> Modyfikuję skrypt eagle.app.v6.ld, używany w moim projekcie.

Na pewno ten? Poza tym tutaj ta sekcja jest dużo dłuższa:
https://github.com/espressif/ESP8266_NONOS_SDK/blob/
master/ld/eagle.app.v6.ld
Możesz puścić make VERBOSE=1 i wkleić linijkę od linkowania?

> Zmodyfikowany fragment wygląda następująco:
> .irom0.text : ALIGN(4)
> {
> _irom0_text_start = ABSOLUTE(.);
> *libmbedtls.a:(.literal .text .literal.* .text.*)
> *libpp.a:(.literal.* .text .literal .text.*)
> *libm.a:(.literal.* .text .literal .text.*)
> *(.irom0.literal .irom.literal .irom.text.literal .irom0.text
> .irom.text)
> _irom0_text_end = ABSOLUTE(.);
> } >irom0_0_seg :irom0_0_phdr
> Niestety nie pomogło - projekt ciągle nie chce się kompilować,
> wyrzucając te same błędy...

Jeśli na pewno linker używa tego pliku, to powinno pomóc. Ewentualnie tak
mocno wychodzisz poza zakres, że przesunięcie jednej biblioteki nie pomaga.
Wtedy mozna dopisać węcej, np. libmain (w poprzednim poście się pomyliłem -
chodziło właśnie o libmain, nie libm). Ewentualnie możesz zrobić tak, że
zwiększysz obszar iram1 tak bardzo, aż projekt się zlinkuje. Definicję masz
na początku skryptu:
iram1_0_seg : org = 0x40100000, len = 0x8000
Przykładowo można zmienić 0x8000 na 0x10000. Oczywiście kod wynikowy nie
zmieści się w pamięci modułu, ale chodzi o to żeby przeanalizować wynikowy
plik wykonywalny. Sprawdzić ile ostatecznie zajęły poszczególne sekcj i
które funkcjeoraz z których bibliotek są w tych sekcjach. Można do tego użyć
readelf albo przejrzeć plik .map jeśli jego generowanie jest uwzględnione w
Makefile.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 31.10.2018 16:02, Grzegorz Niemirowski wrote:

> Na pewno ten? Poza tym tutaj ta sekcja jest dużo dłuższa:
> https://github.com/espressif/ESP8266_NONOS_SDK/blob/
master/ld/eagle.app.v6.ld

Plik o tej samej nazwie. SDK pobrałem kiedyś (bodajże z GitHuba)
kompilując sobie toolchain do ESP8266. Posługiwałem się wtedy jakimś
opisem znalezionym w Sieci. Możliwe, że to po prostu jakaś starsza wersja.

Swoją drogą spróbowałem także drugiego rozwiązania, przez modyfikację
plików bibliotek za pomocą zaproponowanej przez Ciebie komendy
(xtensa-lx106-elf-objcopy --rename-section .text=.irom0.text
--rename-section .literal=.irom0.literal libpp.a). W ten sam sposób
zmodyfikowałem także libc i libgcc, ale nie pomogło - błąd ciągle
występuje. Co dziwniejsze wygląda na to, że (w przypadku zakomentowania
kawałka kodu celem umożliwienia kodu) mapa pokazuje, że biblioteki
faktycznie trafiają do irom0.text. To naprawdę nie ma jakiegokolwiek
sensu...


> Możesz puścić make VERBOSE=1 i wkleić linijkę od linkowania?

Cały wynik jest tutaj. W tym przypadku użyłem standardowego,
niezmodyfikowanego skryptu linkera, ale biblioteki są już zmodyfikowane.
https://pastebin.com/QTNyJEFE

Jeśli zakomentować wspomniany kawałek kodu, zostanie wygenerowana
następująca mapa:
https://pastebin.com/pepCwbtX

Jak widzisz wspomniane wcześniej biblioteki trafiają do flasha.
BTW w jaki sposób odkręcić tę modyfikację. Nie jestem pewien, czy libc i
libgcc jednak nie powinny pozostać w RAM-ie...


> zlinkuje. Definicję masz na początku skryptu:
> iram1_0_seg : org = 0x40100000, len = 0x8000
> Przykładowo można zmienić 0x8000 na 0x10000. Oczywiście kod wynikowy nie
> zmieści się w  pamięci modułu, ale chodzi o to żeby przeanalizować
> wynikowy plik wykonywalny.

Wprowadziłem taką modyfikację, ale projekt cały czas się nie kompiluje...

do góry

Atlantis <m...@w...pl> napisał(a):
> Plik o tej samej nazwie. SDK pobrałem kiedyś (bodajże z GitHuba)
> kompilując sobie toolchain do ESP8266. Posługiwałem się wtedy jakimś
> opisem znalezionym w Sieci. Możliwe, że to po prostu jakaś starsza wersja.
> Swoją drogą spróbowałem także drugiego rozwiązania, przez modyfikację
> plików bibliotek za pomocą zaproponowanej przez Ciebie komendy
> (xtensa-lx106-elf-objcopy --rename-section .text=.irom0.text
> --rename-section .literal=.irom0.literal libpp.a). W ten sam sposób
> zmodyfikowałem także libc i libgcc, ale nie pomogło - błąd ciągle
> występuje. Co dziwniejsze wygląda na to, że (w przypadku zakomentowania
> kawałka kodu celem umożliwienia kodu) mapa pokazuje, że biblioteki
> faktycznie trafiają do irom0.text. To naprawdę nie ma jakiegokolwiek
> sensu...
>> Możesz puścić make VERBOSE=1 i wkleić linijkę od linkowania?
> Cały wynik jest tutaj. W tym przypadku użyłem standardowego,
> niezmodyfikowanego skryptu linkera, ale biblioteki są już zmodyfikowane.
> https://pastebin.com/QTNyJEFE

Z tego co widzę, to linker krzyczy o brak definicji wywołań systemowych oraz
o zduplikowane funkcje odnoszące się do czasu a nie o przekroczenie zakresu
pamięci.
I zwracam honor odnośnie generowania skryptu linkera, faktycznie tak jest.
Nie zaobserwowałem czegoś takiego w open sdk.

> Jeśli zakomentować wspomniany kawałek kodu, zostanie wygenerowana
> następująca mapa:
> https://pastebin.com/pepCwbtX
> Jak widzisz wspomniane wcześniej biblioteki trafiają do flasha.
> BTW w jaki sposób odkręcić tę modyfikację. Nie jestem pewien, czy libc i
> libgcc jednak nie powinny pozostać w RAM-ie...

Ogólnie tam powinny być rzeczy, które powinny się wykonać szybko, np.
obsługujące przerwania. Ale co konkretnie to nie wiem.

> Wprowadziłem taką modyfikację, ale projekt cały czas się nie kompiluje...

Ale z tego co widzę to chodzi o brakujące i zduplikowane definicje funkcji a
nie obszary pamięci. Trzeba by się temu przyjrzeć. W dalszej kolejności
można spróbować zmienić SDK na najnowszą wersję tego otwartego.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 02.11.2018 10:33, Grzegorz Niemirowski wrote:

> Ogólnie tam powinny być rzeczy, które powinny się wykonać szybko, np.
> obsługujące przerwania. Ale co konkretnie to nie wiem.

Mogę jakoś odkręcić te modyfikacje? Zapomniałem zrobić kopie zapasowe.
Niby SDK bez problemu ściągnę z sieci, ale jeśli da się prościej (paroma
komendami) przywrócić domyślne ładowanie do .text, to chętnie bym z tego
rozwiązania skorzystał...


> Ale z tego co widzę to chodzi o brakujące i zduplikowane definicje
> funkcji a nie obszary pamięci. Trzeba by się temu przyjrzeć. W dalszej
> kolejności można spróbować zmienić SDK na najnowszą wersję tego otwartego.

Na trop braku miejsca w .text naprowadził mnie fakt, że w momencie gdy
projekt jeszcze się kompiluje ta sekcja jest zajęta prawie w całości.

Jakiś pomysł co o tego, gdzie mogę szukać źródła problemu z dublującymi
się/brakującymi funkcjami?

do góry

Atlantis <m...@w...pl> napisał(a):
> Mogę jakoś odkręcić te modyfikacje? Zapomniałem zrobić kopie zapasowe.
> Niby SDK bez problemu ściągnę z sieci, ale jeśli da się prościej (paroma
> komendami) przywrócić domyślne ładowanie do .text, to chętnie bym z tego
> rozwiązania skorzystał...

Tak jak podpowiada intuicja, zamiast .text=.irom0.text napisać
.irom0.text=.text

> Na trop braku miejsca w .text naprowadził mnie fakt, że w momencie gdy
> projekt jeszcze się kompiluje ta sekcja jest zajęta prawie w całości.

OK, ale jedno z drugim nie ma żadnego związku.

> Jakiś pomysł co o tego, gdzie mogę szukać źródła problemu z dublującymi
> się/brakującymi funkcjami?

1. Dublują się symbole __tzyear i __tznorth, które występują jednocześnie w
lwip i libc. Są to zmienne (niejawnie) external. Być może rozwiązaniem
będzie zadeklarowanie ich w lwip jako static żeby nie były external. Chyba
że celowo są jako external. Jeśli są, to można spróbować zmienić im nazwy w
obrębie lwip. Albo wywal sntp.c jeśli nie używasz.
2. Brakujące symbole wynikają z braku dostarczenia funkcji obsługujących
wywołania systemowe (syscalls), gdy linkujesz z flagą -nodefaultlibs. Musisz
dodać te funkcje. Wystarczą w większości puste definicje:
https://github.com/RIOT-OS/RIOT/blob/master/cpu/esp8
266/syscalls.c

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 05.11.2018 00:29, Grzegorz Niemirowski wrote:

> Tak jak podpowiada intuicja, zamiast .text=.irom0.text napisać
> .irom0.text=extent

Czyli coś takiego?

xtensa-lx106-elf-objcopy --rename-section .irom0.text=extent
--rename-section .literal=.irom0.literal libpp.a

Treści po "literal" nie zmieniać?


> 1. Dublują się symbole __tzyear i __tznorth, które występują
> jednocześnie w lwip i libc. Są to zmienne (niejawnie) external. Być może
> rozwiązaniem będzie zadeklarowanie ich w lwip jako static żeby nie były
> external. Chyba że celowo są jako external. Jeśli są, to można spróbować
> zmienić im nazwy w obrębie lwip. Albo wywal sntp.c jeśli nie używasz.

Rozumiem, że mowa o bezpośredniej ingerencji w kod lwip? Bo z tego co
widzę, to ta biblioteka standardowo jest dostępna w SDK w formie
prekompilowanej, jako plik liblwip.a.

Niestety sntp jest jedną z najbardziej podstawowych bibliotek w tym
projekcie. Trochę dziwne, że problem pojawia się teraz. W końcu lwip to
chyba standardowy składnik projektów tworzonych na ESP8266, a z sntp
korzystałem do tej pory bardzo często i nigdy nic takiego się nie działo...


> 2. Brakujące symbole wynikają z braku dostarczenia funkcji obsługujących
> wywołania systemowe (syscalls), gdy linkujesz z flagą -nodefaultlibs.
> Musisz dodać te funkcje. Wystarczą w większości puste definicje:
> https://github.com/RIOT-OS/RIOT/blob/master/cpu/esp8
266/syscalls.c

Ok, dzięki za informację. Przyjrzę się tej sprawie bliżej. :)

do góry