Building the Board Support Packages

Hello TO all

guys I want to know that how to make a BSP ( Board support Packages ) for a
new hardware using Linux kernel.

I mean is there any tutorial in regard with this topic.

Also what are the basic requirements in order to move in this direction.


Actually I want to practice it and want to test it on the virtual emulator
like Qemu and than I will port it to my new hardware.



Thanks.

Piyush Pandey	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On Sun, 13 May 2012 09:20:43 -0500, piyushpandey wrote:

> Hello TO all
> 
> guys I want to know that how to make a BSP ( Board support Packages )
> for a new hardware using Linux kernel.
> 
> I mean is there any tutorial in regard with this topic.
> 
> Also what are the basic requirements in order to move in this direction.
> 
> 
> Actually I want to practice it and want to test it on the virtual
> emulator like Qemu and than I will port it to my new hardware.

The subject is too big for a tutorial.  There should be books, though.

Get onto Amazon, start looking through the books on embedded Linux, and 
find one with a table of contents that seems helpful.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

On 5/13/2012 7:20 AM, piyushpandey wrote:
> Hello TO all
>
> guys I want to know that how to make a BSP ( Board support Packages ) for a
> new hardware using Linux kernel.
>
> I mean is there any tutorial in regard with this topic.

I would imagine the best approach would be to grab as many
BSP's that you can find *especially* if you have access to
the schematics (or some equally detailed hardware description)
so you can see how the BSP hooks map to the actual hardware
being used.

There are organizations that do this sort of thing as their
core business.  And, many do it to *support* their core
business (i.e., SoC vendors).

> Also what are the basic requirements in order to move in this direction.

#1 is a good understanding of the *hardware*.
#2 is a good understanding of software!

Simple, eh?  :>

> Actually I want to practice it and want to test it on the virtual emulator
> like Qemu and than I will port it to my new hardware.

Huh?  Qemu sits *above* the hardware.  I don't see what you
are trying to achieve with this approach.  I would imagine
you want to run the BSP on the *actual* hardware and verify
that you can talk to it in much the same ways that the Linux
kernel will.  I.e., your first hurdle is being able to
get code running on bare iron (do you know how to link
for specific hardware addresses?  what tools do you have to
inject the firmware into that hardware?  what tools do you have
for interacting with it to verify its proper operation?  etc.)

If time is cheaper than money, you might just start looking
for BSP's with a goal of trying to accrete enough from them
in toto to get a complete idea of what is required.

Of course, these will tend to only address the "common" bits
of I/O and processor core that you are likely to encounter.
If you've got anything "esoteric" onboard, you're on your
own for those aspects!

>I would imagine the best approach would be to grab as many
>BSP's that you can find *especially* if you have access to
>the schematics (or some equally detailed hardware description)
>so you can see how the BSP hooks map to the actual hardware
>being used.

yes I think you are right don , the best way to learn that how I can
understand to create the BSP is to have a look on the other companies
sources and packages.

So do you have any idea of such websites or anything else where I can get
the sources as you told.

>
>There are organizations that do this sort of thing as their
>core business.  And, many do it to *support* their core
>business (i.e., SoC vendors).

also don I want to know as the companies provide the technical refrences
about there microcontroller and how to use those controllers in the
projects, similarly do the companies developing the bsp provide refrences
about how to develop the BSP, if yes can you suggest me few of those
companies.


>
>> Also what are the basic requirements in order to move in this
direction.
>
>#1 is a good understanding of the *hardware*.

yes I agree don and I must tell you that I am a hardware engineer and have
designed many boards but all containing the 8 and 16 bit microcontrollers
like AVR, PIC and also controllers from the ST etc.

but this time I designed the hardware focussing the 32 bit ARM processor
from the ATMEGA AT91SAM microcontroller.

So as far as I know this is the forum which deals in the software part
mostly and not in the hardware and therefore I didn't disclosed anything
about my hardware.

