Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - František Ryšánek

Stran: [1] 2 3 ... 57
1
Vývoj / Re:FPGA s Verilog na PCIe kartě
« kdy: 17. 10. 2021, 13:45:40 »
Díky za vysvětlivku. Já jsem si říkal, že už jsem to někde zahlédl :-) Čili je to soudělné s "front side busem" ARMových jader a v této souvislosti populární. A pokud správně chápu, výrobci FPGA nás poňoukají, že uvnitř FPGA lze snadno vytvořit "netransparentní slave bridge" z upstream PCI-e na tuto lokální sběrnici, a dál kolem ní uvnitř FPGA ledacos zařídit...

On by to muselo byt NTB, protoze v ruznych kompech mas prece jinam namapovany BAR (mezi rebooty v ramci jednoho stroje se to tedy nastesti nemeni). Ale typicky pro PCIe se to nepouziva v NTB modu - spis exkluzivnim/privatnim. PCIe-device port je master (skrze pcie-axi bridge) a zbytek logiky je slave. Jiny master tam primo nebyva, resp. zbytek zapojeni je zcela jinde (napr. na dalsim portu pametoveho radice - ktery pak prolina pametove operace z dvou masteru).

Na FPGA se to AXI resi "soft" metodou, takze zere cenne zdroje - proto ta ma analogie k java/skriptovanym vecem - mate to sice rychle slepeny, ale neni to optimalni/nativni pro to, co ten hw by umel.

Tyjo, znovu děkuji za poučnou vysvětlivku :-) opět vidíte o dost dál než já.
Já jsem termit "netransparentní slave bridge" plácnul spíš volně v tom smyslu, co dělaly blahé paměti jednoúčelové čipy jako PLX PCI9052 a příbuzní - s tím že za bridgem je "jakási lokální sběrnice". A aniž bych o tom nějak extra dumal, moje představa byla, že v tom FPGA může být natvrdo zapečené ARM jádro (nebo dvě), jak jste tady už zmiňovali, která na tu AXI taky vidí. Takže chápu, že pokud ARM je master a ten PCI-e bridge bazmek je taky master, tak jsou najednou na lokální sběrnici mastery dva, což je pikantní, pokud je AXI standardně single-master věc...

2
Vývoj / Re:FPGA s Verilog na PCIe kartě
« kdy: 17. 10. 2021, 06:54:19 »
AXI je point-to-point spojeni, neco jako "ISA" zbernice z PC.. v PIO rezimu. Adresa, Operace, data, data, data, data.

Je to typicky pro ARM:
https://developer.arm.com/documentation/102202/0200/What-is-AMBA--and-why-use-it-

AXI je sběrnice/komunikace používaná (vyvinutá?) ARMem...

Díky za vysvětlivku. Já jsem si říkal, že už jsem to někde zahlédl :-) Čili je to soudělné s "front side busem" ARMových jader a v této souvislosti populární. A pokud správně chápu, výrobci FPGA nás poňoukají, že uvnitř FPGA lze snadno vytvořit "netransparentní slave bridge" z upstream PCI-e na tuto lokální sběrnici, a dál kolem ní uvnitř FPGA ledacos zařídit...

3
Hardware / Re:Ochrana proti zkratu 12V/2A
« kdy: 17. 10. 2021, 06:34:43 »
No a to je ten důvod, proč PetrM trval na existenci napětí k tomu, aby se jistič bezpečně rozepnul. Po krátký časový okamžik, kdy elektromagnet koná práci, je třeba mít na svorkách elektromagnetu dostatečné napětí, aby ji bylo možné vykonat (musíme překonat vzniklý odpor v náhradním schématu a udržet dostatečný proud, aby vzniklá síla dokázala překlopit kontakt v jističi).

