Linux na Motorole 68008 a nepájivém poli (diskuse)

[Pavel Píša]

Troška nostalgie. Připomíná mi to testování uCLinuxu 2.0 včetně podpory síťové karty na naší desce MO_CPU1 (zdokumentované v diplomové práci Michala Sojky z roku 2003)

Desky se stále ještě pro reálné robotické aplikace používají, ale přesto, že Linux na ní chodil, tak to byl jen pokus a vzhledem k overheadu to nemá kromě získávání smysl. Udržuji pro desky podporu pro RTOS RTEMS, který je dostupnému množství paměti přiměřenější, ale hlavní aplikace robotického kontroléru je napsaná natvrdo na HW s řídicí smyčkou v přerušení a vlastní regulátory jsou zoptimalizované v assembleru, aby se řízení osmi os na 1 kHz stíhalo. V dnešní době ale přecházíme a používáme ARMy Cortex-M4F a Cortex-A8.

Co se týče řady Motorola 683xx, tak je byl z mého pohledu nepřátelštější mikrokontrolér, co znám. Žádná překvapení, periferie chodily tak jak bylo v manuálu a manuál byl dokonale strukturovaný. Například SPI řadič jsem podle manuálu naprogramoval na několik periodických přenosů s různými parametry a výsledek chodil hned na první spuštění. Současné manuály často psané v Číně a nebo odbyté s neúplným popisem registrů a koncepce jsou proti tomu neštěstí. Potom ještě postupně vyjdou errata, kde se člověk dozví, že v každé periferii jsou alespoň dvě chyby, které za určitých okolností vedou k nedefinovanému chování. Prostě M68k byla jiná doba, pomalejší, ale s důrazem na spolehlivost.

No nic tak zpátky k LPC1778 a druhému koprocesoru který máme navržený v FPGA. Už to umí víc než naše dřívější systémy, mnohem rychleji a alespoň ta část na ARMu je celá v C, ale do preciznosti a míře otestování starší aplikace to má ještě daleko. Jinak na LPC také existuje uCLinux, ale čas s tím ztrácet nebudeme. To je lepší už i RPi nebo raději AM335x nebo i.MX5x/6. RTEMS nám na tom naopak chodí pěkně.

[Petr Ježek]

Ona by se ta pomeješí doba hodila i dnes. Miliardy spokojených uživatelů by jásaly...

[Miriam]

autismus lvl over 9000

[pc2005]

Děsná škoda, že Microchip nedělá PIC32MX ve větším DIL pouzdře a/nebo s externí paměťovou sběrnici. Ten MIPS co je v PIC32MX by si Linuxem rozuměl krásně.

[Pavel Píša]

Pokud by se našlo dost zájemců aby se to zaplatilo, tak vyrobit desky s piny dostupnými pro nepájivé pole nebo bastlení pro nás není problém. Kolega z naší firmy komplexní systémy s PIC32 navrhuje a v stovkách se montují do zařízení. Šlo by třeba udělat něco jako MBED LPC DIL nebo po obou stranách dvouřadé lišty, aby se dalo vyvést více signálů.

U PIC32MX ale nevidím žádný čip s externím interfacem a MZ má sice 512 KiB SRAM, a externí interface, ale ten neumí dynamické paměti. Pro Linux to nemá smysl. Pro RTEMS paráda. Pro profi věci má třeba podobné parametry pamětí na čipu řada Hercules TMS570 a spol od Ti s Cortex-R4F, na kterou dáváme dohromady podporu pro jiné firmy ve škole. Výhoda je, že to je rozšířenější ARM, ale to je o dost dražší záležitost a desky s téměř 400 ploškami pro BGA a osmi vrstvami také nejsou v cenové kategorii na hraní.

Pokud chcete něco na Linux s MIPSem, tak je asi nejlepší Linino, může to mít tvar DIL, má to WiFi, základní modely i AVR pro Arduino sketche (Aghr) ale nemusí se to použít. Kdo by to chtěl jako inteligentní prach (senzorové sítě) tak může nakoupit po padesáti Chiwawa destičky pro napájení na vlastní základ. Pro testování jsou i tyto mikro modulky dostupné osazené na několika základovkách. Např.