>#2 is a good understanding of software!

yeah this is the area where I am trying to make my self strong so first of
all I am learning the C programming language and the linux working for it.
if anyhting else is required please instruct me about that in the software
arena.that will be really good as you guys are genius.

:) :)
>
>Simple, eh?  :>

yeah until I start doing it.


>
>> Actually I want to practice it and want to test it on the virtual
emulator
>> like Qemu and than I will port it to my new hardware.
>
>Huh?  Qemu sits *above* the hardware.  I don't see what you
>are trying to achieve with this approach.  I would imagine
>you want to run the BSP on the *actual* hardware and verify
>that you can talk to it in much the same ways that the Linux
>kernel will.  I.e., your first hurdle is being able to
>get code running on bare iron (do you know how to link
>for specific hardware addresses?  what tools do you have to
>inject the firmware into that hardware?  what tools do you have
>for interacting with it to verify its proper operation?  etc.)

I have not decided that yet and thought that first get the idea about the
BSP development and and get started with that than move to porting hardware
in between the development phase.

if that's a problem than can you please describe me that what hurdle I am
going to face if I didn't decided that how and which tools I am going to
use.


>
>If time is cheaper than money, you might just start looking
>for BSP's with a goal of trying to accrete enough from them
>in toto to get a complete idea of what is required.
>
>Of course, these will tend to only address the "common" bits
>of I/O and processor core that you are likely to encounter.
>If you've got anything "esoteric" onboard, you're on your
>own for those aspects!
>


I didn't get this one :( :(




thanks for your reply	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On 5/14/2012 8:49 AM, piyushpandey wrote:
>> I would imagine the best approach would be to grab as many
>> BSP's that you can find *especially* if you have access to
>> the schematics (or some equally detailed hardware description)
>> so you can see how the BSP hooks map to the actual hardware
>> being used.
>
> yes I think you are right don , the best way to learn that how I can
> understand to create the BSP is to have a look on the other companies
> sources and packages.
>
> So do you have any idea of such websites or anything else where I can get
> the sources as you told.

I don't have specific pointers.  Use your favorite search
engine to find "Linux BSP" or "<whateverOS> BSP".  You
might find offerings from *board* vendors (which may or may
not require you to be a current customer, etc.)

>> There are organizations that do this sort of thing as their
>> core business.  And, many do it to *support* their core
>> business (i.e., SoC vendors).
>
> also don I want to know as the companies provide the technical refrences
> about there microcontroller and how to use those controllers in the
> projects, similarly do the companies developing the bsp provide refrences
> about how to develop the BSP, if yes can you suggest me few of those
> companies.

Companies who provide BSPs most usually provide them for
*their* product offerings -- whether those are MCU's,
SoC's, SBC's, or whatever.

There are firms that offer a *service* to develop a BSP
FOR YOU.  But, that comes at a cost  :>

>>> Also what are the basic requirements in order to move in this
> direction.
>>
>> #1 is a good understanding of the *hardware*.
>
> yes I agree don and I must tell you that I am a hardware engineer and have
> designed many boards but all containing the 8 and 16 bit microcontrollers
> like AVR, PIC and also controllers from the ST etc.
>
> but this time I designed the hardware focussing the 32 bit ARM processor
> from the ATMEGA AT91SAM microcontroller.
>
> So as far as I know this is the forum which deals in the software part
> mostly and not in the hardware and therefore I didn't disclosed anything
> about my hardware.

My point is that you need to understand how the hardware can be
"told" to provide the service/functionality that the software
(driver, BSP, etc.) *requires*.

I.e., if you have a serial port, you need to understand how
to interface to the hardware for that serial port; how to
reconfigure it "on demand"; how to query its status; how to
ensure it doesn't "lock up"; etc.  All of these requirements
are dictated FROM ABOVE by the requirements of the system
under which you are implementing the driver/BSP.