Elektromotorické napětí! Analogie toho, co se děje v motoru podél vzrůstajících otáček. Hergot skoro mám chuť si to vážně oměřit. Skop mám, různě tvrdé zdroje 12/24/48V taky, měřící bočník 10 miliOhmů jsem bastlil posledně, nějaký jistič v šuplíku najdu, vhodný omezovací odpor v desítkách až stovkách miliohmů poměrně snadno zaimprovizuju (abych neměřil děje na vlastním odporu vedení). Očkávám, že nejprve bude vidět přímý efekt reakce cívky na skokový nárůst proudu (tam samozřejmě napětí vyskočí). Pak by měla proběhnout nějaká "práce". A až kontakt rozepne, vzniklý EM pulz a jiskra to měření taky slušně zaruší.

Že bych do výpočtů chtěl tahat gyrátory apod., na to se můžu krajcvajc, moje vzdělání na to nestačí :-)

Připodotkl bych od stolu snad jenom tolik, že cívka jističe má poněkud menší počet závitů a větší průřez než cívka relé - takže podle palce, pro vykonání podobné práce bude poměr napětí/proud příslušně poněkud jiný :-) Osobně odhaduji, že budu mít trochu problém, elektromotorické napětí v tom smetí na obrazovce rozpoznat, a že bude maličké.

4
Vývoj / Re:FPGA s Verilog na PCIe kartě
« kdy: 16. 10. 2021, 22:12:05 »
Že se k tomu DMA ještě vracím: rychlý Google mi vrátil úhlednou produktovou stránku u Xilinxu s odpovídajícím IP modulem (obsahuje dokonce video intro - vypadá to báječně, nevím nakolik je to pornografie) a pak o něco méně boží appnote od Altery. Ty hotové bloky jsou boží, skoro mám chuť si začít hrát :-)

Osobně jsem s DMA nikdy nic netvořil, protože veškerý hardware, který DMA používá, jsem dostal s hotovými drivery, a když jsem tu a tam patlal nějaký driver pro IO karty, tak ten hardware DMA neuměl. A moje HW bastlení na koleně je o tři ligy níž.

Pokud správně chápu, periferie může sypat data skrz DMA do libovolně velkého okna v hostitelově RAM, aniž by dotyčná periferie potřebovala mít stejně velký kus RAMky onboard, ze kterého to servíruje. Vůbec ne - periferie může mít interní storage klidně jedno slovo (32b nebo 64b) a prostě do toho DMA sypat vzorky jak přijdou, pokud chodí dost rychle. Trochu to přeháním, ale pointa je, že při DMA periferie nemusí mít na své straně buffer stejně velký, jako je alokované okno v hostitelově RAM (tam je obvykle prostoru relativně dost). A samozřejmě ten přenos je nadrobený na transakce o velikosti "max payload", protože při ultra-dlouhých přenosech by se nedostaly k lizu interrupty (MSI) apod. Osobně bych intuitivně mířil minimální velikost DMA přenosu cca na cache line size (granularita a zarovnání)...  Trochu jsem zagooglil kolem DMA a souvisejícího memory managementu v Linuxu a našel jsem hezké čtení, dvě kapitoly z knížky od Jona Corbeta. Dá se říct, že těžkou práci na straně hostitele udělá Linux za Vás :-)

No a ten IP modul od Xilinxu je k dispozici včetně example driveru pro Linux. Zkompilujete zdroják, loadnete driver, example utilita běží = DMA funguje. Pokud Vám to čtení od J.Corbeta připadá složité, teoreticky ho nepotřebujete :-)
Ony ty IP moduly umí zřejmě i SG-DMA... žůžo. Aspoň na papíře.

BTW, co je zač AXI ? Nějaká lokální sběrnice / privátní adresní prostor, typický pro Xilinx FPGA?

5
Vývoj / Re:FPGA s Verilog na PCIe kartě
« kdy: 15. 10. 2021, 11:26:02 »
...je potřeba, aby FPGA ten 32MB "balík" vidělo naráz? Jako že data uvnitř toho bloku spolu souvisí a jsou potřeba ke zpracování? Protože pro efektivní PCI-e DMA přenos by stačil mnohem menší blok, střelím od boku třeba 1 kB...