http://www.linino.org/modules/chiwawa/

Jinak si myslím, že na hraní i na menší aplikace teď MBED povede.

http://mbed.org/

LPC a další Cortex-M mají zatím méně paměti na čipu, takže i ten RTEMS s plným síťovým stackem a větší aplikací znamená přidat externí paměť.

[daemon]

Ony existují redukční PCB z toho SMD pouzdra na DIP a možná by to pasovalo do nepájivého pole. Třeba toto http://www.ebay.com/itm/2pcs-QFP-TQFP-LQFP-FQFP-32-44-64-80-100-to-DIP-Adapter-PCB-Board-Converter-/251555946697?pt=LH_DefaultDomain_0&hash=item3a91e720c9

[pc2005]

Jako na rozteč asi OK, ale breadboard jsou řádky. Jinak adaptéry TQFP na DIL samozřejmě jsou, ale to už není ono .

[R]

Podobne upraveny Linux by mohol fungovat aj na Sinclair QL - ten ma rovnaky procesor.

[TM]

A navíc zajímavou periférii: 2ks vestavěných Microdrivů. Vsadím se, že pro ty blokové ovladače do jádra ještě nikdo ani nezkusil napsat
Mám doma ale pro QL ještě na disketě port Minixu 1. Takže první ~Unix by to na něm nebyl.

[Radovan Garabik]

A navíc zajímavou periférii: 2ks vestavěných Microdrivů. Vsadím se, že pro ty blokové ovladače do jádra ještě nikdo ani nezkusil napsat

s/blokové/páskové/

[d.c.]

I paskove jednotky jsou blokova zarizeni...

[R]

Nepovedal by som:

crw-rw---T 1 root tape 9, 128 Nov  3 09:18 /dev/nst0
^

[d.c.]

Dobre, tak zalezi na implementaci, spravneji tedy "mohou byt": $ ls -alh /dev/st0 brw-rw---- 1 root operator 5, 0 May 3 2011 /dev/st0

Je pravda, ze kdyz se pristupuje na pasku primo, tak je to znakove. Ma to v Unixu dvoji interface.

[TM]

Vzhledem k tomu, že Microdrive cartridge jsou tvořeny nekonečnou smyčkou a od začátku byly navrhovány jako náhrada disket, měli bychom se na ně dívat jako na bloková zařízení a ne jako pásku do streameru.
Alan Cox si teď hraje s implementací Unixu na CPU Z80 , není důvod, proč by to nešlo naportovat třeba na ZX-Spectrum 128. Třeba se nějakých ovladačů pro Microdrive přece jen dočkáme Navíc je to Angličan.

[daemon]

Mimochodem, pro MC68k existuje i MMU v samostatném pouzdře. Např. NetBSD nebo OpenBSD existují mj. pro hp300, sun3 a další platformy založené na Motorole, takže plnotučný Linux asi taky nebude problém.

[Pavel Píša]

Pokud to není alespoň 68010, tak je možné stránkování s 68451 nebo 68851 MMU využít pouze pro mapování fyzické paměti a ochranu. Pro swapování je MMU nepoužitelná protože 6800x neumí obsloužit výjimky precizně, to znamená, že se neumí po výjimce způsobené chybějící stránkou vrátit a kód spustit znova. Problémem je pravděpodobně především o instrukci zpožděný zápis a některé komplexní instrukce. Až 68010 umí při výjimce na systémový zásobník uložit dostatek stavových informací, který umožní nedokončené přenosy "přehrát". Slyšel jsem nějakou story, že u prvího systému se stránkováním a 68000 to řešili tak, že při indikaci výpadku stránky z 68451 zastavili procesoru hodiny a s využitím druhého pomocného procesoru (Z-80) stránku dohráli z disku a pak hlavní CPU zase pustili.

