Automotive Ethernet PHY bring-up: lessons learned and debug tips
Thekekara, Jean-Louis
I would like to share my experience bringing up various Automotive Ethernet Gigabit PHYs on an iMX8 platform. Agenda: - PHY configuration CheckList (= What I need to know about my PHY, my schematic before starting the bring-up) - SW implementation (= step-by-step SW integration + common pitfalls to avoid, mainly focused on Linux, but I talk also about U-Boot) - Debug tips (= SW and HW tips) This presentation is based on a training I already gave internally in the Valeo Group (with some extra additions). This experience led to some patches that I hope to push at U-boot and Linux level.
 you you Hello everyone, my name is Jean-Louis Tekekara and today I'm here to talk about the bring up of automotive Ethernet files. Quick self-introduction, I'm an embedded Linux engineer since 2010. I started to work in Paris in a company called OpenWide, which is an open source consulting company, and then later in Parod drones. Then I joined Valeo Telematic here in Frankfurt area to develop TCUs. TCUs are basically boxes which connect your car to the internet over 4G, now 5G network, and also give you positioning solutions based on GNSS and dead reckoning for instance. I'm myself not an automotive expert, I just want to share with you my humble experience. Here are the goals and expectations. You should know the basics about Ethernet files. In our case we will talk about automotive Ethernet files, but the work should be the same for standard Ethernet files. You will have an overview of what tasks you should expect when you bring up an Ethernet file in embedded Linux environment. I will share with you some common bring up issues and some deep bell tips. This presentation is based on an internal presentation I already gave last year in Valeo Group. Here's the agenda. So first, a very small slide about why we are talking about Ethernet in the automotive world. Then to be sure we are on the same line, we will define some technical terms and describe the basic architecture. Then we will list all the file configuration, everything you should know about your file before starting the actual software implementation. Then the software implementation itself, and then some debug tips and questions. So why do we have Ethernet in our vehicles? It's simple because we need for always more bandwidth, not only software update use case, but you can think about any advanced driver assistance systems, use cases and also infotainment, etc. There is also a need for standardization. There are already a lot of competing solutions which give you more bandwidth than the old traditional network like KAN Flex Ray which give you only a few megabits. So there are competing solutions like most, for instance, but there are proprietary solutions. Why do we use automotive Ethernet and not standard Ethernet? Because in the automotive world you need to pass very strict electromagnetic compatibility test and automotive Ethernet allow you to do that because it's using only one twisted pair, most of the time unshielded, and so it's very lightweight and it has a lower cost compared to traditional category 5, 6 Ethernet cable. So let's talk about some technical terms. So the file itself in the blue box here, this is basically a transceiver, this is translating or more precisely this is modulating your data which are on the PCB on one side to the external world which is just this twisted pair. The Mac itself, so it's an Ethernet controller, this is integrated into your application processor and this Mac is controlling the Ethernet file over a dedicated control bus which is called MDIO bus, it's a low speed bus with a clock of a few megahertz. Actually it's not directly the Mac which is controlling your file over the same bus, there is another entity, it's called the STA or SME station management entity and into your application processor you could have many Mac, many Ethernet devices but usually only one station management entity. And you have also the high speed database which could be for instance HGMI or RGMI. Oh I didn't say that but it could happen that on some application processor, for instance I know I'm aware at least about some Qualcomm processor they have the Ethernet file already integrated into the Mac. I will talk more about the use case I know, I work many with the IMX8 processor. So file configuration checklist, that is the file address. So this address is used by the Mac to find the file on the MDIO bus and start to talk with it. The IEEE standard set up to 32 files on the MDIO bus as you can see in this example of frame format sent over the MDIO bus there are only 5 bits dedicated to the file address. This file address is bootstrapped at 5 power up. Bootstrap basically means you have for instance some resistors to some dedicated pins and at power up the file is reading out the voltage on this pins and then it decides its own address. This is normally documented in your file data sheet and you need to check just your board schematic. Another item, what is the PHY mode, master or slave? Most of the time you want your TCU to be in slave mode because your endpoints in the vehicle which could be an Ethernet switch is in master. In our test setup when you are developing and bringing up your PHY you have normally a device called media converter which allows your PC to be part of the local network of your TCU and then you need to put this media converter into master. As you can maybe see on the slide the media converter is just basically one microcontroller. On one side you have the automotive Ethernet PHY to connect your TCU and on the other side you have a standard Ethernet PHY and an RG45 connector, standard connector to connect your PC. This mode is of course always bootstrapped and you should ask yourself also if the rest of the bootstrap configuration is consistent with your use case you can select the bandwidth 100 versus 1000 megabits the MII mode sometimes you can enable some delay, internal delay in the PHY etc and it can happen that you could even change the voltage level in software in your PHY so you should pay attention to that. So in general most bootstrap parameters can be overwritten later over the MDO bus during the PHY initialization over for not only for a fast bringer but in all the cases it's really recommended to use as much as possible the bootstrap method if you use case are not changing. So what is the init sequence for the PHY? At the beginning the PHY requires proprietary and under NDA initialization sequence which consists of a list of write sequence on the MDO bus. So write call or function looks like that you have the register the value and you have something called the dev add in which can translate to device address. Be careful this is not the PHY address it's just because to make it simple on modern PHY you have a lot of registers much more than what allow you register address space here so you have also we can say kind of virtual devices inside the PHY and this dev add parameter gives you an additional level of indirection to access these internal devices. There are historical reasons for this. So here just an example you have a kernel function called PHY write and then you have the dev add register value and one could imagine you put all this PHY write enrolling in a loop and this is your init sequence. It must be very carefully selected the source of confusion you need to triple check this init sequence with your vendor. Must match exact revision even if you have different variant like engineering sample 1, 2 and then the mass production sample it could change over the life early life of your internet PHY. There are two places to start the software implementation the bootloader which could be Uboot for instance and then the kernel unless you have a very specific use case and you need to have network access from the bootloader you can implement only the kernel this is what we do most of the time. Anyway the kernel level implementation is always needed for obvious reasons and if you implement it only the if you implement it at two places then when you have some software update maintenance you need to update at both places so. Quick reminder the MDO bus is controlled by the Mac driver this is provided by the your vendor BSP and thus this MDO bus control should work out of the box you are not expected to do any implementation on debug at this level. About close 22 close 45 you have already you had already an overview of what a frame looks like on the MDO bus. I will not cover this in this presentation but there are references at the end that you can invite you to follow. Basically there are PHYs which understand only close 22 format other they are close 45 but this is backward compatible so you can talk to them in a special close 22 indirect mode. It depends on your PHY most of the time instead of the art today that if your Mac can only talk in close 22 you can always somehow find your way to talk to the Ethernet PHY. So let's list the remaining work. First step you need to adapt your born hardware description so device 3 in the Linux world. You need to adapt an existing PHY driver or write your own PHY driver then check that the PHY is detected and your driver is correctly loaded and finally check and debug your link which needs to be up of course to start to do actual communication. So for instance if we take an example here this is based on AMX 8 you have a block describing your your Mac device so it could be called FEC in AMX world but on Qualcomm processor it could be eMac for instance of course needs to be activated. Then the PHY mode attributes needs to be correct here you can notice it's not only rgmii versus hgmii or just mii you have kind of variance suffixes here in this case this suffix is telling the the Mac to not put any delay inside because I'm already managing myself the delay in hardware in the PHY itself for instance. After that you have another block here which is describing your PHY and you have also most of the time as far as I know there is only one PHY for one Mac you have this PHY handle which is pointing at this PHY here you need to check that the PHY address is correct so this is a reg attribute here here my physical address is 10 and for more details of course you have the documentation of the device to itself and so either net PHY and so you have of course the documentation of your own Mac driver after that you need to locate the PHY drivers they are in driver net PHY what is recommended because unfortunately most of the time your new shiny automotive is a net PHY its driver is not existing in the main line so what is recommended even by our cheap manufacturer is to locate one existing driver which looks like the most to the PHY you want to implement one effective way to locate a similar PHY would be to to to to grab the PHY ID which is a unique identifier of your PHY which is stored inside the PHY itself in the standard register two and three and then when you find a good candidate you can start to use it so you can if possible reuse sometimes you can reuse existing function if you don't find any anything you can open a new file or just modify your driver formatly the same brand so when you open your PHY driver you need to define the PHY ID you have the PHY mask also which helps you to map and to to match basically the PHY ID you are finding on the bus you also need to give a name which is then later displayed in the channel messages so you are sure your driver is actually loaded and then you have what we can call primitives routines which are used by the standard PHY framework or by your Mac driver sorry and for instance you have some primitives like config init that need always to be rewritten config init is a good place where you can put your PHY init sequence for instance you can reuse other which are very standard for instance soft reset here it's using already define a PHY reset routine here but behind that it's it could only set one standard bit to reset the PHY and then you don't you don't have any specific soft specific PHY reset sequence because it's very generic and most of the PHYs respect the standard about config init this is called immediately after reset and so this is why you put your init sequence you can put also any other parameter enforcement like master slave for instance or other custom parameter so one effective way to do so is to put your your init sequence in an array of struct and providing the fact that all of this register and value right there on the same dev addy you can put them in loop like that and that's it you have your init sequence about config auto negotiation in my experience in our own use cases we are not using auto negotiation by the way this is defined in the triple high triple E standard as optional in automotive is an it is optional some PHYs they don't even implement auto negotiation some claims they support auto negotiation but it doesn't work also so one effective implementation is just to set this one line code you set the speed of your PHY device to one gigabit for instance and that's it you have you have you have it for other primitive like suspend resume soft reset etc unless your PHY simulator has a really explicitly defined routine for a fast bring up it's safe to not implement them they are in the PHY driver framework they are generic implementations that are automatically used normally to get PHY up and to have your first link up the correct init sequence is all you need for a better detailed description of all the the primitives i invite you to check this header PHY so include linux PHY.h so check the PHY is detected so if everything works you have a attached PHY driver message and the name the string of the PHY name you put in the driver if you have an hardware failure or just a bad PHY address you will have mda device address 10 is missing for instance and unable to connect to PHY sometimes the PHY is found on the on the bus but your PHY driver is not loaded because for instance of an inco-align PHY ID in this case there is a generic PHY genetic driver which is loaded in my experience you cannot do much with this generic PHY then you need to check the link is up of course you can check your media converter or with ip command on linux command source of link issues your PHY init sequence is incorrect in this case it's not so easy to debug but you can always contact your your PHY the other endpoint is not in master when the PHY is in slave or the other way around and you have a delay issue you can you can put a delay internal delay in the PHY or in the Mac but never at both sides I bought usually but never this is what has been recommended by our cheap manufacturer as well and I'm not a specialist of this topic but you should ask your your preferred automotive hardware engineer you could have an hardware issue on the on the physical channel itself or just after your PHY and before the connector you have some components which are there to help basically to pass the electromagnetic compatibility test and so on for instance you have a component called CMC command mode shock which could be which could not work or broken just broken physical channel let's talk about some huboot patch when you are using iMix iMix 8 and you have a gigabit file you need to make sure you have this defined set fc quirk in net mac otherwise you have one specific bit which is not being set correctly in the mac in one of the mac registers this define is by default already set in some board configuration in huboot it's in include config.h but it can it could be that you don't have that in your own board or the board you are describing or writing yourself so actually recently since last year since this patch this define is now set one level above in one of the top level iMix 8 header so you should have no worries unless you are using you know that on in the iMix 8 world you are using a fork from huboot huboot dash iMix 8 no huboot dash iMix which is managed by by nxp and it's also on code or so you might not have always the latest huboot coming with your iMix 8 BSP sometimes you you could have a file that needs your custom reset procedure i forgot to say that about the init sequence sometimes some file manufacturer give you just a PDF file with all the registers you need to to write yourself some other manufacturer it was okay for me for Marvel they give you directly a c source code file which can be easily integrated and in this case i had a custom reset procedure so in i talked already about this use case in linux but at huboot it's the generic file reset routine it gets unconditionally called and i'm i brought a small patch to allow to write your own custom file reset and by the time you see this video maybe it will be already proposed upstream about close 45 support at first when i asked for it and xp told me they didn't want to support it officially but finally a little bit later i observed that they push the support at linux level only so it's not in huboot in the meantime they gave me an official patch that i tested at huboot level and it worked so i plan to to to to upstream it if possible in the near future at linux level nothing special as i said the close 45 if you want to use it it's already in the canal since 2019 some debug tips there is a very useful command line called phi tool here an example where i'm reading the standard register to entry to to to check the phi id for instance so first parameter your your phi device name sorry your username then you have the address physical address of your find and the register phi tool is using the mac driver and it is functional only when the phi is correctly detected when you have such error unable to connect to phi it's not it's not usable so you can use it to debug some link issue but not for phi detection itself one alternative you want to send arbitrary command on the mdi bus one alternative that i'm aware of maybe there are more is to use the huboot environment where you have mdio mi test command it requires of course a minimum of bsp integration if you do everything at linux level and you have the bare minimum at huboot for your for your board it could not work out of the box other debug tip i should have no clue about what's happening and you really want to check that your phi chip is alive normally as soon as it's it's proven up in rgmi i mod for instance this is the one i debug the most um your um your phi is supposed to produce automatically uh rx clock at 25 mega hertz or 125 megahertz depending on your on your speed you should check also the clock symmetry you could have a clock asymmetry the rx clock which is produced by your phi should be the same as the x clock produced by the mac so 25 25 125 125 um you have a doubt and you want to check that the mdi bus is currently managed by your mac uh with the scope it's very easy as i said it's a two megahertz uh by default in my case was maybe two three megahertz and think the standard set it up to 12 megahertz and here you can observe the first frame on the scope in this case for instance it's one of the first time i try to talk with a um close 45 mac uh phi and uh i try to talk with it using close 22 and not the indirect mod uh the compatibility mod so after the turnaround time uh the phi did respond zero so sometimes it doesn't respond um uh it will it will read the line but sometimes it um it it responds zero that can happen when you are talking to a close 45 uh phi uh using close 22 just an example and uh what something really really useful is that at the beginning you can see the start bit which differ between 22 and 45 so you can immediately check that your mac is talking the correct frame format another debug tip um i talked already about um media converter to to connect your developer pc to the local network of your tcu um sometimes it's better to use the phi evaluation kit from the chip vendor which is also itself a media converter but at least it's using exactly the same phi the same revision that the one uh you are trying to bring up why because some early sample like engineering sample you might might um you might use during bring up phase uh they are not always immediately fully compliant uh with the standard uh the open alliance standard for automotive internet and they are not interoperable uh with each other so for early bring up you might uh ask or if or just use directly if you can take a phi evaluation kit from the chip vendor if you can uh here are some reference link about the mdi o close 22 45 uh very useful i invite you to read them and uh if you want a generic internet find introduction more kernel developer oriented you can find open this file in the documentation of the kernel documentation at working phi.txt and that's it i hope you enjoy the presentation and uh that it will help you to bring your own phi thank you want that people are can ask questions and get responses from you unfortunately it looks like so that so far we don't have any questions yet but we still have plenty of time i see one question from luca yes okay so you mentioned the x-txt delay that the phi or the mac can add how do you know the delay values is there any auto tuning auto training feature a standard procedure to measure the required delay i'm not aware of any auto tuning uh auto training feature that we can imagine um uh to be honest um i didn't really i'm not i cannot really answer that question i managed to do it without any delay but normally it's your hardware engineer which is designing a pcb we can answer that question but i know that in software you know you need absolutely uh to not to not put a delay at both sides that's what i know um i'm sorry that's thank for the question yeah in my experience that it's usually it doesn't work well at full speed if the delay is wrong but uh apart from that it depends on the pcb layout uh yeah exactly so so so i don't know if it's visible in the in the stream that will be recorded but uh t-p-rot t-p-o answer luca's question says that i dragam can help you to to find the delay value i don't think the chat will be available in the recording so it's always a good idea to okay Okay, one question from Teresa. Since there are no other questions, can I ask if Automotive Ethernet is changing and how closely do you monitor communication standards? I worked in Auto years ago and I remain an IEEE member. So even if you are not a member of IEEE, there is another committee called Open Alliance. And here in my company in Valeo, my colleague, which is a hardware engineer, is actively following all the news and coming out of this Open Alliance committee. We are already, I think, ourself part of this committee and this is a way for us to stay close to all the news. So the answer is basically be part of the Open Alliance. Okay. Yeah, what should we do? It seems there's no other question. Well, we still have the room until 2.30. OK. And even after that, we can continue in a private room. But I don't think there will be a need for that. OK. Well, Ankurya wonders if Ethernet has a future in automobile, because all he sees is the wascan, flex-ray, and lint. Yes. I think there are all prisons, all these old buses. But for Ethernet, I don't remember if I said it. But it already went into mass production. I think it 2008 in BMW car, luxury car. But now, I think it's coming everywhere. Yeah, usually these things start in the high end, cars first. Yeah, exactly. Luxury car, but. Well, like Kendo, it was first in Mercedes S-Class, if I remember correctly. Was it at the end of the 80s or something like that? So. There's another question from Theresa about what's the difference between auto and computer communications. What's the coolest component you use? Well, as I said, it's a general question, or only an Ethernet question. Because on Ethernet question, as I said, it's a physical medium standard, which is different. Basically, 10,000 base T1 or TX or T and so on. But they're all Ethernets. And then the physical medium change. This is a many different. But behind that, it's always Ethernet protocol. But then, if it's a more general question, maybe you can elaborate, Theresa. This communication inside the car itself, or between car, for instance. What is the. OK, I will answer first what is the coolest component you use. What's the newest components that we have in automobile? Communication are basically V2X, vehicle to everything, which is using as a radio layer. It can use the Wi-Fi or mobile network. And you have also 5G modem. That are the coolest component. Our very precise GNSS module. So we have now, which allow you to have a centimeter resolution. Speaking about Ethernet specifically, I find this automotive very interesting, because it manages to do with just the two wires. And I'm wondering whether that will show up in other areas as well. In buildings, it's probably not going to happen that soon, because they're already equipped with 8 wire cable infrastructure anyway. I wonder myself also the same question. Why do we not have automotives? So Ethernet in the building and so on. One of the first answer is that you are not allowed to have a so long cable using automotive. Basically, it's around 15 meters. But you don't care in automotive to use a 100 meter long cable. Yeah, I don't think I have that long cable in my house. 15 meters would be really small. Yes, but then you need to have a mediaconverter in your house. It's like people who are using fiber optical for their LAN network. They need also to put everywhere a transceiver. And Thérèse is asking another question, but I'm afraid I cannot answer all of them. What is the widest specification, crazy, current, wired package? Are electric vehicles requiring many far different parts than IC? Just remembering an IGBT, I don't know what is it, 75 ampere and a brake unit immersed in brake fluid. I'm not so specialist in automotive as I said. I'm here in value since three years. And Mati has another question for you. If automotive and software, they always bring safety and bureaucracy to my mind. Is this visible at your work too? Well, automotive and software always bring safety and bureaucracy. Yes, there is one thing which is if I feel it correctly and understood it correctly, in automotive world, you have the car manufacturer. They are leading the way. They are the master, the king of the world. And then you have the tier one, tier two, I mean the different car equipment manufacturer. And what I know is that they are driving some very strict standard. It's basically not bureaucracy, but it's just project, very strict project management standard with requirement and so on, risk management, et cetera. So yes, it is visible in my work. I am myself, most of the time working not directly with a project which are already in mass production. I'm at some R&D level, so I have more freedom, let's say. And I don't feel this pressure on my shoulder all the time. But when I'm working also from time to time to help mass production and project, product, then yes, it's visible. Shhh. That's all. Shhh. Shhh. Shhh. Right. Shhh. Shhh. Shhh. So Luca has another question about A2B, automotive audio bus. And he's wondering whether it's gaining adoption on real world automotive. Yes. So Luca, at least I saw A2B components on some PCB. I saw on some schematic. I didn't work personally with it. But recently, yes, I saw it in some project. So yes, it's gaining attraction. I think it's also part of some requirements from some car manufacturer. Even if I'm not working directly during the RFQ phases, I know it's gaining adoption. Yes. Shhh. Shhh. And either has a question about reference clock, which is an input to both the Mac and the PHY. And he's wondering if you've ever seen a device that generates the clock. Shhh. And either if you do you mean that it's a clock signal signal for the RGMI database. I never saw any other device that generates the clock. There is a Mac and the PHY on one side and the other. But no, I never seen a device that generates the clock. I'm aware of the RX clock and TX clock when using RGMI. When using SGMII, I think there is no such clock. I'm not sure. I don't know about that. The fact that I never seen a device that generates such clock. I don't know. Yes, 15. RMII. Sorry, I'm not very familiar with RMII. I don't know if it's still widely used. So I assume it's what it's just 100 megabit maybe. So wait. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. You are mute, Gert. You are mute. Mati has a final question about automated drivers, the systems and internet and safety with Linux. Oh, yes. What's that safety concern? As far as I know, we are not using a specific real-time Linux or something else in our TCU. I don't know. I don't know. I don't know. I don't know.
 you  you  Hello everyone, my name is Jean-Louis Tekekara and today I'm here to talk about the bring  up of automotive Ethernet files. Quick self-introduction, I'm an embedded Linux engineer since 2010.  I started to work in Paris in a company called OpenWide, which is an open source consulting  company, and then later in Parod drones. Then I joined Valeo Telematic here in Frankfurt  area to develop TCUs. TCUs are basically boxes which connect your car to the internet  over 4G, now 5G network, and also give you positioning solutions based on GNSS and dead  reckoning for instance. I'm myself not an automotive expert, I just want to share with you my humble  experience. Here are the goals and expectations. You should know the basics about Ethernet  files. In our case we will talk about automotive Ethernet files, but the work should be the  same for standard Ethernet files. You will have an overview of what tasks you should  expect when you bring up an Ethernet file in embedded Linux environment. I will share  with you some common bring up issues and some deep bell tips. This presentation is based  on an internal presentation I already gave last year in Valeo Group. Here's the agenda.  So first, a very small slide about why we are talking about Ethernet in the automotive  world. Then to be sure we are on the same line, we will define some technical terms and describe  the basic architecture. Then we will list all the file configuration, everything you  should know about your file before starting the actual software implementation. Then the  software implementation itself, and then some debug tips and questions. So why do we have  Ethernet in our vehicles? It's simple because we need for always more bandwidth, not only  software update use case, but you can think about any advanced driver assistance systems,  use cases and also infotainment, etc. There is also a need for standardization. There  are already a lot of competing solutions which give you more bandwidth than the old traditional  network like KAN Flex Ray which give you only a few megabits. So there are competing solutions  like most, for instance, but there are proprietary solutions. Why do we use automotive Ethernet  and not standard Ethernet? Because in the automotive world you need to pass very strict electromagnetic  compatibility test and automotive Ethernet allow you to do that because it's using only  one twisted pair, most of the time unshielded, and so it's very lightweight and it has a  lower cost compared to traditional category 5, 6 Ethernet cable. So let's talk about some  technical terms. So the file itself in the blue box here, this is basically a transceiver,  this is translating or more precisely this is modulating your data which are on the PCB  on one side to the external world which is just this twisted pair. The Mac itself, so  it's an Ethernet controller, this is integrated into your application processor and this Mac  is controlling the Ethernet file over a dedicated control bus which is called MDIO bus, it's  a low speed bus with a clock of a few megahertz. Actually it's not directly the Mac which is  controlling your file over the same bus, there is another entity, it's called the STA or SME  station management entity and into your application processor you could have many Mac, many Ethernet  devices but usually only one station management entity. And you have also the high speed database  which could be for instance HGMI or RGMI. Oh I didn't say that but it could happen that  on some application processor, for instance I know I'm aware at least about some Qualcomm  processor they have the Ethernet file already integrated into the Mac. I will talk more about  the use case I know, I work many with the IMX8 processor. So file configuration checklist,  that is the file address. So this address is used by the Mac to find the file on the  MDIO bus and start to talk with it. The IEEE standard set up to 32 files on the MDIO bus  as you can see in this example of frame format sent over the MDIO bus there are only 5 bits  dedicated to the file address. This file address is bootstrapped at 5 power up. Bootstrap basically  means you have for instance some resistors to some dedicated pins and at power up the  file is reading out the voltage on this pins and then it decides its own address. This  is normally documented in your file data sheet and you need to check just your board schematic.  Another item, what is the PHY mode, master or slave? Most of the time you want your TCU to be in  slave mode because your endpoints in the vehicle which could be an Ethernet switch is in master.  In our test setup when you are developing and bringing up your PHY you have normally a device  called media converter which allows your PC to be part of the local network of your TCU and then  you need to put this media converter into master. As you can maybe see on the slide the  media converter is just basically one microcontroller. On one side you have the automotive Ethernet PHY  to connect your TCU and on the other side you have a standard Ethernet PHY and an RG45 connector,  standard connector to connect your PC. This mode is of course always bootstrapped and you  should ask yourself also if the rest of the bootstrap configuration is consistent with your use case  you can select the bandwidth 100 versus 1000 megabits the MII mode sometimes you can enable  some delay, internal delay in the PHY etc and it can happen that you could even change the voltage  level in software in your PHY so you should pay attention to that. So in general most bootstrap  parameters can be overwritten later over the MDO bus during the PHY initialization over for  not only for a fast bringer but in all the cases it's really recommended to use as much as possible  the bootstrap method if you use case are not changing. So what is the init sequence for the PHY?  At the beginning the PHY requires proprietary and under NDA initialization sequence which  consists of a list of write sequence on the MDO bus. So write call or function looks like that  you have the register the value and you have something called the dev add in which can  translate to device address. Be careful this is not the PHY address it's just because to make it  simple on modern PHY you have a lot of registers much more than what allow you register address  space here so you have also we can say kind of virtual devices inside the PHY and this dev add  parameter gives you an additional level of indirection to access these internal devices.  There are historical reasons for this. So here just an example you have a kernel function  called PHY write and then you have the dev add register value and one could imagine you put  all this PHY write enrolling in a loop and this is your init sequence. It must be very carefully  selected the source of confusion you need to triple check this init sequence with your vendor.  Must match exact revision even if you have different variant like engineering sample 1,  2 and then the mass production sample it could change over the life early life of your internet  PHY. There are two places to start the software implementation the bootloader which could be  Uboot for instance and then the kernel unless you have a very specific use case and you need to  have network access from the bootloader you can implement only the kernel this is what we do most  of the time. Anyway the kernel level implementation is always needed for obvious reasons and if you  implement it only the if you implement it at two places then when you have some software update  maintenance you need to update at both places so. Quick reminder the MDO bus is controlled by  the Mac driver this is provided by the your vendor BSP and thus this MDO bus control should work out  of the box you are not expected to do any implementation on debug at this level. About close  22 close 45 you have already you had already an overview of what a frame looks like on the MDO bus.  I will not cover this in this presentation but there are references at the end that you can  invite you to follow. Basically there are PHYs which understand only close 22 format  other they are close 45 but this is backward compatible so you can talk to them in a special  close 22 indirect mode. It depends on your PHY most of the time instead of the art today that  if your Mac can only talk in close 22 you can always somehow find your way to talk to the Ethernet PHY.  So let's list the remaining work. First step you need to adapt your born hardware description  so device 3 in the Linux world. You need to adapt an existing PHY driver or write your own PHY driver  then check that the PHY is detected and your driver is correctly loaded and finally check and debug  your link which needs to be up of course to start to do actual communication. So for instance  if we take an example here this is based on AMX 8 you have a block describing your  your Mac device so it could be called FEC in AMX world but on Qualcomm processor it could be  eMac for instance of course needs to be activated. Then the PHY mode attributes needs to be correct  here you can notice it's not only rgmii versus hgmii or just mii you have kind of variance suffixes  here in this case this suffix is telling the the Mac to not put any delay inside because I'm already  managing myself the delay in hardware in the PHY itself for instance. After that you have another  block here which is describing your PHY and you have also most of the time as far as I know there  is only one PHY for one Mac you have this PHY handle which is pointing at this PHY here you need to  check that the PHY address is correct so this is a reg attribute here here my physical address is 10  and for more details of course you have the documentation of the device to itself  and so either net PHY and so you have of course the documentation of your own Mac driver  after that you need to locate the PHY drivers they are in driver net PHY  what is recommended because unfortunately most of the time your new shiny automotive is a net PHY  its driver is not existing in the main line so what is recommended even by our cheap manufacturer  is to locate one existing driver which looks like the most to the PHY you want to implement  one effective way to locate a similar PHY would be to to to to grab the PHY ID which is a unique  identifier of your PHY which is stored inside the PHY itself in the standard register two and three  and then when you find a good candidate you can start to use it so you can if possible reuse  sometimes you can reuse existing function if you don't find any anything you can open a new  file or just modify your driver formatly the same brand  so when you open your PHY driver you need to define the PHY ID you have the PHY mask  also which helps you to map and to to match basically the PHY ID you are finding on the bus  you also need to give a name which is then later displayed in the channel messages so you are sure  your driver is actually loaded and then you have what we can call primitives routines which are  used by the standard PHY framework or by your Mac driver sorry and for instance you have some  primitives like config init that need always to be rewritten config init is a good place where  you can put your PHY init sequence for instance you can reuse other which are very standard for  instance soft reset here it's using already define a PHY reset routine here but behind that it's it  could only set one standard bit to reset the PHY and then you don't you don't have any specific  soft specific PHY reset sequence because it's very generic and most of the PHYs respect the  standard about config init this is called immediately after reset and so this is why you put your init  sequence you can put also any other parameter enforcement like master slave for instance  or other custom parameter so one effective way to do so is to put your your init sequence in an  array of struct and providing the fact that all of this register and value right there on the same  dev addy you can put them in loop like that and that's it you have your init sequence  about config auto negotiation in my experience in our own use cases we are not using auto negotiation  by the way this is defined in the triple high triple E standard as optional in automotive  is an it is optional some PHYs they don't even implement auto negotiation some claims they  support auto negotiation but it doesn't work also so one effective implementation is just to set  this one line code you set the speed of your PHY device to one gigabit for instance and that's  it you have you have you have it for other primitive like suspend resume soft reset etc  unless your PHY simulator has a really explicitly defined routine for a fast bring up it's safe to  not implement them they are in the PHY driver framework they are generic implementations that  are automatically used normally to get PHY up and to have your first link up the correct  init sequence is all you need for a better detailed description of all the the primitives  i invite you to check this header PHY so include linux PHY.h so check the PHY is detected so if  everything works you have a attached PHY driver message and the name the string of the PHY name  you put in the driver if you have an hardware failure or just a bad PHY address you will have  mda device address 10 is missing for instance and unable to connect to PHY  sometimes the PHY is found on the on the bus but your PHY driver is not loaded because for  instance of an inco-align PHY ID in this case there is a generic PHY genetic driver which is  loaded in my experience you cannot do much with this generic PHY then you need to check the link  is up of course you can check your media converter or with ip command on linux command source of link  issues your PHY init sequence is incorrect in this case it's not so easy to debug but you can always  contact your your PHY the other endpoint is not in master when the PHY is in slave or the other  way around and you have a delay issue you can you can put a delay internal delay in the PHY  or in the Mac but never at both sides I bought usually but never this is what has been recommended  by our cheap manufacturer as well and I'm not a specialist of this topic but you should ask your  your preferred automotive hardware engineer  you could have an hardware issue on the on the physical channel itself or just after  your PHY and before the connector you have some components which are there to help  basically to pass the electromagnetic compatibility test and so on for instance  you have a component called CMC command mode shock which could be which could not work  or broken just broken physical channel let's talk about some huboot patch when you are using iMix  iMix 8 and you have a gigabit file you need to make sure you have this defined set fc quirk  in net mac otherwise you have one specific bit which is not being set correctly  in the mac in one of the mac registers this define is by default already set in some  board configuration in huboot it's in include config.h but it can it could be that you don't  have that in your own board or the board you are describing or writing yourself so actually  recently since last year since this patch this define is now set one level above in one of the  top level iMix 8 header so you should have no worries unless you are using you know that on  in the iMix 8 world you are using a fork from huboot huboot dash iMix 8 no huboot dash iMix  which is managed by by nxp and it's also on code or so you might not have always the latest huboot  coming with your iMix 8 BSP sometimes you you could have a file that needs your custom reset  procedure i forgot to say that about the init sequence sometimes some file manufacturer give  you just a PDF file with all the registers you need to to write yourself some other manufacturer it  was okay for me for Marvel they give you directly a c source code file which can be easily integrated  and in this case i had a custom reset procedure so in i talked already about this use case in  linux but at huboot it's the generic file reset routine it gets unconditionally called and i'm  i brought a small patch to allow to write your own custom file reset and by the time you see this  video maybe it will be already proposed upstream about close 45 support at first when i asked for  it and xp told me they didn't want to support it officially but finally a little bit later  i observed that they push the support at linux level only so it's not in huboot  in the meantime they gave me an official patch that i tested at huboot level and it worked  so i plan to to to to upstream it if possible in the near future at linux level nothing special  as i said the close 45 if you want to use it it's already in the canal since 2019  some debug tips there is a very useful command line called phi tool  here an example where i'm reading the standard register to entry to to to check the phi id for  instance so first parameter your your phi device name sorry your username then you have the address  physical address of your find and the register phi tool is using the mac driver and it is  functional only when the phi is correctly detected when you have such error unable to connect to phi  it's not it's not usable so you can use it to debug some link issue but not for phi detection  itself one alternative you want to send arbitrary command on the mdi bus one alternative that i'm  aware of maybe there are more is to use the huboot environment where you have mdio mi test command  it requires of course a minimum of bsp integration if you do everything at linux level and you have  the bare minimum at huboot for your for your board it could not work out of the box  other debug tip i should have no clue about what's happening and you really want to check that your  phi chip is alive normally as soon as it's it's proven up in rgmi i mod for instance this is the  one i debug the most um your um your phi is supposed to produce automatically uh rx clock at 25 mega  hertz or 125 megahertz depending on your on your speed you should check also the clock  symmetry you could have a clock asymmetry the rx clock which is produced by your phi should be the  same as the x clock produced by the mac so 25 25 125 125 um you have a doubt and you want to check  that the mdi bus is currently managed by your mac uh with the scope it's very easy as i said it's a  two megahertz uh by default in my case was maybe two three megahertz and think the standard set it  up to 12 megahertz and here you can observe the first frame on the scope in this case for instance  it's one of the first time i try to talk with a um close 45 mac uh phi and uh i try to talk with it  using close 22 and not the indirect mod uh the compatibility mod so after the turnaround time  uh the phi did respond zero so sometimes it doesn't respond um uh it will it will read the line but  sometimes it um it it responds zero that can happen when you are talking to a close 45 uh  phi uh using close 22 just an example  and uh what something really really useful is that at the beginning you can see the start  bit which differ between 22 and 45 so you can immediately check that your mac is talking the  correct frame format another debug tip um i talked already about um media converter to  to connect your developer pc to the local network of your tcu  um sometimes it's better to use the phi evaluation kit from the chip vendor which is also itself a  media converter but at least it's using exactly the same phi the same revision that the one uh  you are trying to bring up why because some early sample like engineering sample you might  might um you might use during bring up phase uh they are not always immediately fully compliant  uh with the standard uh the open alliance standard for automotive internet and they are not interoperable  uh with each other so for early bring up you might uh ask or if or just use directly if you can  take a phi evaluation kit from the chip vendor if you can  uh here are some reference link about the mdi o close 22 45 uh very useful i invite you to  read them and uh if you want a generic internet find introduction more kernel developer oriented  you can find open this file in the documentation of the kernel documentation at working phi.txt  and that's it i hope you enjoy the presentation and uh that it will help you to bring your own  phi thank you  want that people are can ask questions and get responses from you unfortunately it looks like  so that so far we don't have any questions yet but we still have plenty of time  i see one question from luca  yes okay so you mentioned the x-txt delay that the phi or the mac can add how do you know the  delay values is there any auto tuning auto training feature a standard procedure to measure the  required delay i'm not aware of any auto tuning uh auto training feature that we can imagine  um uh to be honest um i didn't really i'm not i cannot really answer that question  i managed to do it without any delay but normally it's your hardware engineer which is  designing a pcb we can answer that question but i know that in software you know you need absolutely  uh to not to not put a delay at both sides that's what i know um i'm sorry that's thank for the question  yeah in my experience that it's usually it doesn't work well at full speed if the delay is wrong but  uh apart from that it depends on the pcb layout uh yeah exactly  so  so  so  i don't know if it's visible in the in the stream that will be recorded but uh  t-p-rot t-p-o answer luca's question says that i dragam can help you to to find the delay value  i don't think the chat will be available in the recording so it's always a good idea to  okay  Okay, one question from Teresa.  Since there are no other questions, can I ask if Automotive Ethernet is changing and  how closely do you monitor communication standards?  I worked in Auto years ago and I remain an IEEE member.  So even if you are not a member of IEEE, there is another committee called Open Alliance.  And here in my company in Valeo, my colleague, which is a hardware engineer, is actively  following all the news and coming out of this Open Alliance committee.  We are already, I think, ourself part of this committee and this is a way for us to stay  close to all the news.  So the answer is basically be part of the Open Alliance.  Okay.  Yeah, what should we do?  It seems there's no other question.  Well, we still have the room until 2.30.  OK.  And even after that, we can continue in a private room.  But I don't think there will be a need for that.  OK.  Well, Ankurya wonders if Ethernet has a future in  automobile, because all he sees is the wascan,  flex-ray, and lint.  Yes.  I think there are all prisons, all these old buses.  But for Ethernet, I don't remember if I said it.  But it already went into mass production.  I think it 2008 in BMW car, luxury car.  But now, I think it's coming everywhere.  Yeah, usually these things start in the high end, cars first.  Yeah, exactly.  Luxury car, but.  Well, like Kendo, it was first in Mercedes S-Class,  if I remember correctly.  Was it at the end of the 80s or something like that?  So.  There's another question from Theresa  about what's the difference between auto and computer  communications.  What's the coolest component you use?  Well, as I said, it's a general question,  or only an Ethernet question.  Because on Ethernet question, as I said,  it's a physical medium standard, which is different.  Basically, 10,000 base T1 or TX or T and so on.  But they're all Ethernets.  And then the physical medium change.  This is a many different.  But behind that, it's always Ethernet protocol.  But then, if it's a more general question,  maybe you can elaborate, Theresa.  This communication inside the car itself,  or between car, for instance.  What is the.  OK, I will answer first what is the coolest component you use.  What's the newest components that we have in automobile?  Communication are basically V2X, vehicle to everything,  which is using as a radio layer.  It can use the Wi-Fi or mobile network.  And you have also 5G modem.  That are the coolest component.  Our very precise GNSS module.  So we have now, which allow you to have a centimeter resolution.  Speaking about Ethernet specifically,  I find this automotive very interesting,  because it manages to do with just the two wires.  And I'm wondering whether that will show up  in other areas as well.  In buildings, it's probably not going  to happen that soon, because they're already  equipped with 8 wire cable infrastructure anyway.  I wonder myself also the same question.  Why do we not have automotives?  So Ethernet in the building and so on.  One of the first answer is that you  are not allowed to have a so long cable using automotive.  Basically, it's around 15 meters.  But you don't care in automotive to use a 100 meter long cable.  Yeah, I don't think I have that long cable in my house.  15 meters would be really small.  Yes, but then you need to have a mediaconverter in your house.  It's like people who are using fiber optical for their LAN  network.  They need also to put everywhere a transceiver.  And Thérèse is asking another question,  but I'm afraid I cannot answer all of them.  What is the widest specification, crazy, current,  wired package?  Are electric vehicles requiring many far different parts  than IC?  Just remembering an IGBT, I don't know what is it,  75 ampere and a brake unit immersed in brake fluid.  I'm not so specialist in automotive as I said.  I'm here in value since three years.  And Mati has another question for you.  If automotive and software, they always bring safety and bureaucracy  to my mind.  Is this visible at your work too?  Well, automotive and software always bring safety and bureaucracy.  Yes, there is one thing which is if I feel it correctly  and understood it correctly, in automotive world,  you have the car manufacturer.  They are leading the way.  They are the master, the king of the world.  And then you have the tier one, tier two,  I mean the different car equipment manufacturer.  And what I know is that they are driving  some very strict standard.  It's basically not bureaucracy, but it's just  project, very strict project management standard  with requirement and so on, risk management, et cetera.  So yes, it is visible in my work.  I am myself, most of the time working not directly  with a project which are already in mass production.  I'm at some R&D level, so I have more freedom, let's say.  And I don't feel this pressure on my shoulder all the time.  But when I'm working also from time to time  to help mass production and project, product,  then yes, it's visible.  Shhh.  That's all.  Shhh.  Shhh.  Shhh.  Right.  Shhh.  Shhh.  Shhh.  So Luca has another question about A2B, automotive audio bus.  And he's wondering whether it's gaining adoption on real world automotive.  Yes.  So Luca, at least I saw A2B components on some PCB.  I saw on some schematic.  I didn't work personally with it.  But recently, yes, I saw it in some project.  So yes, it's gaining attraction.  I think it's also part of some requirements from some car manufacturer.  Even if I'm not working directly during the RFQ phases,  I know it's gaining adoption.  Yes.  Shhh.  Shhh.  And either has a question about reference clock, which is an input to both the Mac and the PHY.  And he's wondering if you've ever seen a device that generates the clock.  Shhh.  And either if you do you mean that it's a clock signal signal for the RGMI database.  I never saw any other device that generates the clock.  There is a Mac and the PHY on one side and the other.  But no, I never seen a device that generates the clock.  I'm aware of the RX clock and TX clock when using RGMI.  When using SGMII, I think there is no such clock.  I'm not sure.  I don't know about that.  The fact that I never seen a device that generates such clock.  I don't know.  Yes, 15.  RMII.  Sorry, I'm not very familiar with RMII.  I don't know if it's still widely used.  So I assume it's what it's just 100 megabit maybe.  So wait.  I don't know.  I don't know.  I don't know.  I don't know.  I don't know.  I don't know.  I don't know.  I don't know.  I don't know.  You are mute, Gert.  You are mute.  Mati has a final question about automated drivers, the systems and internet and safety with Linux.  Oh, yes.  What's that safety concern?  As far as I know, we are not using a specific real-time Linux or something else in our TCU.  I don't know.  I don't know.  I don't know.  I don't know.