BTW OT: ten expanzní konektor na kartách, to je FMC bus? Jako tady? Jasně, pro Vaše potřeby irelevantní...

6
Vývoj / Re:FPGA s Verilog na PCIe kartě
« kdy: 15. 10. 2021, 11:12:01 »
Alternativne nejake vetsi FPGA s hard ARM core, nicmene s tim mam nulove zkusenosti, nikdy jsem s tim nedelal. https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html

Toto není můj obor - jenom z doslechu od jednoho dodavatele vím, že používají Altera Arria. A že na Zynq před lety taky koukali, ale tehdy byl dost rozdíl v komfortu a dotaženosti vývojových nástrojů (softwaru), Arria vyhrála na celé čáře...

7
Hardware / Re:Ochrana proti zkratu 12V/2A
« kdy: 15. 10. 2021, 10:56:30 »
Hergot - jdu pozdě, a možná ještě dobře že tak ;-)

@PetrM: netušil jsem, že se tu vyskytuje odborník na tuhle oblast. Popravdě si s jištěním stejnosměru delší dobu lámu hlavu (bezpečné malé napětí), a přestože se kolem toho pohybuji zhruba v branži, zatím jsem nenarazil na někoho, kdo sype zkušenosti a vysvětlivky takhle z rukávu. Asi se pohybuji příliš daleko od R&D = příliš blízko ke koncovému nasazení a polním dráteníkům...

@PanVP: nabízím vysvětlivku ohledně "výkon při 2A na 230V je přece úplně jiný než na 12V, tak jak ten jistič může fungovat při úplně jiném napětí". Pomiňme otázku, zda se jistič chová, z hlediska reakce na větší nadproud, jinak na stejnosměru a jinak na střídavině. Řekněme, že použitému elektromagnetu je to jedno. (Tepelné ochraně je to jedno tutově.) Mimochodem pokud správně chápu, tak elektromagnet reaguje až při radikálně vyšším nadproudu, na poměrně citelném násobku jmenovité hodnoty jističe. (Pro lehčí přetížení funguje tepelná ochrana, a funguje pomalu.)
Klíčová řečnická otázka k Vašemu zvážení: kolik vývodů má jistič? Inu má dva. Jak se do obvodu zapojuje? Inu v sérii se zátěží, obvykle do fázového/živého vodiče (nikoli do pracovní země). Takže máme jistič, připojený svými jedinými dvěma vývody na "živý potenciál".  ... Takže: *kde* se ten jistič dozví, kolik je na té fázi Voltů, když nemá svorku pro *zem* ? :-D

Osobně se dlouhodobě zajímám o řešení inrushe v systémech bezpečného malého SS napájení - rychlá elektronická ochrana proti nadproudu je vedlejší vlastností aktivních zapojení. Zároveň lze tímto vyřešit i jistou míru přepětí. Koho by zajímala tato analogová poezie, už jsem se na to téma jednou poeticky rozvášnil... a musím smutně přiznat, že se pokládám za dosud spíše naivního umělce. Nejsem vývojář, jsem technická podpora v aplikační oblasti. V elektronické ochraně by mělo být cílem návrhu, aby měřící odpor ("bočník") v sérii s živým vodičem za normálního provozního stavu pokud možno netopil, zároveň aby mu jeho tepelná kapacita umožnila přežít určitou definovanou míru přetížení - v podstatě jde o násobek čas * proud^2. Samozřejmě krát odpor bočníku. Pokud je primárním účelem ochrany omezit inrush = zajistit řízené nabití silového kondíku omezeným proudem, tak vlastně tyto ohledy platí především pro sousední silový spínací prvek (nejspíš MOSFET) a samotný bočník je činností tohoto FETu chráněn proti tepelnému přetížení... Rychlost reakce elektronické ochrany je o pár řádů kratší, než u tavných pojistek a klasických el.mag. jističů, takže ty "absorbované energie" nemusí být kdovíjak vysoké.