[daemon]

Mezi tím jsem se dočetl, že Sun nepoužíval 68451, ale nějakou jejich MMU. A v těch unixových stanicích, byla stejně minimálně 68020. 68010 mám v šuplíku a další ty integráče se dají sehnat přes eBay. Už si nějakou dobu pohrávám s myšlenkou, že si postavím nějaký ten retro počítač.

[pc2005]

Jinak na aukru se už dost dlouho dobu nabízí 68040, sice v PGA, ale možná by šel znásilnit nějakej socket z 486 .

[Kvakor]

Pokud si to dobře pamatuju, tak i u x86 se v některých specifických případech u vyjímky uložila na zásobník jiná adreasa než adresa instrukce, než jí způsobila (mám pocit, že se uložila adresa následující instrukce), tudíž pokud ji obsluha měla rozumně obloužit, tak musela zpětně analyzovat předcházející kód a upravit návratovou adresu. Nejspíš by něco takového šlo i v tomto případě, ale narozdíl od toho hardwareového řešení s hodinamy by byla softwarová obsluha výpadku dost pomalá, což vzhledem k tomu, jak moc se využívá stránkvání na žádost, mělo dost velké dopady na výkon.

[Michal Kubeček]

Záleží na tom, o jaký typ výjimky (trap/fault) se jedná; je ale jednoznačně zdokumentováno, která výjimka je kterého typu (tabulka je např. tady). Obecně se použije adresa instrukce, která výjimku způsobila, (fault) v případech, kdy má smysl něco provést a instrukci zopakovat; typickým příkladem je výpadek stránky - stránka se může např. načíst ze swapu a po návratu se instrukce zopakuje.

[Petr Ježek]

Jo, to Motorola ještě uměla vyrábět něco, s čím šlo spolehlivě pracovat bez dodatečně funkce kamen - nízké takty byly pověstné.

[Michal Kubeček]

Ještě na 386DX-40 od AMD jsem při plné zátěži bez problémů udržel prst a nebyla ani horká. (Pro později narozené: tehdy se ještě na procesor nedával chladič, natož větrák.)

[Käyttäjä 11133]

Kacíř!!! Upálit! :)

[xkucf03]

To jako že si mám připadat staře, když pamatuji 386?

[R]

Ani na 486DX sa este nedaval chladic. Videl som ho prvykrat tusim az na DX2.

[R]

Inak tie procesory funguju na 5V, netreba ziadne blbe menice napatia na doske :D

[Michal Kubeček]

To je možné, já pak měl až DX4-120 a ta už ho měla (z dnešního pohledu ovšem směšně malý).

[pc2005]

Ono to záleží i na voltáži, DX4 už měly 3.3V a to přece jen ten tepelný odpad sníží. Taková AMD 5x86-133 v lepším provedení pravděpodobně nepotřebuje chladič ani větrák (jsou dvě verze, jedna s popiskem: "heatsink and fan required" a druhá bez). Navíc má tak provozní teplotu ~50 stupňů (s minichladičem v těsném notebooku) a v datasheetu bylo snad až 85 stupňů jako limit.

Já měl chladič i na nějaký ořezaný 486, co byla zapájená na PCB, uměla jen 16MB RAM a neměla FPU (si pamatuju, že šlo krásně cítit jak se rozehřívá při bootu w95 ).

[R]

To so 16MB max. bola asi IBM 486SLC.

[pc2005]

Jo nejspíš jo.

[Václav "Darm" Novák]

Fuj. Ani se na tom nedalo pořádně ohřát kafe jako na IQ 151.

[Michal Kubeček]

Netrvalo ale dlouho a procesory začaly být použitelné i pro kulinářské účely.

[Václav "Darm" Novák]

No jo, ale to se člověk musí vrtat uvnitř. Nešlo by udělat něco jako přepínatelný chladič? Horizontální case, heat pipes vedoucí na plotnu s odnímatelnýma žebrama na vršku case. Ráno člověk sundá žebrování, připraví si snídani…