>> #2 is a good understanding of software!
>
> yeah this is the area where I am trying to make my self strong so first of
> all I am learning the C programming language and the linux working for it.
> if anyhting else is required please instruct me about that in the software
> arena.that will be really good as you guys are genius.

<big frown>  I think that you really need to understand how
these hardware features are being used (as dictated by the
OS-BSP interface) before you can truly begin to effectively
implement them.

For a silly example, imagine you have a digital output bit
on your MCU.  No doubt, you could write a bit of code
that would export an interface that lets me set it HI
or LO through some function interface (e.g., setbit(level)).

Simple.

But, what if the software riding above this wants to use that
bit to implement an SPI *clock*?  Or, the TxD signal for
a "software UART"?  Clearly, there may be different approaches
to different potential *uses* for this facility.

E.g., what if you were commanded to change the baudrate of
a UART.  What if the UART was in the process of transmitting
a datum?  How would you protect any data being *recevied*
at this time??

Or, imagine being commanded to change the CLUT for a video
driver.  Have you considered whether this should be done
asynchronously?  Or, should it synchronize with retrace
to avoid visual artifacts??

You don't really know how you *should* approach each task
without knowing what the upper layer actually expects from it.

>> Simple, eh?  :>
>
> yeah until I start doing it.
>
>>> Actually I want to practice it and want to test it on the virtual
> emulator
>>> like Qemu and than I will port it to my new hardware.
>>
>> Huh?  Qemu sits *above* the hardware.  I don't see what you
>> are trying to achieve with this approach.  I would imagine
>> you want to run the BSP on the *actual* hardware and verify
>> that you can talk to it in much the same ways that the Linux
>> kernel will.  I.e., your first hurdle is being able to
>> get code running on bare iron (do you know how to link
>> for specific hardware addresses?  what tools do you have to
>> inject the firmware into that hardware?  what tools do you have
>> for interacting with it to verify its proper operation?  etc.)
>
> I have not decided that yet and thought that first get the idea about the
> BSP development and and get started with that than move to porting hardware
> in between the development phase.
>
> if that's a problem than can you please describe me that what hurdle I am
> going to face if I didn't decided that how and which tools I am going to
> use.

If I was in your situation, I would harvest as many *similar*
(to your target) BSPs and just skim them to see what sorts
of facilities they provide and any common approaches that
seem to be in evidence.  I.e., does the OS-BSP interface
predicate a particular approach (that would be evident in
all such implementations -- regardless of vendor)?

