Currently, the BSP appendix (Appendix A) in the YP Development manual uses the Crown Bay BSP as a base BSP to step the user through an example to create their own "mymachine" BSP.  Suggestions have been made to replace that example with one that uses a BSP suitable for cheaper and more prevalent hardware such as Cedar Trail.  The suggestion is good and we could update the example when we have the BSP available.  

Credits to Jim Abernathy for making the suggestion.  Here is the original text of Jim's email.  It has other suggestions surrounding the BSP example as well:

------------------- EMAIL Abernathy --------------------------------------

Well, the thinking is like this. Appendix A should always be a clear example of creating your own real BSP based off of an existing one that could run on real hardware.  Meaning, if I follow the steps by cutting and pasting the command boxes, I could create the BSP image and it would run on  the real hardware.  Using a hardware platform that was cheap would increase the benefit of the example because customer could easily and cheaply duplicate and learn from it.  Crownbay was expensive due to its ECG/ISB history of development.  Changing to cheaply available hardware platforms in the future would good.  For example Marshalltown for Cedartrail and Pandaboard for ARM TI OMAP4.

Right now Crownbay NOEMGD is a good example, even though I’d prefer it to be with EMGD.  Personal preference.  However, Tunnel Creek is getting long in the tooth and Cedar trail is a good replacement.  We can do the update to the Appendix now for Non-accelerated GFX, or wait until the team finishes.  As we move Yocto forward, we would have to update the instructions in the Appendix anyway, so we should update the platform to the most modern platform that is easy for customers to get their hands on.  I like the Marshalltown because it’s really cheap, like the Beagleboard is for TI OMAP.

What would really make Yocto shine would be an example like appendix A that did the same build for both Marshalltown and Pandaboard, changing only what had to be changed to support the low-level hardware differences.  If we did it right, we’d show off the flexibility of Yocto for use on multiple hardware architectures, but also let people see side by side that IA is better than ARM on the best software you can test with.  This is bigger than current App. A because it assumes Hardware accelerated Video GFX would have to work on both architectures.

BTW, I would love to see a location where we could store the old “Appendix A” examples for people who want to use them on the old hardware, as we update the main doc to the latest.  Maybe Wiki?  We could just keep collecting them and state at what point it was edited and tested last, Like Edison, Bernard, etc.   The community could update the instructions and retest if they cared to.

Some additional comments about Appendix A for what they are worth.

Appendix A with some editing can be a real hardware example to load on a Customer Reference Board, Crownbay, and used with normal VESA graphics.   At present it refers to PC-Common/atom PC instead of standard/crownbay. 

I have taken App. A and expanded it to also use EMGD, which we document in various READMEs. 

I have also created my own Appendix A for n450 (attached) for use on a real ICDB D410PT board, which is now obsolete, and I’ve also done my version of it for meta-cedartrail to use on real hardware, the Marshalltown, a cheap ICBD board