automotive_eth_phy_0_155.png automotive_eth_phy_156_1619.png automotive_eth_phy_1620_2075.png automotive_eth_phy_2076_2903.png automotive_eth_phy_2904_3827.png automotive_eth_phy_3828_5411.png automotive_eth_phy_5412_7151.png automotive_eth_phy_7152_12023.png automotive_eth_phy_12024_13775.png automotive_eth_phy_13776_15191.png automotive_eth_phy_15192_17963.png automotive_eth_phy_17964_18335.png automotive_eth_phy_18336_21071.png automotive_eth_phy_21072_21299.png automotive_eth_phy_21300_21755.png automotive_eth_phy_21756_21899.png automotive_eth_phy_21900_24263.png automotive_eth_phy_24264_24443.png automotive_eth_phy_24444_26423.png automotive_eth_phy_26424_29663.png automotive_eth_phy_29664_32135.png automotive_eth_phy_32136_33239.png automotive_eth_phy_33240_33311.png automotive_eth_phy_33312_33539.png automotive_eth_phy_33540_35903.png automotive_eth_phy_35904_36971.png automotive_eth_phy_36972_40343.png automotive_eth_phy_40344_40703.png automotive_eth_phy_40704_42695.png automotive_eth_phy_42696_45971.png automotive_eth_phy_45972_46031.png automotive_eth_phy_46032_46739.png automotive_eth_phy_46740_47603.png automotive_eth_phy_47604_48203.png automotive_eth_phy_48204_48527.png automotive_eth_phy_48528_49643.png automotive_eth_phy_49644_49739.png automotive_eth_phy_49740_49787.png automotive_eth_phy_49788_50195.png automotive_eth_phy_50196_50243.png automotive_eth_phy_50244_50303.png automotive_eth_phy_50304_51119.png automotive_eth_phy_51120_51323.png automotive_eth_phy_51324_51443.png automotive_eth_phy_51444_53663.png automotive_eth_phy_53664_56135.png automotive_eth_phy_56136_56195.png automotive_eth_phy_56196_56255.png automotive_eth_phy_56256_56567.png automotive_eth_phy_56568_56963.png automotive_eth_phy_56964_59831.png automotive_eth_phy_59832_60191.png automotive_eth_phy_60192_61331.png automotive_eth_phy_61332_61979.png automotive_eth_phy_61980_62627.png automotive_eth_phy_62628_62711.png automotive_eth_phy_62712_62759.png automotive_eth_phy_62760_62927.png automotive_eth_phy_62928_63947.png automotive_eth_phy_63948_64379.png automotive_eth_phy_64380_65063.png automotive_eth_phy_65064_65147.png automotive_eth_phy_65148_65267.png automotive_eth_phy_65268_65483.png automotive_eth_phy_65484_66071.png automotive_eth_phy_66072_66335.png automotive_eth_phy_66336_67679.png automotive_eth_phy_67680_69179.png automotive_eth_phy_69180_69887.png automotive_eth_phy_69888_70631.png automotive_eth_phy_70632_70787.png automotive_eth_phy_70788_72491.png automotive_eth_phy_72492_72743.png automotive_eth_phy_72744_73379.png automotive_eth_phy_73380_74627.png automotive_eth_phy_74628_75335.png automotive_eth_phy_75336_75731.png automotive_eth_phy_75732_75791.png automotive_eth_phy_75792_79559.png automotive_eth_phy_79560_79811.png automotive_eth_phy_79812_79871.png automotive_eth_phy_79872_80507.png automotive_eth_phy_80508_81983.png automotive_eth_phy_81984_82871.png automotive_eth_phy_82872_88547.png automotive_eth_phy_88548_88751.png automotive_eth_phy_88752_89171.png automotive_eth_phy_89172_90143.png automotive_eth_phy_90144_90262.png
you you Hello everyone, my name is Jean-Louis Tekekara and today I'm here to talk about the bring up of automotive Ethernet files. Quick self-introduction, I'm an embedded Linux engineer since 2010. I started to work in Paris in a company called OpenWide, which is an open source consulting company, and then later in Parod drones. Then I joined Valeo Telematic here in Frankfurt area to develop TCUs. TCUs are basically boxes which connect your car to the internet over 4G, now 5G network, and also give you positioning solutions based on GNSS and dead reckoning for instance. I'm myself not an automotive expert, I just want to share with you my humble experience. Here are the goals and expectations. You should know the basics about Ethernet files. In our case we will talk about automotive Ethernet files, but the work should be the same for standard Ethernet files. You will have an overview of what tasks you should expect when you bring up an Ethernet file in embedded Linux environment. I will share with you some common bring up issues and some deep bell tips. This presentation is based on an internal presentation I already gave last year in Valeo Group. Here's the agenda. So first, a very small slide about why we are talking about Ethernet in the automotive world. Then to be sure we are on the same line, we will define some technical terms and describe the basic architecture. Then we will list all the file configuration, everything you should know about your file before starting the actual software implementation. Then the software implementation itself, and then some debug tips and questions. So why do we have Ethernet in our vehicles? It's simple because we need for always more bandwidth, not only software update use case, but you can think about any advanced driver assistance systems, use cases and also infotainment, etc. There is also a need for standardization. There are already a lot of competing solutions which give you more bandwidth than the old traditional network like KAN Flex Ray which give you only a few megabits. So there are competing solutions like most, for instance, but there are proprietary solutions. Why do we use automotive Ethernet and not standard Ethernet? Because in the automotive world you need to pass very strict electromagnetic compatibility test and automotive Ethernet allow you to do that because it's using only one twisted pair, most of the time unshielded, and so it's very lightweight and it has a lower cost compared to traditional category 5, 6 Ethernet cable. So let's talk about some technical terms. So the file itself in the blue box here, this is basically a transceiver, this is translating or more precisely this is modulating your data which are on the PCB on one side to the external world which is just this twisted pair. The Mac itself, so it's an Ethernet controller, this is integrated into your application processor and this Mac is controlling the Ethernet file over a dedicated control bus which is called MDIO bus, it's a low speed bus with a clock of a few megahertz. Actually it's not directly the Mac which is controlling your file over the same bus, there is another entity, it's called the STA or SME station management entity and into your application processor you could have many Mac, many Ethernet devices but usually only one station management entity. And you have also the high speed database which could be for instance HGMI or RGMI. Oh I didn't say that but it could happen that on some application processor, for instance I know I'm aware at least about some Qualcomm processor they have the Ethernet file already integrated into the Mac. I will talk more about the use case I know, I work many with the IMX8 processor. So file configuration checklist, that is the file address. So this address is used by the Mac to find the file on the MDIO bus and start to talk with it. The IEEE standard set up to 32 files on the MDIO bus as you can see in this example of frame format sent over the MDIO bus there are only 5 bits dedicated to the file address. This file address is bootstrapped at 5 power up. Bootstrap basically means you have for instance some resistors to some dedicated pins and at power up the file is reading out the voltage on this pins and then it decides its own address. This is normally documented in your file data sheet and you need to check just your board schematic. Another item, what is the PHY mode, master or slave? Most of the time you want your TCU to be in slave mode because your endpoints in the vehicle which could be an Ethernet switch is in master. In our test setup when you are developing and bringing up your PHY you have normally a device called media converter which allows your PC to be part of the local network of your TCU and then you need to put this media converter into master. As you can maybe see on the slide the media converter is just basically one microcontroller. On one side you have the automotive Ethernet PHY to connect your TCU and on the other side you have a standard Ethernet PHY and an RG45 connector, standard connector to connect your PC. This mode is of course always bootstrapped and you should ask yourself also if the rest of the bootstrap configuration is consistent with your use case you can select the bandwidth 100 versus 1000 megabits the MII mode sometimes you can enable some delay, internal delay in the PHY etc and it can happen that you could even change the voltage level in software in your PHY so you should pay attention to that. So in general most bootstrap parameters can be overwritten later over the MDO bus during the PHY initialization over for not only for a fast bringer but in all the cases it's really recommended to use as much as possible the bootstrap method if you use case are not changing. So what is the init sequence for the PHY? At the beginning the PHY requires proprietary and under NDA initialization sequence which consists of a list of write sequence on the MDO bus. So write call or function looks like that you have the register the value and you have something called the dev add in which can translate to device address. Be careful this is not the PHY address it's just because to make it simple on modern PHY you have a lot of registers much more than what allow you register address space here so you have also we can say kind of virtual devices inside the PHY and this dev add parameter gives you an additional level of indirection to access these internal devices. There are historical reasons for this. So here just an example you have a kernel function called PHY write and then you have the dev add register value and one could imagine you put all this PHY write enrolling in a loop and this is your init sequence. It must be very carefully selected the source of confusion you need to triple check this init sequence with your vendor. Must match exact revision even if you have different variant like engineering sample 1, 2 and then the mass production sample it could change over the life early life of your internet PHY. There are two places to start the software implementation the bootloader which could be Uboot for instance and then the kernel unless you have a very specific use case and you need to have network access from the bootloader you can implement only the kernel this is what we do most of the time. Anyway the kernel level implementation is always needed for obvious reasons and if you implement it only the if you implement it at two places then when you have some software update maintenance you need to update at both places so. Quick reminder the MDO bus is controlled by the Mac driver this is provided by the your vendor BSP and thus this MDO bus control should work out of the box you are not expected to do any implementation on debug at this level. About close 22 close 45 you have already you had already an overview of what a frame looks like on the MDO bus. I will not cover this in this presentation but there are references at the end that you can invite you to follow. Basically there are PHYs which understand only close 22 format other they are close 45 but this is backward compatible so you can talk to them in a special close 22 indirect mode. It depends on your PHY most of the time instead of the art today that if your Mac can only talk in close 22 you can always somehow find your way to talk to the Ethernet PHY. So let's list the remaining work. First step you need to adapt your born hardware description so device 3 in the Linux world. You need to adapt an existing PHY driver or write your own PHY driver then check that the PHY is detected and your driver is correctly loaded and finally check and debug your link which needs to be up of course to start to do actual communication. So for instance if we take an example here this is based on AMX 8 you have a block describing your your Mac device so it could be called FEC in AMX world but on Qualcomm processor it could be eMac for instance of course needs to be activated. Then the PHY mode attributes needs to be correct here you can notice it's not only rgmii versus hgmii or just mii you have kind of variance suffixes here in this case this suffix is telling the the Mac to not put any delay inside because I'm already managing myself the delay in hardware in the PHY itself for instance. After that you have another block here which is describing your PHY and you have also most of the time as far as I know there is only one PHY for one Mac you have this PHY handle which is pointing at this PHY here you need to check that the PHY address is correct so this is a reg attribute here here my physical address is 10 and for more details of course you have the documentation of the device to itself and so either net PHY and so you have of course the documentation of your own Mac driver after that you need to locate the PHY drivers they are in driver net PHY what is recommended because unfortunately most of the time your new shiny automotive is a net PHY its driver is not existing in the main line so what is recommended even by our cheap manufacturer is to locate one existing driver which looks like the most to the PHY you want to implement one effective way to locate a similar PHY would be to to to to grab the PHY ID which is a unique identifier of your PHY which is stored inside the PHY itself in the standard register two and three and then when you find a good candidate you can start to use it so you can if possible reuse sometimes you can reuse existing function if you don't find any anything you can open a new file or just modify your driver formatly the same brand so when you open your PHY driver you need to define the PHY ID you have the PHY mask also which helps you to map and to to match basically the PHY ID you are finding on the bus you also need to give a name which is then later displayed in the channel messages so you are sure your driver is actually loaded and then you have what we can call primitives routines which are used by the standard PHY framework or by your Mac driver sorry and for instance you have some primitives like config init that need always to be rewritten config init is a good place where you can put your PHY init sequence for instance you can reuse other which are very standard for instance soft reset here it's using already define a PHY reset routine here but behind that it's it could only set one standard bit to reset the PHY and then you don't you don't have any specific soft specific PHY reset sequence because it's very generic and most of the PHYs respect the standard about config init this is called immediately after reset and so this is why you put your init sequence you can put also any other parameter enforcement like master slave for instance or other custom parameter so one effective way to do so is to put your your init sequence in an array of struct and providing the fact that all of this register and value right there on the same dev addy you can put them in loop like that and that's it you have your init sequence about config auto negotiation in my experience in our own use cases we are not using auto negotiation by the way this is defined in the triple high triple E standard as optional in automotive is an it is optional some PHYs they don't even implement auto negotiation some claims they support auto negotiation but it doesn't work also so one effective implementation is just to set this one line code you set the speed of your PHY device to one gigabit for instance and that's it you have you have you have it for other primitive like suspend resume soft reset etc unless your PHY simulator has a really explicitly defined routine for a fast bring up it's safe to not implement them they are in the PHY driver framework they are generic implementations that are automatically used normally to get PHY up and to have your first link up the correct init sequence is all you need for a better detailed description of all the the primitives i invite you to check this header PHY so include linux PHY.h so check the PHY is detected so if everything works you have a attached PHY driver message and the name the string of the PHY name you put in the driver if you have an hardware failure or just a bad PHY address you will have mda device address 10 is missing for instance and unable to connect to PHY sometimes the PHY is found on the on the bus but your PHY driver is not loaded because for instance of an inco-align PHY ID in this case there is a generic PHY genetic driver which is loaded in my experience you cannot do much with this generic PHY then you need to check the link is up of course you can check your media converter or with ip command on linux command source of link issues your PHY init sequence is incorrect in this case it's not so easy to debug but you can always contact your your PHY the other endpoint is not in master when the PHY is in slave or the other way around and you have a delay issue you can you can put a delay internal delay in the PHY or in the Mac but never at both sides I bought usually but never this is what has been recommended by our cheap manufacturer as well and I'm not a specialist of this topic but you should ask your your preferred automotive hardware engineer you could have an hardware issue on the on the physical channel itself or just after your PHY and before the connector you have some components which are there to help basically to pass the electromagnetic compatibility test and so on for instance you have a component called CMC command mode shock which could be which could not work or broken just broken physical channel let's talk about some huboot patch when you are using iMix iMix 8 and you have a gigabit file you need to make sure you have this defined set fc quirk in net mac otherwise you have one specific bit which is not being set correctly in the mac in one of the mac registers this define is by default already set in some board configuration in huboot it's in include config.h but it can it could be that you don't have that in your own board or the board you are describing or writing yourself so actually recently since last year since this patch this define is now set one level above in one of the top level iMix 8 header so you should have no worries unless you are using you know that on in the iMix 8 world you are using a fork from huboot huboot dash iMix 8 no huboot dash iMix which is managed by by nxp and it's also on code or so you might not have always the latest huboot coming with your iMix 8 BSP sometimes you you could have a file that needs your custom reset procedure i forgot to say that about the init sequence sometimes some file manufacturer give you just a PDF file with all the registers you need to to write yourself some other manufacturer it was okay for me for Marvel they give you directly a c source code file which can be easily integrated and in this case i had a custom reset procedure so in i talked already about this use case in linux but at huboot it's the generic file reset routine it gets unconditionally called and i'm i brought a small patch to allow to write your own custom file reset and by the time you see this video maybe it will be already proposed upstream about close 45 support at first when i asked for it and xp told me they didn't want to support it officially but finally a little bit later i observed that they push the support at linux level only so it's not in huboot in the meantime they gave me an official patch that i tested at huboot level and it worked so i plan to to to to upstream it if possible in the near future at linux level nothing special as i said the close 45 if you want to use it it's already in the canal since 2019 some debug tips there is a very useful command line called phi tool here an example where i'm reading the standard register to entry to to to check the phi id for instance so first parameter your your phi device name sorry your username then you have the address physical address of your find and the register phi tool is using the mac driver and it is functional only when the phi is correctly detected when you have such error unable to connect to phi it's not it's not usable so you can use it to debug some link issue but not for phi detection itself one alternative you want to send arbitrary command on the mdi bus one alternative that i'm aware of maybe there are more is to use the huboot environment where you have mdio mi test command it requires of course a minimum of bsp integration if you do everything at linux level and you have the bare minimum at huboot for your for your board it could not work out of the box other debug tip i should have no clue about what's happening and you really want to check that your phi chip is alive normally as soon as it's it's proven up in rgmi i mod for instance this is the one i debug the most um your um your phi is supposed to produce automatically uh rx clock at 25 mega hertz or 125 megahertz depending on your on your speed you should check also the clock symmetry you could have a clock asymmetry the rx clock which is produced by your phi should be the same as the x clock produced by the mac so 25 25 125 125 um you have a doubt and you want to check that the mdi bus is currently managed by your mac uh with the scope it's very easy as i said it's a two megahertz uh by default in my case was maybe two three megahertz and think the standard set it up to 12 megahertz and here you can observe the first frame on the scope in this case for instance it's one of the first time i try to talk with a um close 45 mac uh phi and uh i try to talk with it using close 22 and not the indirect mod uh the compatibility mod so after the turnaround time uh the phi did respond zero so sometimes it doesn't respond um uh it will it will read the line but sometimes it um it it responds zero that can happen when you are talking to a close 45 uh phi uh using close 22 just an example and uh what something really really useful is that at the beginning you can see the start bit which differ between 22 and 45 so you can immediately check that your mac is talking the correct frame format another debug tip um i talked already about um media converter to to connect your developer pc to the local network of your tcu um sometimes it's better to use the phi evaluation kit from the chip vendor which is also itself a media converter but at least it's using exactly the same phi the same revision that the one uh you are trying to bring up why because some early sample like engineering sample you might might um you might use during bring up phase uh they are not always immediately fully compliant uh with the standard uh the open alliance standard for automotive internet and they are not interoperable uh with each other so for early bring up you might uh ask or if or just use directly if you can take a phi evaluation kit from the chip vendor if you can uh here are some reference link about the mdi o close 22 45 uh very useful i invite you to read them and uh if you want a generic internet find introduction more kernel developer oriented you can find open this file in the documentation of the kernel documentation at working phi.txt and that's it i hope you enjoy the presentation and uh that it will help you to bring your own phi thank you want that people are can ask questions and get responses from you unfortunately it looks like so that so far we don't have any questions yet but we still have plenty of time i see one question from luca yes okay so you mentioned the x-txt delay that the phi or the mac can add how do you know the delay values is there any auto tuning auto training feature a standard procedure to measure the required delay i'm not aware of any auto tuning uh auto training feature that we can imagine um uh to be honest um i didn't really i'm not i cannot really answer that question i managed to do it without any delay but normally it's your hardware engineer which is designing a pcb we can answer that question but i know that in software you know you need absolutely uh to not to not put a delay at both sides that's what i know um i'm sorry that's thank for the question yeah in my experience that it's usually it doesn't work well at full speed if the delay is wrong but uh apart from that it depends on the pcb layout uh yeah exactly so so so i don't know if it's visible in the in the stream that will be recorded but uh t-p-rot t-p-o answer luca's question says that i dragam can help you to to find the delay value i don't think the chat will be available in the recording so it's always a good idea to okay Okay, one question from Teresa. Since there are no other questions, can I ask if Automotive Ethernet is changing and how closely do you monitor communication standards? I worked in Auto years ago and I remain an IEEE member. So even if you are not a member of IEEE, there is another committee called Open Alliance. And here in my company in Valeo, my colleague, which is a hardware engineer, is actively following all the news and coming out of this Open Alliance committee. We are already, I think, ourself part of this committee and this is a way for us to stay close to all the news. So the answer is basically be part of the Open Alliance. Okay. Yeah, what should we do? It seems there's no other question. Well, we still have the room until 2.30. OK. And even after that, we can continue in a private room. But I don't think there will be a need for that. OK. Well, Ankurya wonders if Ethernet has a future in automobile, because all he sees is the wascan, flex-ray, and lint. Yes. I think there are all prisons, all these old buses. But for Ethernet, I don't remember if I said it. But it already went into mass production. I think it 2008 in BMW car, luxury car. But now, I think it's coming everywhere. Yeah, usually these things start in the high end, cars first. Yeah, exactly. Luxury car, but. Well, like Kendo, it was first in Mercedes S-Class, if I remember correctly. Was it at the end of the 80s or something like that? So. There's another question from Theresa about what's the difference between auto and computer communications. What's the coolest component you use? Well, as I said, it's a general question, or only an Ethernet question. Because on Ethernet question, as I said, it's a physical medium standard, which is different. Basically, 10,000 base T1 or TX or T and so on. But they're all Ethernets. And then the physical medium change. This is a many different. But behind that, it's always Ethernet protocol. But then, if it's a more general question, maybe you can elaborate, Theresa. This communication inside the car itself, or between car, for instance. What is the. OK, I will answer first what is the coolest component you use. What's the newest components that we have in automobile? Communication are basically V2X, vehicle to everything, which is using as a radio layer. It can use the Wi-Fi or mobile network. And you have also 5G modem. That are the coolest component. Our very precise GNSS module. So we have now, which allow you to have a centimeter resolution. Speaking about Ethernet specifically, I find this automotive very interesting, because it manages to do with just the two wires. And I'm wondering whether that will show up in other areas as well. In buildings, it's probably not going to happen that soon, because they're already equipped with 8 wire cable infrastructure anyway. I wonder myself also the same question. Why do we not have automotives? So Ethernet in the building and so on. One of the first answer is that you are not allowed to have a so long cable using automotive. Basically, it's around 15 meters. But you don't care in automotive to use a 100 meter long cable. Yeah, I don't think I have that long cable in my house. 15 meters would be really small. Yes, but then you need to have a mediaconverter in your house. It's like people who are using fiber optical for their LAN network. They need also to put everywhere a transceiver. And Thérèse is asking another question, but I'm afraid I cannot answer all of them. What is the widest specification, crazy, current, wired package? Are electric vehicles requiring many far different parts than IC? Just remembering an IGBT, I don't know what is it, 75 ampere and a brake unit immersed in brake fluid. I'm not so specialist in automotive as I said. I'm here in value since three years. And Mati has another question for you. If automotive and software, they always bring safety and bureaucracy to my mind. Is this visible at your work too? Well, automotive and software always bring safety and bureaucracy. Yes, there is one thing which is if I feel it correctly and understood it correctly, in automotive world, you have the car manufacturer. They are leading the way. They are the master, the king of the world. And then you have the tier one, tier two, I mean the different car equipment manufacturer. And what I know is that they are driving some very strict standard. It's basically not bureaucracy, but it's just project, very strict project management standard with requirement and so on, risk management, et cetera. So yes, it is visible in my work. I am myself, most of the time working not directly with a project which are already in mass production. I'm at some R&D level, so I have more freedom, let's say. And I don't feel this pressure on my shoulder all the time. But when I'm working also from time to time to help mass production and project, product, then yes, it's visible. Shhh. That's all. Shhh. Shhh. Shhh. Right. Shhh. Shhh. Shhh. So Luca has another question about A2B, automotive audio bus. And he's wondering whether it's gaining adoption on real world automotive. Yes. So Luca, at least I saw A2B components on some PCB. I saw on some schematic. I didn't work personally with it. But recently, yes, I saw it in some project. So yes, it's gaining attraction. I think it's also part of some requirements from some car manufacturer. Even if I'm not working directly during the RFQ phases, I know it's gaining adoption. Yes. Shhh. Shhh. And either has a question about reference clock, which is an input to both the Mac and the PHY. And he's wondering if you've ever seen a device that generates the clock. Shhh. And either if you do you mean that it's a clock signal signal for the RGMI database. I never saw any other device that generates the clock. There is a Mac and the PHY on one side and the other. But no, I never seen a device that generates the clock. I'm aware of the RX clock and TX clock when using RGMI. When using SGMII, I think there is no such clock. I'm not sure. I don't know about that. The fact that I never seen a device that generates such clock. I don't know. Yes, 15. RMII. Sorry, I'm not very familiar with RMII. I don't know if it's still widely used. So I assume it's what it's just 100 megabit maybe. So wait. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. You are mute, Gert. You are mute. Mati has a final question about automated drivers, the systems and internet and safety with Linux. Oh, yes. What's that safety concern? As far as I know, we are not using a specific real-time Linux or something else in our TCU. I don't know. I don't know. I don't know. I don't know.
Linux environment. I will share with you some This presentation is based on an internal presentation I already gave last year in Valeo everything you should know about your file before starting the actual software implementation. Then developing and bringing up your PHY you have on the bus you also need to give a name which is delay internal delay in the PHY or in the Mac but integration if you do everything at linux level yeah in my experience that it's usually it Automotive Ethernet is changing and how closely