So what are you going to get out of this session? So we're going to cover a little bit of sort of learnings from standing up SAP cloud platform on Azure and using that as a case study for multi-cloud. But before we get into that, I'm just going to give sort of a brief overview of what Cloud Foundry on Azure means and kind of what the scope of it is. And then talk a little bit about sort of how you can get involved and participate in this journey that we're on. So what is Cloud Foundry on Azure? So this question comes up a lot because there's apparently still a lot of people that believe that Azure is sort of just the Windows Cloud, you know, it's only for doing building dot net applications with Visual Studio targeting Windows to run on Azure. And so people go like Cloud Foundry, that doesn't seem like it would align very well. Azure has changed, Microsoft has changed significantly and Azure has been sort of at the up leading edge of that. We've actually been working with the Cloud Foundry community and with a number of partners for about three years now to bring Cloud Foundry to Azure in a number of different forms. So we have the fully open source version that you can run on top of the Azure infrastructure. You can deploy the Pivotal Cloud Foundry in a sort of single tenant version inside of your Azure subscription from the Azure Marketplace. Or as we'll be talking about today, you can use the fully hosted multi-tenant service from SAP. And as a result of all that work that we've been doing and the partnerships that we've been working on, we actually announced at the Cloud Foundry Summit in Silicon Valley in June that Microsoft had joined the Cloud Foundry Foundation, so really putting a bow on all the work that we've done with Cloud Foundry. And the reason for it is ultimately that we want Azure to be the most open cloud. And so we want to make sure that any operating system you want to target, any framework or tool chain you want to use, any platform you want to use, including things like Cloud Foundry, that you get really a best in class experience on top of Azure. And so that's why we really put a lot of resources into that work. So with that, I'm going to call on Dmitry to talk a little bit about what SAP thinks about in terms of multi-cloud and give a little bit of background on that cloud platform. OK, so as you know, the cloud computing today is an often preferable direction for running software. And as its usage grows, the idea of multi-cloud is gaining more adoption and spread. People are asking me if I could explain a little bit what is the mention of multi-cloud and why it would be important to them. So because multi-cloud have a very broad definition and its response to different topics of cloud architecture and response to modern businesses and developer needs, it's better to explain it with some examples. For enterprise, a multi-cloud that could be a strategy that allows an enterprise to run their software where they best fit by using several cloud providers as one single solution. It allows the enterprise to meet a specific application requirements or a specific workload by consuming multiple cloud providers. And while just as long as each provider can fulfill enterprise specific needs at a given time. Another example, IT specialists may find a multi-cloud as a solution for reducing the risk of downtime or widespread data loss caused by a localized component failure. And of course, and surely the developers may use multi-cloud as an enabler to consume unique innovation technologies from different cloud providers to build great apps. So let's do a very brief overview of the SAP Cloud Platform to understand what is the role of the multi-cloud and the cloud foundry for SAP. SAP Cloud Platform is an enterprise platform as a service that offers you the flexibility to use the leading cloud providers. So while you may select infrastructure powered by Amazon, which is available in general availability, you can also select Google Cloud Platform and Microsoft Azure as an additional infrastructure and thus cloud providers available as a public beta. Regardless of which cloud providers you choose, all multi-cloud application deployments can be centrally managed and operated in one single unified cockpit. Use of adoption is very important to us. So SAP takes care of the complexity of managing and operating the underlying infrastructure accounts. So you can quickly move the applications to the infrastructure that best meets your requirements with a limited effort. If for some reason the application needed to go to another infrastructure, you can easily deploy your application to SAP Cloud Platform and another infrastructure. And to recap, for SAP Cloud Foundry, it plays a central role in a platform as a service strategy. Offering the Cloud Foundry environment helps grow SAP Cloud Platform commitment to open standards and open source technologies and provides more option to developers to utilize the richness of our platform. So Cloud Foundry allows SAP and SAP customers to use popular programming language but also to deploy applications on top of popular IS platform, hence no vendor lock-in. OK, thanks. And now Sean will talk about Cloud Foundry on Azure. All right, thanks, Dimitri. Hey, it's me. I'm back. So I talked a little bit about Cloud Foundry on Azure sort of conceptually a little bit deeper, although not too much deeper. For those who are familiar with Cloud Foundry, this picture will be fairly familiar to you. If you're new, just to give you kind of a sense of how it works, we've got the base Azure infrastructure kind of at the bottom layer. That is deployed using the Cloud Provider Interface plugin that we provide, so the Azure CPI for Bosch. Once you have that Cloud Foundry environment deployed, then you're deploying your applications onto Cloud Foundry, and you actually don't really need to worry about the fact that you're running on Azure. You're just using Cloud Foundry, and that's sort of where this whole sort of multi-cloud abstraction comes in. That's to sort of run your stateless applications. If you want to take advantage of some of the Azure backing services for storing some of your states, that's where the Service Broker API comes in. And we'll talk a little bit more about that in a bit. We've built the Azure Service Broker API as a way to connect out to Azure platform services, so some of our more popular services like Azure SQL, Azure Cosmos DB Storage, and our recently announced MySQL and Postgres databases as a service. Look at that transition. So the session is entitled Making It Real, so I think to make it real, we have to get out of PowerPoint just for a brief second. And I want to just kind of give a sense of how this looks in practice. So I mentioned the Cloud Provider Interface that we build. This is developed by Microsoft Full Time Engineers. We do it fully in the open on GitHub. So this is the project that we've been working on for, again, roughly the last two and a half or three years, have done, as you can see, 27 releases and continuing to add more functionality, integrate with new features that come out in Azure. So as we announced our managed disks offering, for example, we added support for that in the CPI. We recently integrated it with the Azure Application Gateway, which is our layer seven load balancer. And so if you go in here, if you wanted to deploy Cloud Foundry, sort of the fully open source version, you could start from here, jump over into the Bosch documentation to set up your Azure environment, and actually the easiest way to get this bootstrapped is if you go here into the Azure Quick Start templates in GitHub linked there from the Bosch documentation, this actually provides the Azure Resource Manager template that's required to stand up the Jumpbox VM, all the virtual network and storage resources that you need to be able to deploy your Cloud Foundry environment. And the nice thing is you can go right from here to the Azure portal and basically fill in just the necessary properties to stand up that environment. So this makes it pretty easy to get an initial Cloud Foundry environment set up on Azure. You'll see, you fill in some of the details you need here and you'll notice that there is an option to, this will set up initially just sort of a Jumpbox on a virtual network in Azure that you can use as you sort of your entry point to your Cloud Foundry environment and you can actually set it up to also deploy the Bosch director. So to get you up and running and once you do that, you will get a VM that looks like this where you'll get a set of resources and scripts and Bosch manifests that you can actually use to deploy Cloud Foundry. So like under manifests there are options for deploying a single VM, multiple VMs. This makes it relatively easy to get started with running the fully open source Cloud Foundry on Azure. Now that being said, there's still a certain amount of work here to bootstrap this environment. And so that's where using something like the SAP Cloud Platform comes in to allow you to get started even easier with a fully hosted service. So I'll turn it back over to Dmitry to talk a little bit about the technical details of the Cloud Platform. Please don't worry if you find this picture slightly complicated. I'm not going to talk about Cloud Foundry architecture, about Cloud Foundry architecture, about all the services and all the components you can see there. Actually, my story is about how we made the multi cloud to become a reality for SAP Cloud Platform on the case of Microsoft Azure. So in the beginning, we just started with a blueprint like that. And then after a few months, we have finished with a successful integration of Microsoft Azure into infrastructure providers family available on SAP Cloud Platform. So first of all, I want to share the general impression from our work with Microsoft Azure. When we started our exploration of Azure capabilities, we discovered Azure as a stable and mature IS. The lot features and functionality required for our platform, we're already there from day one. For example, things like wide offering of the VM and the hardware types and series. For us, it was important because every component that you can see there, is a consumes a specific amount of resources. Hence our role is to find the optimal match between the component needs and the provided IS resources. And of course, we have found ready to use the Terraform and Bosch CPI for Azure. Such readiness allows us to do a rapid delivery of SAP Cloud Platform and SAP Cloud Foundry on top of Microsoft Azure. You can find that Cloud Foundry on the diagram is one of the pillars in the overall SAP Cloud Platform architecture. It's consisting of multiple components communicating with each other. I want to put your attention that in order to run it on top of Azure, we have collected all the requirements needed for the Cloud Foundry environment and also for all the SAP services and then found the relevant counterparts provided by Azure. For us, it's a fundamental to consume all these resources using the Terraform and Bosch CPIs. My colleagues work closely with the Microsoft team to enhance Bosch CPI and to address essential functionality needed for SAP Cloud Platform on Microsoft Azure. And also last but not least, in the big data area that you can see there, we are working together with Microsoft to certify HANA machines for general availability. So I think it's a good moment to show a small demo of SAP Cloud Platform. You can scan this QR code to go into our Cloud Platform cockpit and actually let's go into it. So actually this is in our cockpit because our demo is limited in time. We have a very strict time limit. So I will skip the registration process for you and we'll go directly to the detail. So after the registration, you can get into this dashboard where you as a developer can use the Cloud Foundry environment for deploying your applications. And for example, you can see that we are providing several Cloud Providers in different regions. And for this demo, especially, I created a project, a demo project on top of Microsoft Azure using the Azure infrastructures. So after I created my account and created the project, you can get into the account overview where you can find all the relevant information like what is the name of the organization, which quota and which services you have, the API endpoint, and if you go deeper into the menus, you can reach the marketplace where you can find the common back-end where services that we are providing and other services like the application works, the HANA trial, under common back-end where services, I mean the PostgreSQL, the RabbitMQ, Redis, and other databases. So for example, my application consumes the PostgreSQL database. So I created an instance of the database and deployed the application. And also after I did the deployment, I did a binding of the PostgreSQL service to my application. So for example, after you do the binding using the dashboard, you can also go to the database or service-specific dashboards. For example, if I'm clicking here, you can see that it's all the details, all the properties, the application log. And if you are familiar with the terminal and you prefer to operate with Cloud Foundry using the Cloud Foundry CLI. So for example, you can target the environment at API endpoint. And for example, you can get the application and I can see the services. So for example, if I open the application, so it's just a very small application that should demonstrate the basic functionality of SAP Cloud Platform. So let's see what's happened under the hood. How was this done on Azure? So briefly on this side, you can see how we are doing of the deployment of the Cloud Foundry environment in other services on top of different Cloud providers. You may find in our toolbox, we are using the tools like Terraform and Bosch and also we are using the concourse for continuous integration. The central role here is it belongs to infrastructure as a code. It's a method to define infrastructure components and all their requirements in form of code. It could be a Bosch manifest or Terraform script for example. So when developer changing the code of some component and commits it to the repository, then the concourse may trigger a Bosch deployment with a specific manifest to do a component update. Because not all Cloud providers may the same, hence the challenging is to support all the diversity of Cloud technologies and the difference between Bosch CPIs, dialects. So when we are deploying the Cloud Foundry environment, we are managing all those differences to provide the same Cloud Foundry experience for customers, regardless of hosted infrastructure. So my story would not be complete without talking about multi-Cloud challenge on Azure. So as a support of different Bosch CPI dialects is a general challenge, I would like to talk about other kind of challenge but of the same level. While the capabilities of Cloud providers are mostly similar, often they are organizing the resources and differently in order to provide to those capabilities. So actually the great example of how different Cloud providers are complex, the same goals with a different design is availability concepts. On most of Cloud providers, users are ensuring availability by spreading multiple instances of the same VM role across availability zones. In other words, each zone is a represent the distant fold domain. For example, if I have a web service and I would like to have a high availability, so I may deploy at least one instance at each zone and I have to do it manually. On Azure, in contrast to other Cloud providers, users can place multiple instances of the same VM role in availability set and allow the Azure platform to automatically spread them across four domains. They say, pick out platform abstracts these differences away from you. Okay, so when we started our exploratory of Azure capabilities, we have a concern about the ease of operation of multiple storage accounts and about the overall disk performance using classic storage accounts. But everything changed with the managed disk feature release which removes the performance limit boundaries. So all concerns will dissipate after the general availability of the managed disk and the following update of the Bosch CPI that support this feature. And if I'm talking about Bosch CPI enhancement, it's a good idea to show how the Bosch CPI evolves over the time. Please put attention that most of the major updates will deliver it in a short period of time. For a half year, a new Azure functionality support landed into Bosch CPI, like managed disk feature, multiple research group support, ability to create application gateway and all other overall improvements towards developer experience, like better diagnostics or retry logic. So I think it was a very fantastic work and I think it's perfect to my story. So thank you. And now Sean, we'll talk about SAP Cloud Platform and the native Azure integrations. This is like a performance test for MacBook HDMI connectivity. Okay, so Dimitri talked a little bit about some of the challenges that we work through together to align SAP Cloud Platform's multi-cloud architecture with some of the specific design decisions that we've made in Azure and how the cloud platform ultimately abstracts most of those things away from you. So you don't have to worry about those sort of peculiarities of different cloud providers. But then there are a number of cases where you actually want to take advantage of some native capabilities and you want to have awareness of the cloud provider that you're running on so that you can actually use some of the differentiated capabilities. And so there's a couple of those that are of interest when it comes to Azure. The first is briefly mentioned before the service broker concept. This is something that I think everybody in the cloud founder community is very excited about. In fact, is growing now beyond cloud boundary into Kubernetes through the service catalog work. And so in Azure, we've built the Azure service broker that provides access to some of our most popular backing services as I mentioned before. And so you can deploy that in any cloud foundry environment including the cloud platform and use that as a way to connect your applications, your sort of cloud native 12 factor apps running in the cloud platform to stateful backing services that are running in this case in Azure. And I'll show an example of that in a second. The other is Active Directory. So Microsoft has a huge amount of assets in the identity space with Active Directory on-prem as well as our hosted version in Azure, Azure Active Directory. And so we've done work as part of that sort of ongoing work with cloud foundry to make the Azure Active Directory service integrated with cloud foundry which means that you can have your, if you have your identity, your corporate identity already managed in Active Directory and potentially federated into AAD. You can use that as your identity into your cloud foundry environment as well. So you don't have to create entirely new developer and operator identities for managing your cloud foundry environment. You can use that with the cloud platform as well. And so that's quite powerful because you can then do a single sign-on into all the different products that AAD supports including Office 365, for example. Okay, so let me jump back out of here again and do a quick demo of the Azure service broker. So again, I'll start in GitHub because again, this is a similar to the CPIs, a project that's built by Microsoft full-time engineers with contributions to the community. We do it all out in the open in GitHub. And so you can take a look here in this GitHub project and see the services that we support today. So I think there's like nine services that we provide there and we're continuing to add more all the time. And so what I'm gonna do is take advantage of this service broker to actually deploy a back-end service in Azure that I can then connect up to an app that's running in the SAP Cloud Platform. So I'll do this actually through the Azure Cloud Shell which is our in-browser CLI experience. So this gives you a full bash shell actually running inside the browser. And I mentioned we've done a number of things to integrate Azure with Cloud Foundry and one of them is we've actually pre-installed the CF CLI in the Cloud Shell. So anybody that has an Azure account can use this for free. So if you're ever sort of on the go and need to access your Cloud Foundry environment whether it's running in Azure or running somewhere else if you just need access to the CF CLI in the browser you can use this. And so what I'll do is I'm basically I've already logged into my Cloud Platform environment and you see here that I'm logged in with my corporate identity. So that's taking advantage of that Active Directory integration and I've already deployed the Azure Service Broker which just gets deployed as a Cloud Foundry application. So you can take that project that's available and get hub and deploy it as a CF app into any CF environment. And as a result, if I do CF Marketplace I can see all of the Azure Backing Services that are available to deploy here alongside some of the ones that are provided natively by the Cloud Platform. So here's Cosmos DB and Event Hubs and MySQL and so on. And so what I'm gonna do, I've got a simple Node.js application that relies on a Redis cache. And so the beauty of the Service Broker is kind of just as a developer you say I just want to have a Redis cache from somewhere I don't really care where it's coming from. In this case I'll use the one that's available in Azure. And so I can just do CF Create Service. Give it the name of the service. Add our Azure Redis cache. We'll call it CF Summit Demo. Whoops, where did I miss here? Oh, the plan name. So I'll use the basic plan. Try to save a few francs. And so what that's gonna do is actually talk through the Service Broker app to start deploying a Redis cache in Azure that I could then bind to my application. That's gonna take a few minutes that we don't have. So I'll use one that I created earlier which you can see specified here in the manifest, the CF Redis demo service. So if I just go ahead and push this application. So I'm pushing this app into the cloud platform. So it's running in the fully hosted environment provided by SAP, but then it's binding to this Redis cache service that I've deployed into my Azure subscription. And once that's completed, I will have a my Node.js application that can talk to that Redis cache behind the scenes. And there you go. It's all up and running. So if I go ahead and grab this endpoint here, put that into a new tab, you see this app. I'm available for consultation on web design after the talk if anybody needs help. So we'll just say CF Summit, let's say SAP platform. Rock submit that and that's going to get stored as a key value pair in that Redis cache behind the scenes. And as you might expect, I can pull it back. So that allows me to take advantage of some of those native Azure services in conjunction with the cloud platform managed by SAP. Okay, so let's start to wrap up. So Cloud Foundry on Azure is again something we've been working on for multiple years. We've got multiple different ways that you can interact with it. We think the cloud platform from SAP provides a great way for customers who are looking to either integrate with their existing SAP assets or have that sort of fully hosted, fully managed service where you don't even have to deal with setting up your boss director and that sort of thing. We've worked really closely with SAP over the last year so to get the cloud platform up and running on Azure it's been a really great partnership as Dimitri alluded to. We've had really quick iteration cycles between the two companies and we're really aware of and invested in this multi-cloud notion. We hear this from a lot of customers and so it's not something that we fear to go and have these conversations about how we can enable multi-cloud environments like the cloud platform. And as a result, Cloud Platform is the first multi-tenant hosted Cloud Foundry offering in Azure. So that's pretty exciting. A bunch of resources here including some of the things that we pointed to through the session. So go ahead and check those out. And with that, I think we'll open it up for a few minutes of questions. Thanks very much. This is one in the back first, yep. Pardon me. The resources, sure. You should be able to get this deck afterwards as well but there you go. Yes sir. The upgrade of Cloud Foundry basically within the Cloud Platform, right? It's a version of Cloud Platform because it's open source Cloud Platform today. So you have quite a release version and then there's a new release version. Actually we're constantly updating the Cloud Platform versions. We are doing it in sequence. So for customers, the transition is very transparent so as a customer you don't need to care how and when the version is updated because we are doing it transparently. And I think it's typically like within a couple weeks, right? Typically within a couple weeks of like sort of an open source version being. We have a release cycle but we may talk about it in the offline. What is the backup and restore of that? The backup and restore of the... I've been working on it and I think it's better to talk offline and you can find me at SAP Fools and we can talk about all the real questions. Okay, thank you. Yep. Yeah, so can you believe me that I botched on as you don't stop trying to work people? Yes. So that was the thing I showed initially is basically you go to the Azure CPI GitHub page or actually the botched documentation and that gives you the, I think one of these links will have it, the instructions for deploying basically a boss director so you can use Azure Resource Manager template and just spin up the Azure Virtual Network and a couple of virtual machines, storage accounts, about a dozen resources to get created but then you can deploy open source Cloud Foundry. Yeah. Correct, yeah.  So Cloud Foundry is not built on VM scale sets, Azure VM scale sets because Bosch operates in terms of single VMs. We actually, we did a whole investigation about whether we could enable that but it just doesn't work well with the Bosch API but in general, yeah, you get the capabilities of the core Azure IaaS in terms of you can choose different VM SKUs and you can set them up for shutting down and all that kind of stuff through Bosch deployments basically. It's, yeah, that is, it's one of the drawbacks frankly is that we don't have, I mean, Cloud Foundry in general doesn't have an auto scaling, infrastructure auto scaling notion which is again, I think, you know, part of the value of using something like SCP is that it's just sort of auto scales for you. Okay, yeah, so thanks everybody for coming. If you have any questions about Cloud Foundry and Azure I'll be at the Microsoft booth most of the time over the next couple of days and as Dimitri mentioned, he'll be over at the SAP booth so thanks everybody. Okay, thank you. Thank you. Thank you.


