Ersätta SD med UFS?
Ersätta SD med UFS?
För några år så lancerades ett nytt minneskort UFS, både som fastlött chip och externt kort. Samsung drivande.
Från början hade SD SPI som interface, sedan ett snabbare eget interface men det nådde även det ett tak tycktes det.
Så för några år sedan kom UFS och det används nu enligt uppgift istället för eMMC i moderna mobiler, men det var tänkt att det även skulle ersätta SD för externa kort men ingen verkar införa det. Jämfört med moderna SSD / M.2 är SD löjligt långsam, något behöver hända.
Kolla UFS på wikipedia.
Någon som vet?
Från början hade SD SPI som interface, sedan ett snabbare eget interface men det nådde även det ett tak tycktes det.
Så för några år sedan kom UFS och det används nu enligt uppgift istället för eMMC i moderna mobiler, men det var tänkt att det även skulle ersätta SD för externa kort men ingen verkar införa det. Jämfört med moderna SSD / M.2 är SD löjligt långsam, något behöver hända.
Kolla UFS på wikipedia.
Någon som vet?
Re: Ersätta SD med UFS?
Att ersätta ny interface istället för något som redan finns tar tid - speciellt när det är så mycket som ändras på en gång, fördelarna för liten för de flesta så är viljan låg och programmerare lata.
Man kan klanka på att SD:s gränssnitt kanske är för långsam - men idag så är det inte gränssnittet i eMMC ännu som bromsar utan hur geometrierna av flash-minnen byggs upp - hur många parallella kanaler som kan arbeta samtidigt då flash-minnen egentligen inte är speciellt snabba och ännu mer långsamma blir de med QLC-celler och man försöker dölja detta ur användarsynpunkt med snabbare mellanlagring i RAM och SLC-Flash eller nyttja med grov-programmering på ledig oanvänd flashyta och sedan stuva om för högre packningstäthet.
Till detta skall man stacka allt detta på en reda mm-tunn microSD med minnesmängd norr om 128 GiB med en stor kontrollerchip i SSD-klass, kanske över 100 MiB i RAM samt så strömsnål att det inte kappar pga. för hög värmen (vilket är det största problemet - att kyla grejorna när det arbetar snabbt och helt klart bättre förutsättningar när det är monterat som eMMC på ett kretskort).
Redan idag är en standard SD-bricka mycket bättre förpackningsformat för snabbhet över längre tid och mer avancerade kontrollers än dito på µSD av just orsaken att det sistnämnda kappar snabbt pga. för hög värme samt sistnämnda använder mindre och enklare kontrollers - också av värme och storleksorsak...
System-ship tillverkarna styr också mycket av det och idag är det egentligen bara qualcomm och med sin snapdragon som tex. har stöd för UFS i sin bidrag till uboot.
Att kunna boota sin embedded på en ny minnesprotokoll är nästan grundförutsättning för att någon skall börja intressera sig att spendera tid på detta då det dessutom hanteras annorlunda gentemot en välbekant och under åren många lager påbyggt eMMC-ekosystem sedan tidigare iom. att i UFS kör man med SCSI-kommandon direkt till minnet istället rent tekniskt - vilket iofs. är bättre då alla moderna embeddedsystem med linux/BSD/unix använder SCSI-kommandon som mellan-lager vid all kommunikation nedåt lagringsmedia.
Sedan en väldigt stor brist för att man skall bli medvetande om tekniken utöver motsvarande eMMC - är att idag finns det ingen definierad kapsel och hållare för dessa UFS-chip (åtminstone inget jag hittade vid en snabb sök) - skall man locka utvecklare på samma sätt som faktiskt skett med RPi på enormt många områden så _måste_ det finnas utbytbara minnen i hållare, och att de med helst standardadapter också går att koppla till PC/laptop med deras xMMC-läsare eller via USB - annars glöm det.
Skall man lansera ny minnesformat som är tänkt att konkurrera med tex etablerad eMMC-format så måste man tänka precis hela vägen - både med tjockt lager gratiskod och redan fungerande libbar - fritt att användas av all utan licenser, att få system-chiptillverkarna att hoppa på det, fixa uboot i all embedded, definierade fysiska kapslingar som är borttagbara och utbytbara i minst samma smidiga format som dagens SD och µSD-kapslingar (men jobba på att det kan kylas mycket bättre än dagens SD-format) - inte för fippliga och för små att hanteras samt kan anslutas med standardkomponenter till PC/laptop - allt detta måste vara klart, buggfritt och genomtestat på en gång samma dag som när det presenteras!!
En sak till som borde införas i en ev. ny kapsling - en HW-mässigt styrd skrivskydd som inte på något sätt kan hackas förbi mjukvarumässigt trots all tänkbar kännedom om systemet, utan man måste förbi fysiskt i egen hög person för att slå om denna switch... SD har en plastflärp som styr en switch i hållaren för läs-chippet - men den är dessvärre bara en rekommendation och den som hackar direkt mot läs-chippet kan ignorera den biten som sattes i registret för skrivskyddswitchen och är inget som tex. blockerar spänningsomvandlaren för skrivströmmen för chipen eller annat som är helt fundamentalt för en skrivning eller radering skall kunna genomföras...
Man kan klanka på att SD:s gränssnitt kanske är för långsam - men idag så är det inte gränssnittet i eMMC ännu som bromsar utan hur geometrierna av flash-minnen byggs upp - hur många parallella kanaler som kan arbeta samtidigt då flash-minnen egentligen inte är speciellt snabba och ännu mer långsamma blir de med QLC-celler och man försöker dölja detta ur användarsynpunkt med snabbare mellanlagring i RAM och SLC-Flash eller nyttja med grov-programmering på ledig oanvänd flashyta och sedan stuva om för högre packningstäthet.
Till detta skall man stacka allt detta på en reda mm-tunn microSD med minnesmängd norr om 128 GiB med en stor kontrollerchip i SSD-klass, kanske över 100 MiB i RAM samt så strömsnål att det inte kappar pga. för hög värmen (vilket är det största problemet - att kyla grejorna när det arbetar snabbt och helt klart bättre förutsättningar när det är monterat som eMMC på ett kretskort).
Redan idag är en standard SD-bricka mycket bättre förpackningsformat för snabbhet över längre tid och mer avancerade kontrollers än dito på µSD av just orsaken att det sistnämnda kappar snabbt pga. för hög värme samt sistnämnda använder mindre och enklare kontrollers - också av värme och storleksorsak...
System-ship tillverkarna styr också mycket av det och idag är det egentligen bara qualcomm och med sin snapdragon som tex. har stöd för UFS i sin bidrag till uboot.
Att kunna boota sin embedded på en ny minnesprotokoll är nästan grundförutsättning för att någon skall börja intressera sig att spendera tid på detta då det dessutom hanteras annorlunda gentemot en välbekant och under åren många lager påbyggt eMMC-ekosystem sedan tidigare iom. att i UFS kör man med SCSI-kommandon direkt till minnet istället rent tekniskt - vilket iofs. är bättre då alla moderna embeddedsystem med linux/BSD/unix använder SCSI-kommandon som mellan-lager vid all kommunikation nedåt lagringsmedia.
Sedan en väldigt stor brist för att man skall bli medvetande om tekniken utöver motsvarande eMMC - är att idag finns det ingen definierad kapsel och hållare för dessa UFS-chip (åtminstone inget jag hittade vid en snabb sök) - skall man locka utvecklare på samma sätt som faktiskt skett med RPi på enormt många områden så _måste_ det finnas utbytbara minnen i hållare, och att de med helst standardadapter också går att koppla till PC/laptop med deras xMMC-läsare eller via USB - annars glöm det.
Skall man lansera ny minnesformat som är tänkt att konkurrera med tex etablerad eMMC-format så måste man tänka precis hela vägen - både med tjockt lager gratiskod och redan fungerande libbar - fritt att användas av all utan licenser, att få system-chiptillverkarna att hoppa på det, fixa uboot i all embedded, definierade fysiska kapslingar som är borttagbara och utbytbara i minst samma smidiga format som dagens SD och µSD-kapslingar (men jobba på att det kan kylas mycket bättre än dagens SD-format) - inte för fippliga och för små att hanteras samt kan anslutas med standardkomponenter till PC/laptop - allt detta måste vara klart, buggfritt och genomtestat på en gång samma dag som när det presenteras!!
En sak till som borde införas i en ev. ny kapsling - en HW-mässigt styrd skrivskydd som inte på något sätt kan hackas förbi mjukvarumässigt trots all tänkbar kännedom om systemet, utan man måste förbi fysiskt i egen hög person för att slå om denna switch... SD har en plastflärp som styr en switch i hållaren för läs-chippet - men den är dessvärre bara en rekommendation och den som hackar direkt mot läs-chippet kan ignorera den biten som sattes i registret för skrivskyddswitchen och är inget som tex. blockerar spänningsomvandlaren för skrivströmmen för chipen eller annat som är helt fundamentalt för en skrivning eller radering skall kunna genomföras...
Re: Ersätta SD med UFS?
Allt det där behöver man bara göra om man försöker lansera en produkt som försöker lösa ett problem som inte riktigt finns.
Lanserar man en produkt som är överlägsen dagens standard till ett lägre pris kommer folk byta även om det innebär en del jobb, annars är det bara att gå tillbaka till kammaren och fila på sin produkt lite till..
Lanserar man en produkt som är överlägsen dagens standard till ett lägre pris kommer folk byta även om det innebär en del jobb, annars är det bara att gå tillbaka till kammaren och fila på sin produkt lite till..
Re: Ersätta SD med UFS?
det vore riktigt bra, helst på något media som håller sig mer än i månader på säkert sättxxargs skrev: En sak till som borde införas i en ev. ny kapsling - en HW-mässigt styrd skrivskydd som inte på något sätt kan hackas förbi mjukvarumässigt trots all tänkbar kännedom om systemet, utan man måste förbi fysiskt i egen hög person för att slå om denna switch... SD har en plastflärp som styr en switch i hållaren för läs-chippet - men den är dessvärre bara en rekommendation och den som hackar direkt mot läs-chippet kan ignorera den biten som sattes i registret för skrivskyddswitchen och är inget som tex. blockerar spänningsomvandlaren för skrivströmmen för chipen eller annat som är helt fundamentalt för en skrivning eller radering skall kunna genomföras...
Re: Ersätta SD med UFS?
Problemet blir väl att kunna använda det i sina projekt... kommer säkert krävas en fpga med gigabit-transceivers... och snordyr IP.
Re: Ersätta SD med UFS?
Att använda i hobbyprojekt blir nog svårt.Andax skrev:Problemet blir väl att kunna använda det i sina projekt... kommer säkert krävas en fpga med gigabit-transceivers... och snordyr IP.
Men redan nu om du vill ha de snabbare hastighetsklasserna med SD så är det inte SPI längre, utan mer exotiska saker, men som jag förstår det så är även de nyaste och bästa SD-korten bakåtkomatibla med SPI och då långsamma hastigheter.
Re: Ersätta SD med UFS?
Om man skall använda nånting annat än 1-bits SPI på ett SD-kort, så måste man bli medlem i SD-klubben och betala royalties till dem, man behöver dessutom köpa en dyr standard av dem, för att få veta hur de gör.
- lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: Ersätta SD med UFS?
Nja, så enkelt är det inte, har jag för mig.
SD-kortet kan köra med 1-4 datalinor DDR per default, beroende på om man har licens för det eller inte.
Finns nog inga prollar som har nativt stöd för SD per se, däremot kan man köpa en SD-Host processor och använda den till IO-t, då kan man köra 4 linor DDR i full hastighet.
Just detta krånglet gjorde att jag började använda CF i stället.
SD-kortet kan köra med 1-4 datalinor DDR per default, beroende på om man har licens för det eller inte.
Finns nog inga prollar som har nativt stöd för SD per se, däremot kan man köpa en SD-Host processor och använda den till IO-t, då kan man köra 4 linor DDR i full hastighet.
Just detta krånglet gjorde att jag började använda CF i stället.
- lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: Ersätta SD med UFS?
Tomas, det kanske är dags för lite omvärldsanalys istället för att sitta parkerad i PIC-träsket.
https://www.digikey.com/products/en/int ... ageSize=25
Jag vet inte hur komplicerat det är att implementera ett fyrbits SD-interface för jag har aldrig haft anledning. Men stöd i kislet finns det ju. För en femtiolapp och uppåt.
https://www.digikey.com/products/en/int ... ageSize=25
Jag vet inte hur komplicerat det är att implementera ett fyrbits SD-interface för jag har aldrig haft anledning. Men stöd i kislet finns det ju. För en femtiolapp och uppåt.
Re: Ersätta SD med UFS?
Bara för att processorn har QPI/SQI, så är det ju inget SD-interface. QPI/SQI använder du ju mot många saker.
Det är just SD-protokollet du behöver, och det får du bara om du betalar.
Och jo, många PICar har QPI/SQI också.
Det är just SD-protokollet du behöver, och det får du bara om du betalar.
Och jo, många PICar har QPI/SQI också.
- lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: Ersätta SD med UFS?
Nä, men jag tänkte använde SD kort med full fart, dock, hittar man inte någonstans hur man förhandlar med kortet, sätter upp det för 4-bitars kommunikation etc.
Detta får man om man köper licensen.
Detta får man om man köper licensen.
Re: Ersätta SD med UFS?
Ta en stm32 med sdio interface så har st micro kod för sätta upp 4bit sdio..