Then, pick a *simple* device to implement (UART is always
a favorite for me as it is pretty trivial to implement,
in terms of the hardware, so you can spend more time
focused on the *software*/system side of the problem.

Then, figure out how you are going to use your available
*tools* to write and DEPLOY code in that hardware environment.

You can then write tiny/trivial routines to test your
bare driver.  E.g., something that prints a list of
sequential numbers (to test serialOUT()); something that
echoes incoming characters (to test serialIN()); etc.

 From there, step up to more sophisticated devices,
virtual devices, etc.

>> If time is cheaper than money, you might just start looking
>> for BSP's with a goal of trying to accrete enough from them
>> in toto to get a complete idea of what is required.
>>
>> Of course, these will tend to only address the "common" bits
>> of I/O and processor core that you are likely to encounter.
>> If you've got anything "esoteric" onboard, you're on your
>> own for those aspects!
>
> I didn't get this one :( :(

Imagine if your hardware has the ability to drive a *motor*.
I.e., that's not something you are likely to find in a "generic"
OS BSP!  You might have to conceptualize your own interface
(driver) to that "device" -- based on how you *expect* to use
it (and access it, from above).

On 2012-05-13 16:20, piyushpandey wrote:
> Hello TO all
>
> guys I want to know that how to make a BSP ( Board support Packages ) for a
> new hardware using Linux kernel.
>
> I mean is there any tutorial in regard with this topic.
>

Check out
www.openembedded.org	- more useful
or
www.buildroot.net	- easier

BR
Ulf Samuelsson



> Also what are the basic requirements in order to move in this direction.
>
>
> Actually I want to practice it and want to test it on the virtual emulator
> like Qemu and than I will port it to my new hardware.
>
>
>
> Thanks.
>
> Piyush Pandey	
> 					
> ---------------------------------------		
> Posted through http://www.EmbeddedRelated.com

>On 2012-05-13 16:20, piyushpandey wrote:
>> Hello TO all
>>
>> guys I want to know that how to make a BSP ( Board support Packages )
for a
>> new hardware using Linux kernel.
>>
>> I mean is there any tutorial in regard with this topic.
>>
>
>Check out
>www.openembedded.org	- more useful
>or
>www.buildroot.net	- easier
>
>BR
>Ulf Samuelsson
>
>
>
>> Also what are the basic requirements in order to move in this
direction.
>>
>>
>> Actually I want to practice it and want to test it on the virtual
emulator
>> like Qemu and than I will port it to my new hardware.
>>
>>
>>
>> Thanks.
>>
>> Piyush Pandey	
>> 					
>> ---------------------------------------		
>> Posted through http://www.EmbeddedRelated.com
>
>


thanks ulf for providing these beautiful links.

	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

>On 5/14/2012 8:49 AM, piyushpandey wrote:
>>> I would imagine the best approach would be to grab as many
>>> BSP's that you can find *especially* if you have access to
>>> the schematics (or some equally detailed hardware description)
>>> so you can see how the BSP hooks map to the actual hardware
>>> being used.
>>
>> yes I think you are right don , the best way to learn that how I can
>> understand to create the BSP is to have a look on the other companies
>> sources and packages.
>>
>> So do you have any idea of such websites or anything else where I can
get
>> the sources as you told.
>
>I don't have specific pointers.  Use your favorite search
>engine to find "Linux BSP" or "<whateverOS> BSP".  You
>might find offerings from *board* vendors (which may or may
>not require you to be a current customer, etc.)
>
>>> There are organizations that do this sort of thing as their
>>> core business.  And, many do it to *support* their core
>>> business (i.e., SoC vendors).
>>
>> also don I want to know as the companies provide the technical
refrences
>> about there microcontroller and how to use those controllers in the
>> projects, similarly do the companies developing the bsp provide
refrences
>> about how to develop the BSP, if yes can you suggest me few of those
>> companies.
>
>Companies who provide BSPs most usually provide them for
>*their* product offerings -- whether those are MCU's,
>SoC's, SBC's, or whatever.
>
>There are firms that offer a *service* to develop a BSP
>FOR YOU.  But, that comes at a cost  :>
>
>>>> Also what are the basic requirements in order to move in this
>> direction.
>>>
>>> #1 is a good understanding of the *hardware*.
>>
>> yes I agree don and I must tell you that I am a hardware engineer and
have
>> designed many boards but all containing the 8 and 16 bit
microcontrollers
>> like AVR, PIC and also controllers from the ST etc.
>>
>> but this time I designed the hardware focussing the 32 bit ARM
processor
>> from the ATMEGA AT91SAM microcontroller.
>>
>> So as far as I know this is the forum which deals in the software part
>> mostly and not in the hardware and therefore I didn't disclosed
anything
>> about my hardware.
>
>My point is that you need to understand how the hardware can be
>"told" to provide the service/functionality that the software
>(driver, BSP, etc.) *requires*.
>
>I.e., if you have a serial port, you need to understand how
>to interface to the hardware for that serial port; how to
>reconfigure it "on demand"; how to query its status; how to
>ensure it doesn't "lock up"; etc.  All of these requirements
>are dictated FROM ABOVE by the requirements of the system
>under which you are implementing the driver/BSP.
>
>>> #2 is a good understanding of software!
>>
>> yeah this is the area where I am trying to make my self strong so first
of
>> all I am learning the C programming language and the linux working for
it.
>> if anyhting else is required please instruct me about that in the
software
>> arena.that will be really good as you guys are genius.
>
><big frown>  I think that you really need to understand how
>these hardware features are being used (as dictated by the
>OS-BSP interface) before you can truly begin to effectively
>implement them.
>
>For a silly example, imagine you have a digital output bit
>on your MCU.  No doubt, you could write a bit of code
>that would export an interface that lets me set it HI
>or LO through some function interface (e.g., setbit(level)).
>
>Simple.
>
>But, what if the software riding above this wants to use that
>bit to implement an SPI *clock*?  Or, the TxD signal for
>a "software UART"?  Clearly, there may be different approaches
>to different potential *uses* for this facility.
>
>E.g., what if you were commanded to change the baudrate of
>a UART.  What if the UART was in the process of transmitting
>a datum?  How would you protect any data being *recevied*
>at this time??
>
>Or, imagine being commanded to change the CLUT for a video
>driver.  Have you considered whether this should be done
>asynchronously?  Or, should it synchronize with retrace
>to avoid visual artifacts??
>
>You don't really know how you *should* approach each task
>without knowing what the upper layer actually expects from it.
>
>>> Simple, eh?  :>
>>
>> yeah until I start doing it.
>>
>>>> Actually I want to practice it and want to test it on the virtual
>> emulator
>>>> like Qemu and than I will port it to my new hardware.
>>>
>>> Huh?  Qemu sits *above* the hardware.  I don't see what you
>>> are trying to achieve with this approach.  I would imagine
>>> you want to run the BSP on the *actual* hardware and verify
>>> that you can talk to it in much the same ways that the Linux
>>> kernel will.  I.e., your first hurdle is being able to
>>> get code running on bare iron (do you know how to link
>>> for specific hardware addresses?  what tools do you have to
>>> inject the firmware into that hardware?  what tools do you have
>>> for interacting with it to verify its proper operation?  etc.)
>>
>> I have not decided that yet and thought that first get the idea about
the
>> BSP development and and get started with that than move to porting
hardware
>> in between the development phase.
>>
>> if that's a problem than can you please describe me that what hurdle I
am
>> going to face if I didn't decided that how and which tools I am going
to
>> use.
>
>If I was in your situation, I would harvest as many *similar*
>(to your target) BSPs and just skim them to see what sorts
>of facilities they provide and any common approaches that
>seem to be in evidence.  I.e., does the OS-BSP interface
>predicate a particular approach (that would be evident in
>all such implementations -- regardless of vendor)?
>
>Then, pick a *simple* device to implement (UART is always
>a favorite for me as it is pretty trivial to implement,
>in terms of the hardware, so you can spend more time
>focused on the *software*/system side of the problem.
>
>Then, figure out how you are going to use your available
>*tools* to write and DEPLOY code in that hardware environment.
>
>You can then write tiny/trivial routines to test your
>bare driver.  E.g., something that prints a list of
>sequential numbers (to test serialOUT()); something that
>echoes incoming characters (to test serialIN()); etc.
>
> From there, step up to more sophisticated devices,
>virtual devices, etc.
>
>>> If time is cheaper than money, you might just start looking
>>> for BSP's with a goal of trying to accrete enough from them
>>> in toto to get a complete idea of what is required.
>>>
>>> Of course, these will tend to only address the "common" bits
>>> of I/O and processor core that you are likely to encounter.
>>> If you've got anything "esoteric" onboard, you're on your
>>> own for those aspects!
>>
>> I didn't get this one :( :(
>
>Imagine if your hardware has the ability to drive a *motor*.
>I.e., that's not something you are likely to find in a "generic"
>OS BSP!  You might have to conceptualize your own interface
>(driver) to that "device" -- based on how you *expect* to use
>it (and access it, from above).
>



Hello Don

I have sent you a personal message do you get that or not.

Please reply to my that message.



Thank you	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com