Bezpečné malé DC napájení má sklon ukolébat člověka do klidu, že to přece nekope, tak se nemůže nic stát - ale ono to může být i pěkně nebezpečné, hlavně v centrálních rozvodech, kde je zdroj schopný dodat do zkratu desítky nebo stovky A, třeba i krátkodobě (koďan na výstupu zdroje), nebo hůř dlouhodobě (baterka). Jištění a selektivita jištění na silových větvích takových rozvodů je dost důležitá věc. Hrozí požár. Ve srovnání s tím jsou přechodové jevy při inrushi spíš k pousmání...
V této souvislosti palec nahoru původnímu tazateli za tohle téma! Že se nad tím zamýšlí.

Já bych chtěl ještě upozornit, že spínací prvky na AC a na DC můžou být dost jiné kvůli zhášení oblouku, který u střídavého zhasne snadněji protože průchod nulou. Na 12V to bude ještě v pohodě, ale třeba na 48V už by mohl ve „střídavém“ jističi hořet oblouk.
Zhasnutí oblouku může být problém klidně už na 24V DC. Hnijou kontakty relátek a tak. Obecně kontakty ve spínačích/relátkách mají na DC zkrácenou životnost, pokud pro tenhle provoz nejsou explicitně navrženy.
Svoje o tom vědí solárníci včetně amatérů na malých napětích.

Jinak já osobně bych použil něco takového:
http://robodoupe.cz/2013/jednoducha-elektronicka-pojistka/

Tohle je klasické zapojení rychlé ochrany výstupu, které se používalo ve výkonových audio zesech třídy AB = než je převálcovala třída D (PWM). Upozorňuji, že tahle pojistka neprovede "reverzibilní vypnutí do nuly", ale pouze omezení proudu na konstantní hodnotu (ořez/clipping) - takže ve stavu "ochrana aktivní" tento obvod trvale udržuje úbytek na měřícím výkonovém odporu (v sérii s emitorem silového tranzistoru) a především silový tranzistor absorbuje při zkratu značný trvalý výkon: v zásadě napětí zdroje (nebo kam se zdroj prohne) krát protékající omezený proud. Jako inrush limiter to není úplně marné.

Uvedené zapojení lze dále vylepšit. Jednak pokud se namísto přechodu "báze emitor" (otvírací napětí cca 0.6 V) použije diferenciální zesilovač, dá se jeho výstup navázat na komparátor se stavitelným prahem pro omezení = na měřícím odporu může být ve stavu "proudové omezení aktivní" mnohem menší úbytek než zmíněných 0.6V. Také lze doplnit nějaký klopný obvod, buď časovací (auto-restart) nebo bistabilní s resetem (možnost ručního restartu). Přesně tím jsem se zabýval ve svých analogových hrátkách (odkaz výše).

...
S obloukem souvisí vypínací schopnost. To je proud, který jistící prvek dokáže bezpečně rozpojit. A tam jsou sakra rozdíly. Třeba pokud jde o přístrojovou pojistku 5x20, tak ty skleněný atrapy z hobbymarketu / vesnickýho elektra F1A/250V mají obvykle vypínací schopnost 43A. Pak se drátek rozprskne po skle tak, že se vytvoří vodivá vrstva a jede se dál. Poctivá keramická, pískem plněná od Omegy má garantovaných 1500A, ale cenově je to trochu jinde a laik rozdíl nepozná... Btw, pokud mám u zásuvky jistič B 16A, tak ten má vypnout při 48-80A, takže levná skleněná pojistka je spíš na ozdobu.[/li][/list]
...

