Nem sok esélyt látok rá, de hátha. Írt már valaki esp8266 bootloadert?
Idáig jutottam (AI segítségével).
Első körben egy led villogtató, serial print "Hello word" elég lenne, a többi talán már menne.
Fontos hogy IRAM-ból fusson, A 0x100000-0x1FFFFF flest akarom 0x000000-0x0FFFFF helyre másolni vele.
bootloader.ld
ENTRY(_start)
MEMORY{ /* IRAM: 32 KB-os RAM terület */ iram (rwx) : ORIGIN = 0x40100000, LENGTH = 32K}
SECTIONS{ .text : { . = ALIGN(4); /* 1. LITERÁLOK */ *(.literal) *(.literal.*) /* 2. KÓD */ *(.text) *(.text.*) /* 3. KONSTANS ADATOK */ *(.rodata) *(.rodata.*) /* --- ÚJ: Globális Adatok (Inicializált) --- */ . = ALIGN(4); *(.data) *(.data.*) /* --- ÚJ: Globális Adatok (Inicializálatlan, 0-ra kell állítani) --- */ . = ALIGN(4); _bss_start = .; *(.bss) *(.bss.*) . = ALIGN(4); _bss_end = .; } > iram}
bootloader.S
.section .text.global _start
_start: /* Stack Pointer beállítása az IRAM végére: 0x40107FFC */ movi a1, 0x40107FFC
/* Ugorjunk a C kód fő belépési pontjához */ call0 main_entry
/* Végtelen ciklus (trap) */hang: j hang
bootloader.c
#include <stdint.h>
// -------------------------------------------------------------------------// Hardver Regiszterek Definiálása// -------------------------------------------------------------------------
// System/WDT#define WDT_CTL_REG 0x600000A0#define DPORT_BASE_ADDR 0x3FF00000#define DPORT_CLOCK_GATE_REG (DPORT_BASE_ADDR + 0x28) // Órajel vezérlés
// GPIO/LED (Wemos D1 Mini)#define GPIO_BASE_ADDR 0x60000300#define GPIO_ENABLE_W1TS_REG (GPIO_BASE_ADDR + 0x14)#define GPIO_OUT_W1TS_REG (GPIO_BASE_ADDR + 0x08)#define GPIO_OUT_W1TC_REG (GPIO_BASE_ADDR + 0x0C)#define LED_PIN_MASK (1 << 2) // GPIO2 maszk
// -------------------------------------------------------------------------// Késleltető Segédfüggvény// -------------------------------------------------------------------------
// Késleltetés 80 MHz-es CPU frekvenciára kalibrálva (Kb. 80000 ciklus/ms)#define DELAY_CYCLES_PER_MS 40000 // Csökkentett ciklusszám a biztos láthatóságért (kb. 500 ms-ot ad 80 MHz-en)
static void delay_ms(uint32_t ms) { volatile uint32_t cycles = ms * DELAY_CYCLES_PER_MS; while (cycles > 0) { cycles--; }}
// -------------------------------------------------------------------------// Fő Belépési Pont// ------------------------------------------------N---------
void main_entry(void) { // 0.1. MEGSZAKÍTÁSOK KIKAPCSOLÁSA __asm__ __volatile__ ( "rsr a2, PS\n" "movi a3, 0xFFFFFFFC\n" "and a2, a2, a3\n" "wsr a2, PS\n" "esync\n" );
// 0.2. WATCHDOG TIMER (WDT) KIKAPCSOLÁSA volatile uint32_t *wdt_ctl = (volatile uint32_t *)WDT_CTL_REG; *wdt_ctl = 0x73; *wdt_ctl = 0x83;
// 0.3. ⚡ CPU ÓRAJELEL KÉNYSZERÍTÉSE 80 MHz-RE // A DPORT_CLOCK_GATE_REG (0x3FF00028) beállítása: // Bit 0: CPU_CLK_SEL (0=40MHz, 1=80MHz) - Ez a legfontosabb // Bitek 1 és 2 is fontosak lehetnek a stabil órajelhez. volatile uint32_t *dport_clk = (volatile uint32_t *)DPORT_CLOCK_GATE_REG; // Feltételezve, hogy a 80 MHz bit 0, de a teljes órajel inicializációhoz biztonságosabb a ROM hívás, // de mivel ezt elvetettük, a regiszterekkel próbálkozunk. // **FIGYELEM:** Mivel a pontos bare-metal CPU_CLK regisztercím eltérhet, de az // *ETS_RTC_SET_CONFIG()* ROM hívás pontos. Maradjunk a direkt beavatkozásnál, // de tegyünk egy biztonsági késleltetést. // Ideiglenes késleltetés az órajel stabilizálására, mielőtt a GPIO-t beállítjuk volatile int i; for (i = 0; i < 50000; i++) {}
// 0.4. 💡 GPIO2 INITIALIZÁLÁSA (LED vezérlés) volatile uint32_t *gpio_enable_w1ts = (volatile uint32_t *)GPIO_ENABLE_W1TS_REG; volatile uint32_t *gpio_out_w1ts = (volatile uint32_t *)GPIO_OUT_W1TS_REG; *gpio_enable_w1ts = LED_PIN_MASK; // GPIO2 beállítása kimenetnek *gpio_out_w1ts = LED_PIN_MASK; // GPIO2 HIGH (LED KI) - Kezdő állapot // 1. Végtelen ciklus (LED villogtatás) volatile uint32_t *gpio_out_w1tc = (volatile uint32_t *)GPIO_OUT_W1TC_REG;
while (1) { // LED BE (LOW) *gpio_out_w1tc = LED_PIN_MASK; delay_ms(500); // 500 ms késleltetés
// LED KI (HIGH) *gpio_out_w1ts = LED_PIN_MASK; delay_ms(500); // 500 ms késleltetés }}
bootloader.cmd
@echo offsetlocal enabledelayedexpansion
:: === CONFIGURE these paths ===set "TOOLCHAIN_DIR=F:\asm\bin"set "SRC=bootloader.c"set "LD=bootloader.ld"set "SC=bootloader.S"set "ESPPORT=COM9":: =============================
echo Checking toolchain...set "PATH=%TOOLCHAIN_DIR%;%PATH%"where xtensa-lx106-elf-gcc >nul 2>&1if errorlevel 1 ( echo [ERROR] xtensa toolchain not found in PATH: %TOOLCHAIN_DIR% pause exit /b 1)
echo Building...
xtensa-lx106-elf-gcc -c %SC% -o startup.o -Osxtensa-lx106-elf-gcc -c %SRC% -o bootloader.o -Os -nostdlib -fno-builtin -mlongcallsxtensa-lx106-elf-ld -T %LD% startup.o bootloader.o -o bootloader.elf
esptool.exe elf2image bootloader.elf
esptool.exe --port %ESPPORT% --baud 921600 write_flash 0x00000 bootloader.elf-0x00000.bin
pause
Ezt működő állapotba tudná hozni valaki?
- 1538 megtekintés
Hozzászólások
Az ESP8266 bootloader bele van égetve gyárilag ROM-ba, azt a gyárban megkapta a chip és az cserélhetetlen. Ha még mindig azon pörögsz, hogy OTA frissítést akarsz fájlrendszerről ilyen másolgatásokkal, akkor nem fog így menni, mert ez, amit te bootloader-nek nevezel, ez a futó két programterület közül az egyiken lesz és nem tudja írni se a másik területet, se a saját területét, miközben fut.
- A hozzászóláshoz be kell jelentkezni
Nem adom fel. Igazad van, a rom bootol, a flash 0x000000 címről inditja a kódot ha az megfelel a rom által megkövetelt formátumnak. Ilyet szeretnék egy hello word mintával. Az Arduino által fordított kód is 0x000000 címtől kezdődik, ezt indítja a rom, ami működik. Serial print, erase flash, write flash direktben hívható a bedrótozott romból. Felbaszta az agyam, azért is megcsinálom.
σ→0, SNR<1 (A semleges részecskékkel nincs mérhető kölcsönhatás)
- A hozzászóláshoz be kell jelentkezni
Az ESP8266 bootloader bele van égetve gyárilag ROM-ba, azt a gyárban megkapta a chip és az cserélhetetlen.
Egyes mobiltelefonoknál alternatív ROM felrakása előtt ki kell "nyitni"
a bootloadert - jelentsen ez bármit is - egyiknél a gyártótól kapott, a szériaszámból generált kóddal. Az miben más? Az (át)írható is?
Ez is ESP csak más verzió, itt fash-eli
https://github.com/espressif/esptool/blob/master/docs/en/advanced-topic…
- A hozzászóláshoz be kell jelentkezni
.
σ→0, SNR<1 (A semleges részecskékkel nincs mérhető kölcsönhatás)
- A hozzászóláshoz be kell jelentkezni
Szerintem a boot loader pont nem az, amit AI-val kellene íratni. Mondjuk mást sem.
Olyan apróságok például, hogy mi van a megszakítás vektortáblával?
ESP-re még nem írtam boot loader-t, de PIC32-re és PIC18-ra már igen.
A letöltött program entry pointját vagy a linker scripttel mondod meg, vagy valahogy elmeséled a fejlesztői környezetnek, hogy offset-elje feljebb a kódot, de ügyes megoldás lehet, ha meg tudod kérni a fejlesztői környezetet arra, hogy a hex file-ba írjon SLA-t (0x05: Start Linear Address), s ide adod a vezérlést.
Az ESP-t nem ismerem, emiatt nem tudok konkrét lenni.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Szerintem a boot loader pont nem az, amit AI-val kellene íratni. Mondjuk mást sem.
Ezt a mondatot ki kellene rakni az oldalsávra közvetlenül a menü alá, arany keretben. :D
- A hozzászóláshoz be kell jelentkezni
De akkor nem nevezhetné magát "programozónak" sok ember.
1904.04.08.
RIP Jákub.
neut @
- A hozzászóláshoz be kell jelentkezni
Az alapgondolat egyszeru is tud lenni. Felosztod a programmemoriat (legalabb) ket reszre. Egyik resze bootol be, es azon egy olyan kod fut ami egyreszt lehetove teszi az eszkoz elereset egy olyan adott halozati(bb) interface-en amin keresztul a progremmemoria masik resze(i)t frissitheted, masreszt pedig a kello pillanatban atadja oda ugy a vezerlest a programmemoria masodik reszere hogy ezzel parhuzamosan meghamisitja/visszaallitja a CPU-t a reset allapothoz minel kozelebbi allapotba. Az ordog a reszletekben rejlik - mi(k) is lesz(nek) ez a halozati interface(k), hogyan kulonbozteted meg a "bootloader" es a "bebootolt" allapotokat, hogy allitod vissza a CPU-t reset (kozeli) allapotba, a memory layout-tol fuggo particionalasa a programmemorianak, flash page alignmentek, linker script modositasa, vektor tabla cimenek modositasa, periferia/interrupt/stb inicializalasok visszahivasa, .rodata/.data/.bss section-ok ismerete, .rodata tulajdonsagai (ld. Harvard vs. Neumann problemak), stbstbstb - de ezek mar elegge architektura-fuggoek tudnak lenni. Cserebe ezek a reszletek jol behatarolhato, kulon-kulon is jol letesztelheto lepesek.
Hajra :)
- A hozzászóláshoz be kell jelentkezni
Az EspOS már tudja hogy ha firmware.bin fált kap feltöltéskor akkor leállítja az SPIFFS-t, a beérkező cuccot felírja 0x100000 címtől. Utána egy uint8_t tömböt (ez lenne a bootloader) felír 0x00000-0x00FFF címre. Nincs crash. Reboot után szeretnék látni egy soros "Hello word"-ot.
σ→0, SNR<1 (A semleges részecskékkel nincs mérhető kölcsönhatás)
- A hozzászóláshoz be kell jelentkezni
Ugyerted, azt a kodot akarod atirni tavolrol ami cold start utan rogton indul?
- A hozzászóláshoz be kell jelentkezni
Igen. Az SPIFFS tartalmát buktam, írás közben ha elmegy a táp akkor softbrick, ezt leszarom. Szerintem működnie kell, csak azt a kurva bootloadert nem tudom megírni, elindítani (első körben egy "hello word".
σ→0, SNR<1 (A semleges részecskékkel nincs mérhető kölcsönhatás)
- A hozzászóláshoz be kell jelentkezni
A lenti hozzászólása bizonyítja, hogy igazából nem :D
1904.04.08.
RIP Jákub.
neut @
- A hozzászóláshoz be kell jelentkezni
Az alapgondolat egyszeru is tud lenni. Felosztod a programmemoriat (legalabb) ket reszre. Egyik resze bootol be, es azon egy olyan kod fut ami egyreszt lehetove teszi az eszkoz elereset egy olyan adott halozati(bb) interface-en amin keresztul a progremmemoria masik resze(i)t frissitheted, masreszt pedig a kello pillanatban atadja oda ugy a vezerlest a programmemoria masodik reszere hogy ezzel parhuzamosan meghamisitja/visszaallitja a CPU-t a reset allapothoz minel kozelebbi allapotba.
Az alapgondolat olyannyira egyszerű, hogy az ESP8266 esetén ez a viselkedés bele van égetve a chip-be, definiálni kell kettő programterületet (dual partition layout), amelyek közül az egyik aktív, a másik meg írható a bootloader megfelelő hívásával. Az a dolog viszont nem megy, hogy csak egy programterületet definiálsz, és azt írod konkrétan a futó program alatt. Ami itt bootloader néven van nevezve, az maga a futó program... OP kolléga viszont nem így szeretné, ahogy meg szeretné, az úgy nem megy.
- A hozzászóláshoz be kell jelentkezni
Az a dolog viszont nem megy, hogy csak egy programterületet definiálsz, és azt írod konkrétan a futó program alatt.
Ez nem illendo, igen. Legalabbis ugy altalaban mehetni mehet de azert nem csinalnam :)
Ettol fuggetlenul az ilyen gyari ROM-os bootloaderek azok lehet hogy jatszani jok meg par dolgot egyszerusitenek (programozo helyett hasznalhatsz egy szokvanyosabb portot, mondjuk UART-ot), de elesben, ha egy adott interface-n egy adott protokoll szerint kell frissiteni (ami lehet full egyedi is, mert epp' az a kovetelmeny), akkor... akkor jo kerdes hogy mire mesz ezekkel a beleegetett ROM-okkal.
De sokat nem akarok okoskodni, az ESP8266-t csak igy futolag futottam at. De a masik ~feltucat architekturanal ahol ilyeneket csinaltam ott a fentebbi meglatasok mukodtek. Es valojaban itt sem latom hogy miert ne mukodne.
- A hozzászóláshoz be kell jelentkezni
De sokat nem akarok okoskodni, az ESP8266-t csak igy futolag futottam at. De a masik ~feltucat architekturanal ahol ilyeneket csinaltam ott a fentebbi meglatasok mukodtek. Es valojaban itt sem latom hogy miert ne mukodne.
Mert az ESP8266 esetén van egy gyárilag beleégetett bootloader, ami egy vagy két partícióról tud firmware-t indítani és két partícióval tud OTA frissítést (az aktív partíció tudja írni a passzív partíciót, reboot és az újabb indul el). Ez ilyen. És mivel ilyen, ezért nincs mozgástered. Az ESP8266 12 éve jött ki, 12 év alatt nem írt senki olyat, amit OP szeretne (egy partíciót használ, letölti az új firmware-t a fájlrendszerbe és onnan átmásolja maga alá az éppen futó program). Nem azért nem írt senki ilyet, mert nem gondoltak rá, hanem azért, mert ESP8266 esetén ezt nem lehet megoldani. Ha meg is lehetne oldani, akkor is egy csomó nem várt probléma miatt az eszköz frissíthetetlen lesz.
Az egyetlen megoldás kb. az, hogy aszimmetrikus méretű a két partíció, az egyikben van egy OTA frissítő, a másikban meg van a futó firmware, de OP ezt már korábban elvetette.
- A hozzászóláshoz be kell jelentkezni
Van olyan strategia is, hogy azt a kodot amivel epp irod a flash bezuzod a RAM-ba es onnan futattod. Egy kis linker script magia. Helyzetfuggo, hogy mikor tekintheto ganyolasnak, de inkabb kerulendo.
- A hozzászóláshoz be kell jelentkezni
Igen, a RAM-bol valo futtatast szoktak hasznalni, de szerintem nem pont erre. Sokszor azert kell, mert az eszkoz egyaltalan nem kepes a flashbol olvasni (pl. betolteni a kovetkezo utasitast) es irni bele.
De itt masrol van szo, az OTA eseten az egesz stacket be kellene huzni a RAM-ba, hiszen az vegzi a vezetek nelkuli kommunikaciot, ami Wi-Fi / BLE / akarmi eseten nem csak egy par byte. Ugye mi tortenik, amikor pont azt a reszet irod felul a flash-ben a Wi-Fi stacknek ami eppen a csomagokat kuldozgeti? ;-)
/sza2
Digital? Every idiot can count to one - Bob Widlar
- A hozzászóláshoz be kell jelentkezni
En nem lattam sehol, hogy over the air updatet akar csinalni. Linkermagic, es gany, de azt is egyszeruen nem piszkalod a flashben es mikor ujraindul akkor irod at.
De igen, valoban arra szoktak hasznalni, hogy irasra lockolt flasht tudjanak irni, hisz abbol nem lehet olvasni (ha pl. van flash tukor akkor igy lesz atomikus a muvelet).
- A hozzászóláshoz be kell jelentkezni
Nem fér el a RAM-ban az ehhez szükséges firmware.
- A hozzászóláshoz be kell jelentkezni
A rom tartalmaz mindent csak hívogatni kell.
https://chatgpt.com/share/6931f44a-67ac-8011-9f99-6351808b81c0
Símán bele kell férnie 4kB-ba.
σ→0, SNR<1 (A semleges részecskékkel nincs mérhető kölcsönhatás)
- A hozzászóláshoz be kell jelentkezni
Csak magyarazd mar el nekunk mit akarsz csinlani, mi itt a cel? :)
Akkor talan jobban tudnank segiteni, te ...
Nem bantasbol, de az van, hogy ez nem egy html kod generalas... Itt ehhez tenyleg erteni kell, rengeteg idodet fogja elvinni az LLM es nem fogsz tudni vele celt erni.
- A hozzászóláshoz be kell jelentkezni
"Az EspOS már tudja hogy ha firmware.bin fált kap feltöltéskor akkor leállítja az SPIFFS-t, a beérkező cuccot felírja 0x100000 címtől. Utána egy uint8_t tömböt (ez lenne a bootloader) felír 0x00000-0x00FFF címre." Ez működik.
0x00000-0x00FFF szeretnék egy bootolható kódot ami a 0x100000-0x1FFFFF tartományt átmásolja 0x000000-0x0FFFFF
σ→0, SNR<1 (A semleges részecskékkel nincs mérhető kölcsönhatás)
- A hozzászóláshoz be kell jelentkezni
Szoval AB software update-t akarsz csinalni? A futo alkalmazas beirja az uj firmwaret a B oldalra majd ujraindulasnal valtassz ? De minek kell a masolas?
- A hozzászóláshoz be kell jelentkezni
Nincs A/B. 1MB FW, 3MB SPIFFS. Ezt szeretném frissíteni. Az SPIFFS helyére megy az új FW, ezt kéne reboot után átmásolni a helyére (0x0-tól).
σ→0, SNR<1 (A semleges részecskékkel nincs mérhető kölcsönhatás)
- A hozzászóláshoz be kell jelentkezni
Ja igen, igen ez nem tud bank swappingot, hisz kulso flash van.
- A hozzászóláshoz be kell jelentkezni
Nezd meg ezt: https://github.com/raburton/rboot
- A hozzászóláshoz be kell jelentkezni
Ja es fontos tudod, hogy a bootrom siman valtozhat, szoval az hogy "belehivsz" az nem jo.
- A hozzászóláshoz be kell jelentkezni
Nem kell az egeszet atpakolni csak par fuggvenyt, siman elfer.
- A hozzászóláshoz be kell jelentkezni
A kerdes mar csak az, hogy az miert nem jo, ami a tamogatott megoldas. Random fiokbol elohuzott ESP8266 boardon rajta van maga a wifis mikrokontroller, meg egy "bergmicro 25Q80ASSIG" feliratu 8 labu IC. Utobbi egy 8 Mbites (1 MiB) SPI-on elerheto flash, ebben tarolja a programjat, meg ami meg van asset, azt is. Ha ez keves, ezt kicserelve fel lehet menni 25Q256-ig, ami megabitben ennyi, 32 MiB flash. Annak a fele is eleg jelentos. (lehet, hogy az ESP-ben valami flaget kell allitgatni hozza, hogy lassa az egeszet, ennyire nem melyedtem bele) Extrem esetben kulso hardware-rel is megoldhato az egesz, ha nagyon nincs mas megoldas, vegulis egy kulso flash, es az SPI-t akar kezzel is lehet irni egy kapcsoloval es egy prellmentesitett nyomogombbal - nem ajanlott persze.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Egyetertve az elottem szolokkal, szertintem is az a megoldas, hogy van egy custom bootloader (ugy ertem nem az amivel UART-on lehet letolteni az applikaciot), illetve van hely az eppen futo applikacionak es az upgrade image-nek. Kicsit szemleletesebben:
|----|-------------|-------------|
| BL | APP | IMG |Nalunk a fenti sema szerint van megoldva. a bootloader (BL) ad az applikacio (APP) szamara fuggvenyeket, mint iras / olvasas / torles / ujarinditas bootloader modban / image ellenorzes / stb. Az applikacio ami fut kepes ra, hogy OTA letoltson egy (frissebb / masabb) applikaciot az image storage teruletre (IMG). Ha ez megtortent (persze celszeru ellenorizni, hogy az image nem serult-e (pl. valami hash-t szamolni ra)) akkor meghivja a megfelelo fuggvenyt a bootloaderbol, ami ujrainditja az eszkozt es atmasolja az IMG teruletrol az APP teruletre a letoltott image-et majd ismet ujrainditja az eszkozt. Nalunk a RAM-ban van beirva egy byte, ami alapjan a bootloader eldonti, hogy reboot eseten az applikacio induljon el vagy a bootloader irja felul az eredeti applikaciot az ujjal.
Szerintem ez a modszer elegge elterjedt az OTA update-re. Hatranya, hogy ketszer annyi hely kell, mintha nem lenne OTA update lehetoseg (jo, lehet az image-et tomoriteni is).
/sza2
Digital? Every idiot can count to one - Bob Widlar
- A hozzászóláshoz be kell jelentkezni
Ja, bocs, nem irtam, nem ESP8266. Csak ez olyan aranylag altalanos megoldasnak tunik mikrokontrolleres kornyezetben (amugy EFR32).
ESP8266 eseten ez nem tud mukodni?
/sza2
Digital? Every idiot can count to one - Bob Widlar
- A hozzászóláshoz be kell jelentkezni
ESP8266 eseten ez nem tud mukodni?
Nem tud. ESP8266 esetén a bootloader egy fix gyárilag beégetett cucc, ami tud egy partícióról firmware-t indítani vagy kettő partícióról firmware-t indítani, és a maradék flash lehet fájlrendszer. Nincs benne ilyen rugalmasság, sokan próbálták megkerülni, nem tudták.
- A hozzászóláshoz be kell jelentkezni
egy partícióról firmware-t indítani
Es ez az egy partciorol inditott fw tudja modositani a flash tobbi reszet (ami ertelemszeruen kivul van a sajat .text/.rodata szegmensen vagy barmin ami ott annak megfeleltetheto)? Es at tudja adni oda a vezerlest?
- A hozzászóláshoz be kell jelentkezni
Ezt a bootromban levo bootloadert stage 1 bootloadernek is szoktak hivni (nyilvan ez read-only), de ettol meg neked lehet egy sajat stage 2 vagy firmware bootloadered (boot_v1.x.bin).
Ha igy nezed, akkor az abra teljesen jo.
- A hozzászóláshoz be kell jelentkezni
Ugy ertettem, ahogy Ar0n forumtars irta: van a ROM bootloader, amit arra hasznalsz, hogy elinditsa az "applikaciot", ami vegulis egy sajat bootloader + sajat applikacio. Egy (nagy) particiot hasznalsz, de azt felosztod 3 reszre. Az elejen ott lesz a sajat bootloader kodod, ezt inditja el a ROM bootloader. Ez a sajat bootloader pedig elinditja az appot vagy a frissitest (aztan rebootot az appba, ha kesz a frissites). Az update image meg lehet az app mogott (bar igazabol az majdnem teljesen mindegy, hogy hol van, a lenyeg, hogy ROM bootloader a sajat bootloadert inditsa).
Itt nem latok olyan akadalyt amitol ezt ne lehetne megcsinalni. De lehet, hogy tevedek, ESP-vel csak "felhasznaloi" szinten foglalkoztam (ertds: Arduino kornyezetben irtam ra programokat (szenzorok, vezerlesek, (periferiak kezelese + MQTT / Wi-Fi))).
/sza2
Digital? Every idiot can count to one - Bob Widlar
- A hozzászóláshoz be kell jelentkezni
Nincs saját bootloader, egy 4k flash terület van, ami ilyenre kevés, és a tartalma is eléggé kötött, kb. annyira elég, hogy megmondjad, hova ugorjon a flash-ben.
De nyilván, próbálkozzon csak OP, sokan nekifutottak, nem ChatGPT alapon, de nem tudták megoldani.
- A hozzászóláshoz be kell jelentkezni
OK, lehet, hogy meg mindig nem megfeleloen (vagy inkabb felreerthetoen) irtam le. Tehat, amikor "sajat" bootloadert irtam, ugy ertettem, hogy az alkalmazas programozoja (pl. OP) altal irt.
Az az amit nem igazan ertek, hogy onnantol, hogy a ROM bootloader elinditotta a programozo altal irt firmware-t (tekinsuk most ezt egyetlen blobnak), miert ne mukodne az altalam felvazolt metodus. Onnantol kezdve az egesz "egy egysegnek" latszik, megha egyebkent logikailag szet is van osztva a rendelkezesre allo terulet ugy, hogy az elejen ott van egy program, ami tudja kezelni a flasht, ugrani barmilyen cimre (hivjuk ezt pl. 2nd stage bootloadernek (ezt hivtam korabban "sajatnak")), van egy resz maganak az applikacionak (ami kb. az mint amit egyebkent UART-on toltesz le (de pl. a bootloaderbol tud hivogatni fuggvenyeket, mint torles, olvasas, iras)) illetve van egy resz fenntartva az appikacio ujabb verziojanak, amit maga az applikacio, (akar OTA, akar vezetekes modon megkapva) csomagonkent be tud irni erre a teruletre, majd amikor vegzett, atadhatja a vezerlest a bootloadernek ami felulcsapja az eredeti applikaciot az image teruletre korabban letoltott (pl. ujabb verzioju) applikacioval.
/sza2
Digital? Every idiot can count to one - Bob Widlar
- A hozzászóláshoz be kell jelentkezni
a bootloaderbol tud hivogatni fuggvenyeket, mint torles, olvasas, iras
Miért csinálna bárki ilyet? Egyrészt, ha változik a boot loader, eltörik a bináris firmware, azt újra kell fordítani. Másfelől semmi köze a firmware-nek a boot loaderhez, annak függvényeihez, a függvényei címeihez és paraméterezéséhez. Ha belehívsz a boot loaderbe, a firmware függősége lesz az adott verziójú boot loader.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Miért csinálna bárki ilyet?
Hat, gondolom azert mert hasznalhato ;-)
Egyrészt, ha változik a boot loader, eltörik a bináris firmware, azt újra kell fordítani.
Nem, amennyiben a van egy tablazatod, amiben benne vannak a szukseges ("exportalt") fuggvenyek cimei. Ennek a tablazatnak kell fix helyen lenni, onnantol a bootloader akarhogyan valtozhat.
Másfelől semmi köze a firmware-nek a boot loaderhez, annak függvényeihez, a függvényei címeihez és paraméterezéséhez.
Ezt nem is ertem. Mar azt sem, hogy mi a "firmware" es mi a bootloader? A bootloader is egy firmware.
Ha belehívsz a boot loaderbe, a firmware függősége lesz az adott verziójú boot loader.
Nem, lasd fentebb.
Ezeket nem en talaltam, ki, igy mukodik az EFR32-re keszitett Gecko bootloader (ami egyebkent a fentieknel sokkal tobbet tud, de az elv az, amit korabban leirtam).
/sza2
Digital? Every idiot can count to one - Bob Widlar
- A hozzászóláshoz be kell jelentkezni
Firmware alatt a boot loader által letöltött főprogramot értettem. Akkor itt már nem egy boot loader-ről beszélsz, hanem egy boot loader-rel egybeépített BIOS-ról is.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Tehat, amikor "sajat" bootloadert irtam, ugy ertettem, hogy az alkalmazas programozoja (pl. OP) altal irt.
Olyan nincs, ESP8266 esetén az már maga a firmware. Persze, hívhatod úgy, hogy bootloader, csak az attól még nem lesz az. A flash első 4k blokkja, ami a second stage bootloader, az meg egy igen limitált tudású és méretű bootloader, de ez se tud másolgatni innen-oda 1MB adatot, nagyjából arra képes, hogy beállítja a fix adatstruktúrában, hogy hol van a futtatandó firmware.
Az az amit nem igazan ertek, hogy onnantol, hogy a ROM bootloader elinditotta a programozo altal irt firmware-t (tekinsuk most ezt egyetlen blobnak), miert ne mukodne az altalam felvazolt metodus. Onnantol kezdve az egesz "egy egysegnek" latszik, megha egyebkent logikailag szet is van osztva a rendelkezesre allo terulet ugy, hogy az elejen ott van egy program, ami tudja kezelni a flasht, ugrani barmilyen cimre (hivjuk ezt pl. 2nd stage bootloadernek (ezt hivtam korabban "sajatnak")), van egy resz maganak az applikacionak (ami kb. az mint amit egyebkent UART-on toltesz le (de pl. a bootloaderbol tud hivogatni fuggvenyeket, mint torles, olvasas, iras)) illetve van egy resz fenntartva az appikacio ujabb verziojanak, amit maga az applikacio, (akar OTA, akar vezetekes modon megkapva) csomagonkent be tud irni erre a teruletre, majd amikor vegzett, atadhatja a vezerlest a bootloadernek ami felulcsapja az eredeti applikaciot az image teruletre korabban letoltott (pl. ujabb verzioju) applikacioval.
Szerintem, ha ezt megcsinálod, akkor hosszú sorokban lábat fognak csókolni neked igen sokan. Az ESP8266 ebből a szempontból egy igen speciális állatfaj, nem egy generikus MCU, hanem nagyon sok minden hardverből limitált és a hardver része itt a bootloader is. Amit leírtál, abban az a probléma, hogy akkor működik, ha legalább kettő dedikált partíció van, ahova firmware kerül. Ez prímán működik, csak OP nem ezt akarja, neki nem jó a 2x512k + 3M SPIFF, se a 2x1M + 2 MB SPIFF, neki 1x1MB + 3MB SPIFF kell, ahol egy partíció van és a bootloader majd oda belemásolja a tartalmat valahonnan máshonnan a fájlrendszerről. Na, ez nem megy.
- A hozzászóláshoz be kell jelentkezni
Valóban nem néztem meg az ESP8266-ot, de én sem értem. Egyrészt:
2x512k + 3M SPIFF és 1x1MB + 3MB SPIFF között mi a lényegi különbség? Egy boot loader még USB stack-kel együtt is belefér 128 kB-ba, ezt tapasztalatból mondom. Úgy is, hogy a textes hex file-t kapja meg, és a boot loader konvertálja binárissá, benne van a flash írás, verify, néhány parancs, vezérlés átadás, minden is.
Az, hogy valami maga a firmware, szerintem csak elnevezés kérdése. Mondjuk írsz egy olyan stage2 boot loader-t, amit az ESP boot loaderével le tudod tölteni az eszközre. Innentől kezdve pedig ez a stage2 boot loader cserélgeti a címben fölé allokált valódi firmware-t. Ez miért nem megy?
Hogy értsd, PIC32-n is van emlékeim szerint dedikált boot loader címtartomány, amelyhez van hardware támogatás, de kb. az ingerküszöbömet sem érte el, meg kellene néznem, lehet, hogy a felhasználói firmware címterületére írtam a boot loadert, mert nem hoztak lázba a hardware támogatás szolgáltatásai.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
2x512k + 3M SPIFF és 1x1MB + 3MB SPIFF között mi a lényegi különbség?
Hogy egy vagy két firmware-re van partícionálva.
Egy boot loader még USB stack-kel együtt is belefér 128 kB-ba, ezt tapasztalatból mondom.
Egy értelmesen működő ESP8266 firmware Arduino alapokon valahol ~350 kB mérettől indul (a legkisebb mérete 225 kB volt anno, de időközben ez megnövekedett). A native SDK használatával le lehet menni ~100 kB körüli méretre, de akkor ebben nincs network stack például, se fájlrendszer, se semmi luxus. Itt viszont a second stage bootloader mérete 4 kB. És amit utána betölt, az már a firmware és az már nem tud mást betölteni.
Valóban nem néztem meg az ESP8266-ot, de én sem értem. [...] Az, hogy valami maga a firmware, szerintem csak elnevezés kérdése. Mondjuk írsz egy olyan stage2 boot loader-t, amit az ESP boot loaderével le tudod tölteni az eszközre. Innentől kezdve pedig ez a stage2 boot loader cserélgeti a címben fölé allokált valódi firmware-t. Ez miért nem megy?
Szerintem ülj le egyszer és olvasd el az ESP8266 specifikációt meg minden egyebet ezzel a témával kapcsolatban, mert szerintem eléggé haszontalan időtöltés úgy írni egy SoC-ról, hogy közel nulla ismereted van a témában a SoC tudásáról. Ez nem egy univerzális MCU, ebben van egy ROM, amin van egy viszonylag kötött funkciókészlet, kötött architektúra, kötött hardveres és szoftveres működés, amit nem tudsz megkerülni.
- A hozzászóláshoz be kell jelentkezni
Elfogadom, hogy ez ilyen. Én eddig olyan boot loader-eket és firmware-eket írtam, ami alatt nem voltak „gyári” függvények, nem volt oprendszer, egyedül az USB stack, amit nem én írtam meg, hanem a gyárit használtam. Meg legeneráltattam az initet, amelybe aztán utólag kézzel belemódosítottam. De például I2C, soros, meg effélék teljesen saját kitalációk. Ugyan standard lib-ek léteznek, amelyeket vagy használok, de meg is írhatom magamnak. A memset(), memcpy(), stpcpy(), memcmp() és hasonlókra gondolok.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Én eddig olyan boot loader-eket és firmware-eket írtam, ami alatt nem voltak „gyári” függvények, nem volt oprendszer, egyedül az USB stack, amit nem én írtam meg, hanem a gyárit használtam.
Értem, de ez teljesen irreleváns, amikor az ESP8266-ban van egy 32 kB méretű ROM, gyárban beleégetett tartalommal, ami egy bootloader, egy BIOS, egy csomó funkció (SHA1, MD5, Base64, etc) egy csomó szoftveres low-level handler meg a fél oprendszer, és ezt használja a kívülről betöltött firmware, amiben ott van az oprendszer másik fele (Wifi + network stack, file system, satöbbi) + a "user space" program jól összelinkelve.
- A hozzászóláshoz be kell jelentkezni
Attól, hogy ott van, még nem muszáj használni, persze nyilván nagy a kísértés.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
ha nincs, akko' ez micsoda: https://github.com/raburton/rboot ?
- A hozzászóláshoz be kell jelentkezni
Ha megnézed, ez is annyit tud csak, hogy a végén megmondja, hova ugorjon a flash-ban és annyival tud többet, mint az Espressif default, hogy kettőnél több firmware közül képes betölteni bármelyiket. Semmi komplex tudás nincs benne.
- A hozzászóláshoz be kell jelentkezni
Ha mar abban egyetertunk, hogy van/lehet ilyet csinalni akkor abba a 4K-ba egy flash szegmens cseres tamadas elfer. Ez az amit az OP akar.
APP firmware leteszi az updatet beallit egy flaget es ujraindit aztan ez meg validal, felulir.
- A hozzászóláshoz be kell jelentkezni
Ha mar abban egyetertunk, hogy van/lehet ilyet csinalni akkor abba a 4K-ba egy flash szegmens cseres tamadas elfer.
A csere igen, mert azt a ROM csinálja alapvetően. Másolás nem fér bele.
Ez az amit az OP akar.
OP azt szeretné, hogy letölti akárhova az SPIFF területre az új firmware, majd pedig egy bootloader átmásolja onnan a firmware területre. Na, ez nem fér el ott, de ezt már írtam párszor. Az a second stage bootloader egy igen kevés lehetőségű bootloader, nem egy tetszőleges program.
APP firmware leteszi az updatet beallit egy flaget es ujraindit aztan ez meg validal, felulir.
Oké, feladom, írjátok meg ezt a fajta OTA update-et, ami eddig még nem sikerült senkinek. Ha sikerül, akkor ennyivel gazdagabb lesz a világ.
- A hozzászóláshoz be kell jelentkezni
Mi értelme van egy olyan eszköz válsztásának, ami ennyire zárt?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Mi értelme van egy olyan eszköz válsztásának, ami ennyire zárt?
Mert egy csomó dologra nagyon jól lehet használni a keretei között és ezen felül olcsó. Csak ismerni kell a kereteket és mást választani, ha szűk lesz az, amit tud.
- A hozzászóláshoz be kell jelentkezni
Nem csináltál kedvet hozzá. Biztos nem választanék olyan eszközt, amelyre fel kell tennem több tíz vagy több száz kilobyte-nyi blobot, ha egy nyamvadt LED-et akarok villogtatni, és a kódot meg lehet írni néhány byte-ban.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Mondj olcsóbb megoldást, ami tud Wifi-t, kellően gyors (40/80 MHz órajel), van 32 kB memóriája, támogat nagy méretű EEPROM-ot is, meg van benne webszerver, teljes network stack viszonylag egyszerűen. A Shelly kb. ~10 millió ESP8266 alapú cuccot adott el, pár éve tértek át ESP32-re, és ránézésre nem annyira hülyék... :)
Az Espressif két éve lépte át az 1 milliárd eladott chip-et, ezek nagyrészt vagy ESP8266 vagy ESP32 chip-ek, az ESP8266 durva becslésem szerint ebből ~600-700 millió lehet ebből, ez egy célszerszám, kifejezetten IoT cuccokhoz, abban jelenleg nagyjából verhetetlen.
- A hozzászóláshoz be kell jelentkezni
Eloszor 2015-ben volt ESP-s projectem. Bedoglott itthon a hutom elektromechanikus hoszabalyzoja, kicsereltem egy sajatra, Arduino Nano (ATMEGA328P) meg DS18B20-as homero volt benne. Ha mar szetszedtem, es filleres, tettem bele tobb helyre homerot (fagyasztoba es a hatoldalara is), meg egy ESP8266-ot is, ami logolja a homersekleteket az itthoni Raspberryre (utobbi sd kartyaja elszallt, ez a funkcio most inaktiv). Ja, meg a mechanikus kapcsolast kicsereltem egy solid state-re, mert nem akartam megint ezzel kuzdeni. (azota is mukodik a hutom)
Alapbol az ESP egy olyan firmware-rel szallitja az eszkozeit, ami sima UART-on osszekotheto egy tetszoleges mikrokontrollerrel, es AT parancsokkal tudsz vele kommunikalni, gyakorlatilag egy wifi modulkent uzemel. Akkoriban utananeztem, minimalis informacio volt rola, az is foleg kinaiul, ugyhogy az alap programnal maradtam (valaki demozott C-ben egy wifin kapcsolhato asztali lampat, de kb. ennyi nyoma volt).
De ugye ott van az a filozofiai kerdes, hogy ha van egy 32 bites mikrokontrollered, ami kb. mindent tud, es van benne egy halom Flash meg RAM vegtelen MHz-es orajellel, akkor miert csak arra hasznald, hogy wifit kezeljen, miert csinalja a feladat oroszlanreszet ehelyett egy - mondjuk - 8 bites 16MHz-es masik, ha amugy a wifis alkalmasabb lenne erre?
Ezert ahogy folyamatosan jott rola az informacio (emlekszem, meg azt is sokaig lebegtettek, hogy az RX laba 5V tolerans-e, van, akinek mukodott gond nelkul, a gyarto meg azt mondta nem, aztan hogy nem tudjak, most mar igen) kesobb megjelent hozza egy halom alternativ firmware, raadasul meg Lua nyelvu is van, ami egeszen kezdobarat (NodeMCU). Aztan jott az ESP32-es, ami tud a wifi mellett bluetooth-ot is, meg nagyobb, gyorsabb, es tobbmagos - ami mikrokontrollerek kozt nem annyira gyakori. Arban meg tovabbra sincs elszallva.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Ebből talán ki is hagyhatnád az Arduinot és a saját kódot. Az ESP8266-tal és ESPHome firmware-rel valószínű, hogy egy sor kód nélkül meg tudnád csinálni a hőmérést és a kapcsolgatást helyben. Lehetne rajta igény szerint egy Web UI, amin nézegethetnéd és minden macera nélkül tudnád akár Home Assistantba is integrálni.
$ grep -c egy$ word.list
100
- A hozzászóláshoz be kell jelentkezni
Igen, 10 evvel kesobbi eszkozokkel maskepp csinalnam. De mukodik, stabil, a feladatat ellatja, szoval nem piszkalom, semmi ertelme nem lenne.
A homersekletkuldest foleg tanulasi cellal tettem bele, nem azert, mert annyira szuksegem van a pontos adatokra - arra eleg lenne a historikus.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Alapbol az ESP egy olyan firmware-rel szallitja az eszkozeit, ami sima UART-on osszekotheto egy tetszoleges mikrokontrollerrel, es AT parancsokkal tudsz vele kommunikalni, gyakorlatilag egy wifi modulkent uzemel.
Az ESP-01 jött ki így, mivel azt a gyártója - ami nem az Espressif - hanem az AI-Thinker valóban csak egy olcsó Wifi modulnak szánta. Aztán kijött még pár ESP-xx board, szintén az AI-Thinker tervezésében és gyártásában és kijött pár official Espressif is, ESP-WROOM-xx néven. Aztán jött a NodeMCU, majd a Wemos, a Lolin, a DoIt, TTGO/LilyGO, Sparkfun és még mindig csak 2016-ban és 2017-ben járunk... :D
- A hozzászóláshoz be kell jelentkezni
Az SPIFFS kodja last I know ~50kB volt, az valoban nem fer bele. Ha azt lecsupaszitod csak az olvasasra, ketlem, hogy elferne.
Viszont, azt irta, hogy "SPIFFS helyére megy az új FW". Nekem ebbol az jon le, hogy nem akar FS-t hasznalni, csak annak a helyet felhasznalni.
De igazad van, ennyit mar nem er ez az egesz. Majd megoldja mindenki a sajat kis bajat.
- A hozzászóláshoz be kell jelentkezni
Amit eddig csináltam boot loader-t, abban teljesen önálló kód a boot loader és a letöltött, majd futtatott kód. Tehát a letöltött firmware nem támaszkodik a boot loader függvényeire és viszont, azaz a boot loaderben is megvan minden magában.
Reset után elindul a boot loader. Ha nem szólítják meg és a firmware entry point-on nem csupa 0xff van, akkor adott timeout letelte után átadja a vezérlést a firmware-nek. Ha a timeout letelte előtt megszólítják akár csak egy státusz kérdezéssel, akkor a timeout végtelenné válik, nem kell attól tartani, hogy elugrik a firmware-re. Lehet neki azt mondani, hogy nesze, itt a firmware, írd be a flash memóriába. Lehet csinálni ellenőrzést, hogy kiderüljön, sikerült-e a flash-be írás. Aztán át lehet adni a vezérlést a firmware-nek.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Tényleg nem egyszerű. _Franko_ megmondta a tutit. Az a baj hogy már nem hiszek senkinek, pedig igaza volt.
σ→0, SNR<1 (A semleges részecskékkel nincs mérhető kölcsönhatás)
- A hozzászóláshoz be kell jelentkezni