 Hello everyone. Thanks for writing in this session. It's about spy memory support in Linux and you but Let me introduce myself. I'm Mikael. I'm working at bootlin. We do kind of stuff training and As part of this job, I've been involved in the port of the spy memory framework in you, but That's what I'm talking about today. So this is my second talk about the MTD sub system This is pretty much how I feel now that I know all the subsystems Hopefully having such contributions like the creation of this spy memory framework will improve things But we are not there yet So this talk is about spy memories. I will start with the spy bus What has changed to support the storage over spy buses And how we do how we support it in Linux and you would and maybe getting feedback from users if there are any in this room So let's start small with the spy bus. It's for why a bus as you know, there is one chip select per device one clock and Two data lines one from the master to the slave one from the slave to the master, which means it's a full-duplex protocol It runs at 10 megahertz, which for me is really is really high And VME people will say it's incredibly slow, but for us. It's quite okay in the embedded world Spy is good, but For storage it wasn't it wasn't enough. So people starting Thinking how we can improve the throughput first solution is to increase the the clock, of course So now we can see buses running at 100 megahertz The second solution is to increase The number of your lanes data Iolines So now we know we have a dual spy quest spy and octo spy and of course you can double the rate with a Data rate mode when you sample both on the rising edge and the falling edge of the clock Of course, all of this comes with an extra cost and it's a bit more complex to handle The fact that we use dual quad or octo modes means the protocol is now half-duplex Not full-duplex anymore The number of Iolines is device specific and there is a negotiation between the Spy controller and the between the master and the slave This is the spy memory protocol. So it's made of different cycles Upcodes address cycles dummy cycles and data in or data out cycles. This is pretty standard All of this makes spy memory commands. This is the basics of An exchange with a spy memory the opcode that is at the at the beginning Will determine what's after if there is another opcode with there are Either there are address bytes, maybe dummy bytes or that I buy data data bytes and if yes, how many This is the generic part of the spy memory protocol Of course the command set are different. What's in the cycles? we know We now know about the spine and and spino Command sets might have other ones What's pretty standard here is the fact that we need to read write erase access internal registers Those there are two registers that are pretty standard actually I don't think there is a real specification around this, but for now we've only seen chips Following this so this is great. Please guys continue like this And of course vendors can add their own opcodes if they want to add some features to their chips This is an example of a read With a know it's pretty straightforward It's just one command and one opcode tree address bytes and then the data you want to read With names It's always more complicated with names You know, you can't read bytes per bytes You have to to read a page which is usually to K for case it depends So first you have to read an entire page and put it in cache During this time you will pull a status register until the operation is done and Once this is done you can actually read the data from the cache in the spine and chip So this is the theory Let's see how it's handled in Linux first Initially spy memories were handled like was supported like any of the devices with drivers in driver slash empty devices They were made of regular spy messages on spy transfers And it worked great until we appeal people Used more advanced spy controllers that can do highest outputs and optimize things So a spinal subsystem was created and to handle the spinal command set and the The spy controller drivers the advanced ones could implement the spinal interface. Okay, so this is This was the stack at this time You had spinal controller drivers Just dealing with hardware and the spinoff framework with the dealing with the No, spinoff command set Of course for regular spy controllers People wrote a specific generic driver, which is called n25p80 It's an awful name for this because it's used for much more than one single controller But it's basically translates What's given by the spinoff framework into something understandable by the spy framework? So this works great until people started adding spinoff You have to know that spy memory controller the spy controllers and those who have these advanced features Do not care about what's in the old codes There are memory agnostic. So One solution could have been to write another spinoff stack Like this one but beside But this would have duplicated a lot of code Because the underlying hardware is the same so The the solution that has been brought was to use instead of you the spy Framework was to use a spy spy memory framework a new one On top of it The spinoff framework was added pretty much like the spinoff framework and the m25p80 driver and That's our example from the beginning with a read Within a read attempt So a user tries to read an empty device from user space it goes through the empty different work and then depending on the underlying Chip it will go through the spinoff framework or spinoff framework This one will handle the common set. So we'll translate the read request into the spy memory operations and the spy memory framework will act as a thing and Check if the spy controller drivers can handle such optimized Ios there is a There is a hook which is called a supported up And if yes, we'll call the hook exact up which is implemented by this driver To send actually sends the data to the spy chip spy flash if the driver cannot handle the operation The spy memory framework will know it thanks to the support of hook and Will fall back to regular spy transfers All for Linux. So what About you boot now? Well, I've been involved in migrating the spy memory Framework and the spine and framework to you boot from Linux to you boot we needed a bit of redesign because you boot use internally its own glue about around the empty devices Yeah, we spent some time cleaning all of this and also Rewriting a bit How to handle partitions? Actually the partition work is not even mainline in Linux. I need to find some time to do it So now you have Entity devices having parents until There is no more partitions and we are on the actual entity device, which is the real physical one All this work has been merged in the RC to the last RC to Because we've been a bin late Thanks to Travis CI We had some troubles getting all the configurations work So Tom Rini accepted to merge this work a bit later than than the merge window But you it's mainline now and you can trade so This was the internal stuff in you would but from a user perspective. You need to interact with your device There were three there are three comments to do that SF or spy flash named and when none Also the empty departs command actually The question was shall we add a spine on command now? and the answer is no Because we trimmed all these internal glue to use most of the entity stack and There is no real reason to not use the abstraction of the entity layer So instead we wrote an entity command which should deprecate deprecate the three other commands at the top And it acts almost like them. There isn't help you can have a look at For people handling partitions that was a question that was asked to me a few times The empty departs command will be deprecated not the deep note the empty departs viable You can still define your partitions there because it will still be used by by Linux if you put it in the in the command line But now any time you will use the empty the command to read or write your devices It will check if the empty departs or entity ID variables have changed and if yes It will automatically update the empty departitions Before doing the real job you asked for So what's next in the future? We would like to support Direct mapping it would be a great feature to have It will even allow you to execute in place code from spine and chips by no chips. I'm sorry We should convert all the spinal controllers these controllers in the red in the red thing before It's part of the past we don't want to see them anymore And now they should be migrated to use a spy memory framework and of course try not to reproduce our Previous mistakes stay memory agnostic. Do not mix everything Just a few words about the direct mapping you can create a gym up object and It will appear like regular memory for you. You can have you can do gym up read or write on it if your controller supports it it would automatically do the the spy memory operations on the spy bus and access a spine on device by none or more device and It would be transparent for you. So now what's in the pipe for the spine or side? It was recently added the non-uniform array sizes I know some spine and controllers are being migrated like the atmail and micro micro chip one on the free-skill spine or controllers the direct mapping API of course and the M 25 p80 drivers I talked about before is being renamed to be something more generic like spy-no.c Which is much more meaningful for us? This is for spy-no for spy-no now and we have the same problematic about the MAP API, of course What's missing? the support for on flash bad block table right now we rely on the bad block markers So it would be great to have a on flash but block table like with power and man's There is an on fee page parameter page in some chips We don't read it. Maybe we could optimize some things And the ecc engine there is no generic ecc engine block right now for spy-non chips We can only use chips with on die ecc Otherwise, it will not work right now with this framework But yeah, it would be great to have it for instance to have a software ecc running on your SOC And I think support for new chips is something we are looking for so if you are already using spy-non chips please contribute that the drivers for these chips are really small and Anyway, if you're using the MT 29F driver spy-non driver, it's going to be removed anytime soon Probably in the next release. So you really should migrate to this To this new framework Yeah, that's all for me Thank you for your attention. Now if you have any question, I'd be pleased to answer them now microphone Our products. We are using some fancy nor SPI chips from expansion. They have They have two dies inside one package Yes, which is as the you would version that we are using is 2017.1 which is not supported officially Is there any plan to support those fancy configurations and newer versions of you would because there are a lot of patches around? Yeah, but none of them has been mainline Preferable that patches are from silence because there are the only vendor who support those chips in their SOCs I know when you put some work has been delayed because of internal changes We discussed a lot with a yagan we with you would spy maintainer and I Can't answer you right now. I think maybe Marik is here and can No, I don't know where he is Well, I can have an answer right now with this But you can ping maybe yagan with working as a maintainer for in this area Any other question? No, okay. Well, thank you