In this session, we are trying to draw the threads of what we've been discussing this morning and yesterday to relate it to health, because after all, that is what we all care about. And we have speakers from China, also Africa. This is very important because different cultures, different ethnic groups have a different take on what is needed. And also, the health situation in different countries is also different because you might have countries dealing entirely with non-communicable diseases, the aging population, but yet at the same time deal with communicable diseases in a poor country. And finally, this issue that's recurring in this conference is the balance between profit, policy and good health outcomes. So we'll go through the presentations and then we have 30 minutes to discuss.


Hello! Welcome to my talk about using MIP-DSI as main display interface. I'm Marcel Ciswiller, the Software Team Lead Embedded Linux BSB at Toradex. I joined Toradex in 2011. I basically spearheaded the Embedded Linux adoption there. I introduced an upstream-verse policy, and with that I got into top-10 U-boot as well as kernel armsock contributor at times. And our latest platform is the Industrial Embedded Linux platform, Toryzen. And it's fully based on mainline technology. It's using mainline U-boot with Distribute, KMS, DRM graphics with Etnavive and Nuvo. And it uses ODIRA update with OS3, and also supports containerized workloads with Docker. What will we cover today? I will introduce MIPI-Display Serial Interface, MIPI-DSI. Then I will show you the display adapter system design that we've chosen for Verdin. That is the latest system-on-monule family from Toradex. And I will then also give a quick introduction into the Linux DSI subsystem. Then I'm covering the DRM stack DSI bridge chip integration. We also look at the DSI bridge chip ecosystem. And I will talk a little bit about bridge chips that are supported in mainline Linux. And then the next part is basically about the auto-detection. I will show you how we implemented that using display adapters. And they have an earprom and based on that contents we can auto-detect which display basically a customer is using. I also show you how we integrated that in U-boot. So U-boot is reading the earprom contents and then selects an applicable device relay basically. I also talk a little bit about how you can integrate that into a U-boot fit image. So for a final product that's a really nice concept to have it all in one image. And you can use port specific and display adapter specific device 3 overlays. And I will sum that up with a live demo where I actually can show you a port that I have here which has this whole DSI auto-detection implemented. Okay, let's dive into the MIPI display serial interface topic. It's basically a specification by the mobile industry processor interface alliance, the so-called MIPI alliance. And it's basically about the high-speed differential signaling point-to-point serial bus. And it's used as an interface between a host processor or a SOC and a display module. Whether that is a discrete kind of display or like in our case when you go through a bridge chip. It's a high performance low power and low electromagnetic interference EMI solution. It compared to kind of legacy parallel displays, of course it has a very reduced pin count. And another goal was to have compatibility across different vendors. And usually you have like one high-speed differential clock line and then one or more data lanes that actually carry the actual pixel data, sorry. Then for transferring that, it's one differentiates between a low power and a high-speed mode. While the high-speed mode is usually unidirectional basically just, you know, finding out the display data, the low power mode usually also allows some bidirectional communication between the display and the host processor. From a specification point of view, the initial version came out in May 2006. The current version is version 131 that got released in December 2015. There is also a successor specification I just quickly want to mention, whose initial version was in January 2016. There is now the version 11 out, published May 2018. And that one has support for both DeFi as well as the newer DeFi. And it supports ultra high-definition, so not only 4K, but also 8K. So it's kind of for future applications. Okay. Then how does that look from the layers? So in the physical layer, it uses Meepid DeFi. There are various versions which basically increase the speed of the lanes. So it started with one gigabit per second lane and can nowadays with DeFi 2.0 go up to four and a half gigabit per second lanes. And then on the higher layer, you have the Meepid Display Command Set, so-called Meepid ECS. And that also incorporates display stream compression, DSC, that is basically a standard video electronic standard association the VESA guys have done. And nowadays on higher end SOCs, it's a de facto standard. And unfortunately, as it comes mainly from the mobile industry, it's quite hard to get long-term available discrete Meepid ESI display panels. So for a long time, years ago, there were hardly even any panels available. That changed a little bit with a lot of kind of make-up boards pushing to that. So nowadays, you can, for example, for the Raspberry Pi, you can get such a display. But keep in mind that a lot of these displays are actually at the end just basically a DSI bridge chip again and then use a regular parallel or LVDS display on the actual display panel side. On such bridge chips, they can convert from pretty much or to pretty much any kind of display interface like RGB, LVDS, embedded or regular display port or HDMI. Now I want to show you our display adapter system design. So this basically shows kind of one part of system on module design. So you see there the DSI mezzanine connector. That's basically the connector that will go to such a display adapter. And that basically is a generic system concept. And the idea is that those DSI display adapter boards, they can integrate various bridge chips. So it also has an e-proma on it to store identification or parametrization data. And then this kind of board-to-board mezzanine connector. On there we have a meep DSI, of course, with one clock lane and up to four data lanes. Then we have a bunch of GPIOs, for example, to enable backlight or if there is also a touch control integrated for the touch interrupt. We also have two independent I2C buses. The idea behind that is depending on what actual display you might connect, it might use that for like DDC edit. And if you now have a bridge chip, you basically could even have kind of bridge chips kind of in a chained configuration because you don't know what your actual display might do if this is a display port or an HDMI display. So we try to have an independent I2C bus for that. Then also further signals might be PWM for like backlight brightness stuff. We also have an optional I2S for integrated audio, which can be found basically in HDMI or in a display port. And we also use generic kind of system control signals that we have available on our module standard, which is basically power-enable mochi that is kind of our abbreviation for module out carrier in or sleep mochi or reset mochi. So those are kind of generic system signals that are also available. This is basically one of those modules in that family. We call it the Word in iMix 8M Mini. It has basically an nxbi.mix 8M Mini system on chip. This one has a single display controller. It's basically of the LCD kind of family. If you're familiar with the link stack there, then as a display output, it really only supports mid-bDSI output with up to four data lines and as kind of the DSI controller IP. NXB uses the so-called Northwest Logic IP. From a DeFi point of view, it supports version 1.2, but only a maximum data transfer of 1.5 gigabit per second, while in theory DeFi 1.2 would also allow for higher ones. Then from a resolution point of view, you can do like full HD, 60 Hz, or even kind of a wide format, this 1800x1200. Then now let's go and look at some of these display adapters. Those are the ones I can show you at the demo at the end. This is, for example, the Word in DSI to HDMI adapter. It integrates a Lonsium semiconductor LT8-912B mid-bDSI to HDMI bridge. This one is HDMI version 1.4 capable. It can do full HD at up to 60 Hz in 8-bit RGB kind of fashion. It also has another chip on it, the so-called SDHMI 2C1. That is kind of a single GPSD protection and signaling conditioning chip. So basically that's that little chip just next to the connector that will basically do all this kind of fancy stuff with the signaling that you can easily meet the standard HDMI type A kind of specification. And then of course also the year prom that we talked about so that we can actually identify it. And of course there is a lot of power stuff involved and some kind of interrupts. For example that chip has an interrupt that basically it can interrupt you when it gets a new screen or something like that that you could kind of renegotiate things like that, hot block things like that. Another adapter that is more common in embedded world is the Word in DSI to LVDS adapter. That one uses a Texas Instrument SN65 DSI 84. It's basically a mid-BDSI to dual-link LVDS bridge. So it supports configurable single or dual-lane LVDS up to like kind of this wide full HD resolution or in a single channel this kind of extended HD in 60 frames also and up to 24 bit per pixel. This one also integrates a touch, capacitive touch controller. Basically it allows to directly connect. It also uses from a connector point of view that kind of connector that we also sell this Toradex capacitive touch displayed, 10 inch one. Then let's have a look on the Linux side. How does that look? Basically this DSI subsystem basically it has one piece the DRM mid-BDSI core that basically common logic and some helpers to deal with the mid-BDSI preference. And then basically you have a display engine driver and I also show there the actual calls. So they basically register into the DRM core and then basically have the DSI part, the DRM mid-BDSI core and there in our case the actual DSI host controller is this Northwest logic one. So the NVL DSI and that one host register. And then we can have one or multiple bridges kind of in a chain configuration that goes through the DRM bridge core. There for example in the DSI to LVDS bridge this TA SN65 would then basically call the DRM bridge add so it gets added there and then on a panel side you basically for LVDS there is for example the generic kind of simple LVDS panel thing, the panel LVDS and that one would be added with kind of panel add. That's kind of how it works on the interface side. How does the actual kind of data now get out to the display? So you usually have a display engine driver. So that might be the LCD if and of course the whole kind of rendering. You might have a GPU support for that. For example on the I.M mixes with Fetnavif and then that kind of renders into planes and through the CRTC it then gets fanned out through a DSI encoder in our case. So that will be this kind of meet the DSI Northwest logic thing and then there is a concept of DSI connector and that's how it flows to data then. How does a DSI bridge chip now integrate into that? So from a DRM point of view it's basically a DRM bridge and these are these DRM bridge functions. So there is an attach, enable, disable and the DRM bridge add. So that is into the DRM bridge side of things. And then of course you have the DRM connector side and there are the DRM connector functions. You have to fill modes, detection, destroy and then there are also some helper functions basically to manage get modes, mode valid. So those are used to negotiate the mode and make sure that it's driven by the valid mode. Then there is the connector init, helper add, attach encoder so that's where the meet the DSI encoder kind of gets hooked in and then of course it calls the DRM panel attach which then will basically call into the next one which is then whatever panel is also kind of attached there. From an I2C device point of view it's an I2C device on a bus and it's basically detected using regular ID table or off match table. And of course a common kind of design element there is to use RegMap so basically to obstruct the register of such a bridge chip one can use regular I2C RegMap so with the DRM RegMap init I2C and I2C set client data to actually kind of publish that and on the meet the DSI device side there is this meet the DSI device register fall which registers it and then once it's ready you can attach it with meet the DSI attach. Let's also talk about some kind of bridge chip integration pitfalls that we have met along the way basically one problem kind of as usual is that a lot of those data sheets seem to be super secret so it's kind of tricky especially with some of these kind of Chinese vendors they don't seem to want to give those out easily and then of course the vendors themselves they usually only have some kind of engine downstream driver if you're lucky or even just some kind of bare skeleton driver only where you can kind of guess at the register set and also kind of in what combination and order stuff needs to be done and then even if you have some kind of code of course it's all very hard coded so it's not very user friendly in a sense that if you're trying to support the generic kind of system module concept like we are trying to do which we basically would want that our customers could more or less hook up any display then to that display adapter that makes it rather hard so for example the current LVDS adapter implementation that is kind of hard coded for single channel because there is a version of that chip that only supports single channel that kind of was the only driver that was halfway kind of available so we're still looking into actually working more on that then one problem we saw is that the whole link up sequence stuff is not well documented if you have some kind of a skeleton driver you're not sure in what order and by what things that will be called and that may require a lot of trial and error especially with like the other problem we also saw that of course usually in embedded devices the stuff is rather limited you have some limited kind of dividers frequencies available either on the controller or on the bridge side or even on both and you kind of sometimes have to do some trickery to actually find some combination that halfway works so in our case we had to kind of get a little bit outside of the spec of our actual display and then it suddenly worked fine because all the other frequencies there we just had problems that this north west logic thing in the NXB chip just didn't want to drive the TI chip basically somehow so you might have to do some tuning on this frequency stuff okay then how about the bridge chips that we currently use so I can talk a little bit about more stories in that area so on the DSI side we use this Longium semiconductor that's some kind of a Chinese vendor basically rather nice chip it's just not really well documented or anything luckily we found some downstream driver from the ROG chip Linux guys on GitHub so we actually adopted that one but of course unfortunately with such downstream stuff you know how it is so it was some ancient kind of version of the DRM API so we have to kind of forward port it to later one we also had to fix some kind of confusing naming of some structure and the instant stuff and we had to revert the whole kind of driver to be a proper I2C device because before it was just kind of a hacked thing and then also we had to you know have a look at the full register set from some pseudo code that got actually provided by Longium kind of bugging them over months we got some pseudo code from them so we were able to you know integrate more of the register set then we also improved the whole rack map integration there and you know another thing that is kind of a feature is that those bridge chips often have more than one I2C address so it's basically can be handled in Linux with the so called I2C sub addresses so we also properly reserve those now and then another thing we added regular I2C based DCC ED handling so basically when you with HMI adapter when you there have an actual monitor connected you might want to actually find out from the monitor what modes you can do and we integrated regular handling there then also the hot block detection was missing so it wasn't you know supported that you would during runtime kind of connected different display so we added support for that and then of course we saw some problems when we did that because in our case the GPIO is actually not kind of a SOC native GPIO but goes through a GPIO expander because we kind of were you know short on GPIOs and we found out that then of course because it goes through an I2C bus to actually get to that expander that crashed because we used the wrong kind of you know variant of the GPIO get value stuff so you need to be careful there and another thing that was also done wrong on the DSI side was that the bus format was not properly set still not very pretty but it works and further cleanup and upstreaming there is pending how about the other one that was the HMMA one the LVDS one Texas Instruments basically we started off with a downstream driver taken from the Kompulap Yogdometa layer on GitHub luckily they had adopted it already for kind of an item say the mini design unfortunately it hardcoded for a single channel LVDS use case which luckily our regular panel is actually a single channel but of course we would also want to support the customers to basically attach any kind of a panel also to our channel full HD ones so that is pending and also further cleanup and upstreaming spending how about this DSI bridge chip ecosystem so if you're getting into this kind of area it's of course kind of you face a lot of design system design questions if you want to integrate something like that and unfortunately we met that a lot of those vendors they're still very reluctant to kind of mainlining their drivers so neither Lonsium nor kind of Texas Instruments has really put any work in so it's basically us from the community that have to step in there and that's also kind of the reason there are only very few mainline supporter bridge chips I will actually kind of talk about those on a later slide and therefore also there are only very few kind of examples where we can copy stuff from and find kind of solutions to some things that you might face and of course if you do actual hardware and want to sell that like we at Toradex do it's also quite tricky to actually procure some of this actual silicon that there might be mainline driver but you might not really be able to actually buy such silicon chips and then another thing we saw is of course kind of the conformance of course MEPDSI when the specification got developed it was the goal to actually be kind of vendor independent but you know how that goes with other stuff like USB or so if some of those guys are not really adhering to the spec then it can get tricky and so this conformance with various kind of bridge chip silicon can be problematic how about kind of the chips supported in mainline you can find those on the driver's GPU DRM bridge and I kind of filtered out the ones for DSI of course because that was the only thing we were interested here so one thing to note is that you have to differentiate between kind of SOC internal IP that you might also find there so certain SOC chips basically might already have a bridge integrated for example I believe the regular 8M has kind of a already in the chip does from DSI some other kind of interfaces as far as I remember so you might also find drivers for that and then of course also this grid external bridge chips that are and of course you find also directly connected panels so one thing for example you find there is a northwest logic that was recently added for the iMix 8 series that is basically one of these SOC internal IPs then on the discrete bridge chip side there are some analog devices parts supported the 33 and the 35 which are basically VPDSI receivers with HDMI transmitters so basically similar to the consume one that we are using then another one is from Parade this is a VPDSI to EDP converter we also used some customers use that in some designs then from Texas Instruments there is actually mainline driver but not for the LVDS one that we are using which is the 85 but the 86 is basically a DSI to EDP bridge and looking closer at this driver the driver is actually written kind of in an agnostic way so the idea would be that we could really extend this driver to because kind of the back end DSI side would be the same but of course the front end in this case is EDP and in our case it would then be the LVDS another one that is quite common used is the Toshiba ones they have both version 64 at the end for LVDS and there is a version 68 or 78 that is basically for other display interfaces then on the discrete panel side like you already mentioned there is basically one of the readily available ones is the 7 inch Raspberry Pi touch panel and that one actually inside it uses one of these Toshiba ones actually a 62 at the end which you won't find the discrete kind of tier and bridge driver but in the Raspberry Pi kind of panel driver it's kind of hacked in there and this is a DSI to parallel RGB bridge basically so I guess they just had the goal to kind of mainline that panel but I think it would have been kind of smarter to do that in a more generic fashion to also have a regular kind of bridge driver and then just use a regular panel simple thing on top okay now let's dive into the auto-detection topic so basically the straightforward idea was to well why not just store the device tree in the earprom now why not just using some kind of FTD features in UBOO to just change some disabled versus ok thing in the device tree but unfortunately if you look closer at device trees in this area you have this kind of graph device graph linking stuff with the end point and the remote end point so it's not so easy to kind of just you know set something to ok and have that work so the second straightforward idea was to just you know store the overlay in the earprom unfortunately at least the earprom that we have chosen because they were you know earprom they also cost something so in the two case eyes it's kind of hard well you could maybe compress it or something but it's still very small so as a compromise we now just store kind of identification so called configuration block and then just use that to actually apply a device tree overlay so how is UBOO doing that we already have this kind of config block handling code for NAND and EMMC integrated we generalize that to earprom and then we have basically a table of this product IDs that will then map to overlay filenames and of course with hdmi one can also do hot block the deck of the actual screen and it will do ddc edit or one can do custom display specific parametrization and so it's also possible to actually cascade device tree overlay so I can have basically the auto-detected display adapter device tree overlay and then on top of that an actual kind of hard coded overlay that has the panel or monitor specification in it in the LVDS case that's usually anyway the way it's done so it usually requires further parametrization for the actual panel that is connected to it whether it's single dual channel, it's color format and of course the whole kind of timing resolution stuff so if you look at those overlays that's basically you have these fragments on the left side you see the hdmi one on the right side the LVDS one I don't want to go in too much detail but basically you can you have like a fragment for the iSQC bus which you set the speed and ok so this is actually kind of the ddc one the top one and then you have the fragment the actual iSQC bus where you have the bridge chip on you see that one at the address 48 and you hook up the other bus to do its ddc bus you have like op block detect and all this kind of stuff and then of course you see this device graph linking stuff with the ports endpoints remote endpoints and the last fragment actually exactly that that's from the dsi controller side it's port that links back to the actual bridge and in the LVDS case it's a little bit more complicated because we also have stuff like the PWM backlight we also have the touch controller things like that so there are actually some more fragments there ok now how can we combine that in a fit image basically you can store in a fit image that's the whole point you can store various images so you can have for example you know different device trees for the board we actually for example have there is a Wi-Fi and a non-Wi-Fi variant of that module available so you can have those kind of base device trees and then you can have device 3 overlays the so-called TTBOs like the one for the LT8912 so the HDMI one or the one for the you know for the LVDS Texas instrument one and then you can further combine that into configurations and there it actually allows kind of there are two ways allowed you can have kind of fixed configurations in this case here I show like a configuration 0 and configuration 1 and then you could of course also integrate overlays there but that would you know the more overlays you have that would give you much more configuration and that's why it also is supported that you can basically load the base configuration and then some further overlays you do that with the boot.m command basically you can have like the load address where you have that and then you can say like on config add and then that configuration and then you can just continue with like pound and then such device 3 overlays so you can have like basically a configuration which just has the separate device 3 overlays like that to plant. Then of course also some pitfalls that if you play with device 3 overlays that you might face one thing is of course some simple overlays they work just fine and then you find out you suddenly get this kind of error at least it says nicely that you don't have the symbols in there so you need to actually compile those with symbols inside so if you have more complex device 3 overlays then usually it's not possible to apply them without those symbols. Then another thing that I met is that if you're referencing nodes via hex addresses in the device 3 overlays all of this is actually case sensitive so kind of the base device 3 if you want to reference back to a node from the base device 3 you have to make sure that this has the same case usually I guess everybody uses lowercase letters in hex numbers but at least in some kind of downstream Manning's piece stuff that was not the case so if you look forever why it doesn't work but then I found out it really is a casing of those hex numbers another thing that is quite useful when troubleshooting what it's actually going on and what actually gets applied is if you actually boot into Linux you can use the device 3 compiler on the target board itself I just old package installed it into my image and then you can actually use the input format FS which understands this proc device 3 kind of notation and can actually dump it back into kind of a readable format in basically device 3 source format then you can actually easily see what really got applied if you have multiple overlays and then you know at the end you can't figure out what happened with all that stuff that's very useful okay I guess then we are ready to get to the demo for as a first part in the demo I will just show the console of that board basically you see here on the left that is the Aliyah carrier board with the HDMI display adapter and that kind of module on it so I will prepare this combination here on my table I will show the actual board at the end but for now I will quickly share my screen and I have here the console ready somehow and I turn the board on so it boots up and you can see basically of course it all goes a little bit fast so let me see that was the HDMI one let's see LVDS1 power it back on and it will boot into the into the other variant the thing that we are showing here is the Toradex easy installer and I can now check actually show you take the camera so that would be that board here you see the LVDS adapter I will show this kind of 10 inch panel I can boot it up again so it basically outer detects that display adapter and then initializes the 10 inch display and it then basically loads this easy installer configuration and I can turn it off I can put in the HDMI one and I can turn that one on and it detects that one and basically boots that one up and shows that on the HDMI screen here okay that's basically it put that back and then we can do the question and answer session still have like 5 minutes for that let me quickly look at that whether the low power signal is singland I believe it's both with differential as far as I know and it's just using only one line okay that would be that one more questions whether an end panel like LVDS supports partial update and how will the bridge propagate that I guess that will basically be a matter of the actual bridge chip that you use I guess if that one if the bridge chip supports such partial update I guess it would work it would basically I guess usually that is called kind of smart displays so you would probably need some kind of frame buffer also on the bridge chip side so I'm not sure I have not seen any such chips but I haven't really looked for it so I would assume that should be possible but rather special use case I guess okay this one let me see what else we have oh yeah whether we consider doing it in the Linux kernel of course we kind of you know I attended a lot of those overlay talks in the past and I remember that some of those actually got rather almost a little bit violent isn't it we didn't really want to get into that too much I think for an end product in our case for our customers it's usually you know it doesn't need to be ultra kind of runtime ish that you would connect that during runtime even or something like that so I think they're fine when we load that from your boot site whether the bridge chip can limit any of the DCS commands that I'm not really familiar with that why DRM is required with DSI well I guess DRM is kind of you know the graphics stack in Linux nowadays so I'm not sure how else you would want to hook up a DSI panel I think it makes total sense to have that properly integrated in the DRM subsystem so yeah we used to overlay stuff in Uboot yeah why the vendors are reluctant with mainlining or even giving out documents but that's a very good question well I think they just don't see the value too much I think a lot of those vendors they are very project driven so they just kind of sell those chips into projects and they kind of think well it anyway needs some engineering company to integrate that and fine tune it and whatever not I don't believe into kind of a generic Linux approach too much yet but I guess that is changing isn't it it's evolving I mean a couple years ago who would have thought that you could run open source graphics acceleration on our embedded ports like we now have with many different drivers okay so I believe we just have to push them further and keep reminding them and also of course try to mainline more such drivers and then show them that that's a good idea because they will then sell more chips and things like that variable refresh rate that I'm also not so sure I think that's also something that would it's kind of from the smart display mobile space I believe DSI definitely supports that whether you could also do that with a bridge chip I guess that depends on that bridge chip okay I guess I don't know when it will be really finished here if you have further questions you can there is also slack channel so you can bring those to the to that slack channel I will also hang out there some more and I'm happy to answer some more questions you also find my email address I believe I have some references here and yes I will publish the PDF slides I will just upload them okay thank you very much for your time and have a nice rest of the conference this virtual experience so I'm already past midnight in Europe here have a nice time see you guys thank you