I stumbled across the concept of device tree overlays while trying to get my stuff to work with kernel 4.x, and it sounded like a great idea. When next I have to muck around with the device tree (likely the next kernel upgrade from what I¹ve seen) I¹ll revisit overlays.
‹ Tim Tim Kennedy G5 Infrared 603/204.5722 x33 www.g5ir.com On 6/8/16, 9:38 PM, "Phil Reid" <[email protected]> wrote: >On 9/06/2016 05:56, mgerlach wrote: >> >> Hi Everyone, >> >> This discussion of creating device trees especially in the context of >> upgrading linux is extremely relevant. I have experienced my fair of >>pain >> debugging device trees during kernel upgrades, and this pain is a >>frequent >> topic >> at the various Linux conferences. It is safe to say, this problem is >>not >> unique to SOCFGPAs, but the FPGA can make the pain more acute. >> >> As some background, sopc2dts is an Open Source tool that can help make >> device >> trees based on a FPGA designs described in a "sopcinfo" file produced by >> Altera design tools. Sopc2dts predates SOCFPGAs and was created by >> Walter Goossen originally for Linux running on Nios-II. Sopc2dts can >> also be used to make device trees for SOCFPGAs, but as many folks have >> pointed out, the output of sopc2dts does not always produce suitable >> device >> trees for every version of the Linux kernel. >> >> The SoC Embedded Development Suite (SoCEDS) includes a snapshot of >> sopc2dts and >> a set of "board info" files that can be used to create device trees for >> the >> the reference designs using the kernel version shipped with that version >> of SoCEDS. Version 16.0 of SoCEDS shipped with linux-3.10-ltsi. >> >> When upgrading kernels, the process people have described by taking the >> base >> device tree found in the kernel version's source tree and merging it >>with >> the FPGA portion of the output to Sopc2dts is a perfectly reasonable >>work >> flow. Interestingly, this work flow has similarities to using dynamic >> device tree overlays in the boot flow. >> >> With dynamic device tree overlays, Linux could boot using the minimum >> device >> tree to get to user space. Once in user space, one or more overlays >>could >> be >> applied to the live device tree in order to enable more components on >>the >> SoC, >> program the FPGA, and instantiate necessary drivers for components in >>the >> FPGA. >> I think such a boot flow would be easier to debug and provide >>substantial >> flexibility to manage the overall boot flow. I would like to hear what >> other folks think about using dynamic device tree overlays. >> > >G'day Matthew, > >Yes, I think using device tree overlays is the way to go. >Our planned product range is going to use a common SOC / CPU board that >plugs into >different base (mother) boards. It would be ideal to be able to deploy a >bare minimum >device tree to boot the cpu and then have it probe what it was attached >to. >We'd probably require a simple FPGA image to be loaded to assist with >probing. >Then reload the appropriate FPGA image and corresponding device tree. >This does seem to be the direction that everything is heading towards >within the kernel. > >I haven't found time yet to test the dynamic dts support in the linux >kernel. >Our reloading fpga images either. > >-- >Regards >Phil Reid > >_______________________________________________ >Rfi mailing list >[email protected] >http://lists.rocketboards.org/cgi-bin/mailman/listinfo/rfi _______________________________________________ Rfi mailing list [email protected] http://lists.rocketboards.org/cgi-bin/mailman/listinfo/rfi
