Přiveďte to zpět z mrtvých k dokončení.
Podrobnosti jsou nejasné, ale jak se ukázalo, samotné zařízení při startu havarovalo. Věřím, že to mělo co do činění s chatováním generovaným uBootem na USB lince. V podstatě uBoot dotazoval všechny hardwarové linky (včetně USB), aby našel zaváděcí obraz. Toto dotazování by mělo být neškodné, ale firmware na našem USB zařízení to nezvládl a okamžitě se zhroutil, což způsobilo jeho nefunkčnost až do tvrdého resetu (fyzického odpojení zařízení a jeho opětovného připojení).
Nahlásili jsme tuto chybu výrobci zařízení, ale neobdrželi jsme žádný náznak, že by oprava problému (která se zjevně týkala pouze nás) byla prioritou, a tak jsme se uchýlili k opravě 0,50 $.
Způsob, jakým jsme to vyřešili, byl docela kreativní, ale fungoval bezchybně. Postavili jsme jednoduché relé řízené GPIO a propojili USB napájecí vedení přes toto relé. V podstatě se systém spustil s „vypnutým“ relé, a tedy bez napájení USB zařízení. Systém se normálně spustil a v našem spouštěcím skriptu jsme jednoduše přepnuli linku GPIO, aby se relé aktivovalo. Zařízení USB bylo možné normálně spustit bez rušení ze strany uBoot.
Zní to, jako by se zařízení pokusilo chatovat s OS při prvním spuštění, a protože zásobník v té době nebyl připraven, „odhlásilo se“ z hubu. Zvažte přidání sekce na konec zaváděcího procesu, abyste zrušili ovladač a vynutili opětovné načtení. (modprobe -vr ehci_hcd; modprobe -v ehci_hcd pokud USB2.0, uhci_hcd pokud USB1.x)
Další možností je, že když se Gumstix vypnul, řekl zařízení, aby přešlo do režimu úspory energie, který může být zařízením nesprávně podporován. Windows tam mohou dělat věci jinak než Windows, což může být vše, na čem výrobce testoval. Chcete-li to otestovat, možná budete muset sdělit ovladači zařízení, aby během restartování systému nepozastavoval nebo nevypínal zařízení. Chcete-li začít, podívejte se do dokumentace jádra Linuxu o úsporách energie v části USB.