S tou trubičkovou pojistkou... homogenní kovová vrstva zamrzí, ale od určitého proudu bych spíš tipoval, že prostě zůstane hořet oblouk (v kovových výparech původního tavného drátku nejspíš o to radostněji) a pokud trubička nebouchne a oblouk se nesfoukne, hoří tam radostně až dosmrti :-) Resp. dokud funkci pojistky nesplní nějaká jiná část obvodu. Nadřazená ochrana, slabší a vhodně situovaný vodič, žárovka která původně prdla jako první, požární poplach apod. (Odpusťte baví mě spekulovat :-)

Těsnopisně příhoda z natáčení: v divadelním stmívači, který je jištěný 13A jističem char.C, PWM spínač je 40A triak, v souvislosti s prdnutím žárovky 230V/1kW ten triak dost často odejde (obvykle zůstane v sepnutém stavu už navždycky). Upstream trafo je po drátech asi 20 metrů daleko. Hypotéza: při náběhu žárovka žere násobek ustáleného odběru (třeba o řád), takže se triak nažhaví, aniž jistič stihnul hnout brvou - a když v tu chvíli žárovka prdne, což vede s jistou pravděpodoností ještě víc směrem do zkratu, tak se tomu triaku prostě roztaví vnitřnosti. Teprve poté vybaví jistič (a obvod úspěšně odpojí). Vyměníte žárovku a zjistíte, že svítí trvale. O trochu silnější stmívač snese praskání žárovek bez problému - má 20A tavné pojistky (10x38mm) a tuším 100A triakový modul. Tzn. toto stačí pro bezchybný provoz se žárovkami, které mají jmenovitý ustálený odběr asi 5A...

8
Server / Re:Zabezpečení výrobních zařízení v továrně
« kdy: 11. 10. 2021, 00:00:22 »
Proc resite pasivni a low power reseni? V prumyslu neni nad poradnej vetrak :)

Souhlas - když je potřeba výpočetní výkon, chce to přiměřeně chladit.

Ale pokud stačí nějaký kozí dech, který není problém uchladit pasivně, tak je výhodou vyšší spolehlivost "solid state" řešení.

9
Sítě / Re:Návrh internetové sítě
« kdy: 10. 10. 2021, 10:39:31 »
Dovolte věcnou reakci - pár námětů, "co teda s tím", pokud má tazatel čas a náladu googlit si buzzwordy a trochu se expresně dovzdělat:

Ještě k požadavku "aby ředitel viděl všude a ostatní jenom co mají dovoleno" (nechci pouze planě řečnicky slovíčkařit): Už tu jiní zmínili, že to nesouvisí ani tak s topologií sítě (dobrá, ať si tam ten firewall mezi ředitelnou a zbytkem LAN klidně použijí) jako spíš s uživatelskými právy v zúčastněných OS na serveru a klientech.

Takže bych navrhoval fileserver = Windows Server (nebo ekvivalent), nechť na tom běží doména (AD) kvůli správě privilegií, a dál tradiční schéma: řadové užovky dostanou neprivilegované účty a každý "home adresář" na serveru plus třeba nějaké další shary kam můžou všichni nebo podle tříd / oddělení / skupin, jenom "ředitel" bude mít administrátora (nebo obecně v AD nějaký účet který smí koukat všude).

Ale: koukat všude kde? No tradičně v rámci fileserveru. V tomto bodě "chci" vzít tazatele/zadavatele za slovo :-)

Když se zeptám: a co ty klientské stanice? Řekněme, že nejsou diskless. Že mají lokální disk. Třeba mají nějaký lokální prostor, kam užovky taky můžou hnojit - a kam by se říďa/admin chtěl na dálku z tepla své pracovny podívat. To by znamenalo, dát na ten lokální prostor na klientech taky práva dle schématu v AD (řadový user / superuser) a vystavit to jako share? Nikam jinam na lokále by užovky nesměly. Případně by říďa mohl na klientech *všude* skrz implicitní share C$ a svůj nadčlověčí účet v AD? Fungovalo tohle někdy? (Nebo je k tomu třeba lokální admin? (Funguje C$ ještě?))
Jinak samozřejmě admin může na klienty přes "vzdálenou pomoc" (= vzdálenou plochu RDP) - to funguje rutinně...

Za mě provozovat LAN traffic z klientů na fileserver skrz firewall... nebude ten FW úzkým hrdem? Jasně, záleží jaký FW... jsem konzerva, přijde mi to trochu přehnané :-) Jasně pokud se síť rozdělí více VLANami třeba mezi učebny / kabinety / ředitelnu, tak tam minimálně L3 router být musí. Ale pokud nejsou požadavky na vyšší firewallovou akrobacii, tak tam dát prostě trochu slušný "L3 switch", který má HW akcelerovaný L3 forwarding a třeba i základní access listy... bude to mít wire-speed průchodnost, dá se tím zaříznout nežádaný provoz mezi VLANami navzájem (na bázi least privilege) a díky doméně bude fungovat cross-subnet přístup k windowsím sharům... Základním filtrem co zvládne L3 switch se dá zabránit třeba háčkování sborovny a kabinetů z učeben = triviální "script kid" útoky, hádání hesel na ad-hoc shary na učitelských pracovních stanicích, přímé šíření malwaru apod.

Přemejšlím, co všechno by L3 switch se svým relativně hloupým filtrováním dokázal zaříznout mezi stanicemi uvnitř společné VLANy. Třeba navazování TCP relací, nebo paušálně veškerý lokání provoz s některými výjimkami? (arp, podmnožina ICMP) Akorát by se takto striktní bezpečností odstranila dost výrazná část vzdělávací hodnoty školní LAN ;-)

V rovině bezpečnosti třeba ještě přidat na dedicated stroj nějaký IDS který bude hlásit port-scany apod., pokud je šance, že bude někdo mít čas pošilhávat po jeho výstupu a řešit false positives...

Pro úplnost: samozřejmě nějaký košer firewall mezi celou tou "routovanou a filtrovanou LAN sítí" a vnějším světem = do divokého internetu. Ani by sám firewall nemusel vidět do jednotlivých VLAN - pokud má jako default route pro jednotlivé VLANy/subnety sloužit L3 switch. Ale třeba taky mohl (vytáhnout VLAN trunk z LAN switche do firewallu)... to je na zvážení správce/projektanta.

Je to lebeda, kolik se toho dá dneska uroutovat a ufiltrovat na 2.-5. vrstvě "relativně obyčejným switchem" :-)

EDIT: možná ještě dva odkazy na obrázky k fyzické topologii. Text ignorujte, pokud je nad Vaše momentální schopnosti.

10
Sítě / Re:Jak řešit internet v malém městě? 50mbps
« kdy: 08. 10. 2021, 20:35:35 »
Ohledně Němců a plánování, klobouk dolů před jejich vysokorychlostní železnicí, Deutsche Telekom je taky zajímavá firma, ale nejde mi do hlavy ta jejich elektrická přenosová soustava v kontextu OZE :-) To fakt úplně nenaplánovali, a stavba nových vedení se protahuje... sry za OT.

11
Sítě / Re:Jak řešit internet v malém městě? 50mbps
« kdy: 07. 10. 2021, 22:55:32 »
široce dostupný na vesnicích. Řekněme jak kde.
Ano, jak kde. Paradoxně Poláci, Maďaři a Rumuni jsou na tom líp, začali stavět komplet novou infrastrukturu už na FTTH.
Co je důležité je, že tyto země mají jasný plán rozšíření a modernizace.
My plán nemáme, peníze na to nemáme, zato máme stavební zákon, co to v podstatě blokuje.

Dík za věcnou vysvětlivku - zjevně jste v obraze :-)

Fakt je, že u nás se v devadesátých letech natahalo poměrně dost měděných telefonních párů poměrně moderním materiálem, tím pádem jsou dodnes v poměrně dobrém stavu, a tím pádem se je CETIN a kamarádi snaží dojit dokud to jen jde.

Němci pokud vím rozjeli koncem devadesátek dost ve velkém ISDN = asi mají taky dost mědi zakopané v zemi, a stejný problém.

Pokud někde měli telefonní infrastrukturu fakt zanedbanou, a budují rovnou FTTH, tak jím hnusně závidím :-) a politické konotace nechme stranou...

12
Sítě / Re:Jak řešit internet v malém městě? 50mbps
« kdy: 07. 10. 2021, 17:14:53 »
Já si zase troufnu zpochybnit, že je gigabit na optice v Německu reálně široce dostupný na vesnicích. Řekněme jak kde. A ten desetigigabit v Polsku... :-) Ve skutečnosti většina rozvinutých tržních ekonomik zhusta brečí, že by chtěli na venkově aspoň kvalitnější ADSL.

13
Server / Re:Zabezpečení výrobních zařízení v továrně
« kdy: 07. 10. 2021, 15:54:17 »
Tohle je v krabičce a má to Braswell, zbytečně čtyřjádro TDP=5W, jako option to může mít TPM. Není to úplně obskurní, protože to má SD slot a SATA. A nemá to průmyslový rozsah teplot... nenaděláš nic.

14
Server / Re:Zabezpečení výrobních zařízení v továrně
« kdy: 07. 10. 2021, 15:43:11 »
Obecnou vlastností několika generací NUCů s plnotučnými procesory je vysoká teplota. Do průmyslu nedoporučuji. Na uvedené použití skutečně stačí to nejslabší, co vyhoví účelu a nebude moc hřát. Pokud ne malina (ta umí hřát, a není moc průmyslová) tak třeba nějaký Vortex (x86 32bit) nebo spodní konec Intelových ATOMů. Pokud je zároveň výhodou "security by obscurity", tak třeba nějaký COM/SOM modul, který bez devkitu ani nepřipojíte k displeji. Může to mít onboard eMMC flashku jako bootovačku, takže nehrozí "vytáhnu SDčko a ve čtečce si ho přečtu". Onboard je taky RAMka a aspoň jeden Ethernet. Tuším jsem viděl takovou desku s dvoujádrovým asi 1.3 GHz BayTrailem nebo Braswellem, formát desky Qseven COM, samotný SoC žere 3-4 W (TDP), další třeba dva watty přidá RAM a LAN. Ale je fakt, že to znamená, navrhnout si nosnou desku a nechat ji vyrobit.

Jo a TPM to koukám v základu nemá... viděl jsem ho u Congatecu na jiných platformách, tuším přes SPI, což tuším z x86 vytáhnout nejde. Možná na USB.

15
Server / Re:Zabezpečení výrobních zařízení v továrně
« kdy: 07. 10. 2021, 10:56:36 »
Um. Na okraj mi tady vysvítá otázka, zda "požadavek na vyšší zabezpečení" přišel od zákazníka, nebo od šéfa tazatele v rámci dodavatelské firmy :-)

= zda je cílem chránit zákazníkova hodnotná data (designy výrobků, CAM data, provozně-výrobní statistiky apod.), nebo zabránit zákazníkovi, aby si dokázal zálohovat OS/FW a svépomocně ho opravit v případě, že hardware zmíněného "šémového RPi" jednoho dne umře. (Nedejbože klonovat/namnožit licencovanou řídící jednotku s úmyslem ušetřit za licence apod.)

V praxi potkávám oba zájmy :-)
A řešení jsou možná v obou případech podobná, protože podobné budou i "vektory útoku" = v prvé řadě fyzický přístup, znalost architektury a bootovací sekvence počítače na bázi RPi, nahraditelnost hardwaru "kus za kus". Otázkou je, zda to smí/nesmí/musí komunikovat po LAN a co je obsahem té komunikace apod.

Možná ještě třetí motiv: zabránit v neautentikovaném přístupu do firemní LAN skrz neprověřené zařízení...

Stran: [1] 2 3 ... 57