Motherboard Forums


Reply
Thread Tools Display Modes

Building the Board Support Packages

 
 
piyushpandey
Guest
Posts: n/a
 
      05-13-2012, 02:20 PM
Hello TO all

guys I want to know that how to make a BSP ( Board support Packages ) for
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 emulato
like Qemu and than I will port it to my new hardware.



Thanks.

Piyush Pandey

---------------------------------------
Posted through http://www.EmbeddedRelated.com
 
Reply With Quote
 
 
 
 
Tim Wescott
Guest
Posts: n/a
 
      05-13-2012, 05:10 PM
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
 
Reply With Quote
 
 
 
 
Don Y
Guest
Posts: n/a
 
      05-13-2012, 07:53 PM
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!
 
Reply With Quote
 
piyushpandey
Guest
Posts: n/a
 
      05-14-2012, 03:49 PM
>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 ca
understand to create the BSP is to have a look on the other companie
sources and packages.

So do you have any idea of such websites or anything else where I can ge
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 refrence
about there microcontroller and how to use those controllers in th
projects, similarly do the companies developing the bsp provide refrence
about how to develop the BSP, if yes can you suggest me few of thos
companies.


>
>> Also what are the basic requirements in order to move in thi

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 hav
designed many boards but all containing the 8 and 16 bit microcontroller
like AVR, PIC and also controllers from the ST etc.

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

So as far as I know this is the forum which deals in the software par
mostly and not in the hardware and therefore I didn't disclosed anythin
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 o
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 softwar
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 virtua

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 th
BSP development and and get started with that than move to porting hardwar
in between the development phase.

if that's a problem than can you please describe me that what hurdle I a
going to face if I didn't decided that how and which tools I am going t
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
 
Reply With Quote
 
Don Y
Guest
Posts: n/a
 
      05-14-2012, 11:30 PM
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).
 
Reply With Quote
 
Ulf Samuelsson
Guest
Posts: n/a
 
      05-15-2012, 06:42 AM
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


 
Reply With Quote
 
piyushpandey
Guest
Posts: n/a
 
      05-15-2012, 04:16 PM
>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 thi

direction.
>>
>>
>> Actually I want to practice it and want to test it on the virtua

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
 
Reply With Quote
 
piyushpandey
Guest
Posts: n/a
 
      05-16-2012, 01:58 AM
>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 ca

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 technica

refrences
>> about there microcontroller and how to use those controllers in the
>> projects, similarly do the companies developing the bsp provid

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 an

have
>> designed many boards but all containing the 8 and 16 bi

microcontrollers
>> like AVR, PIC and also controllers from the ST etc.
>>
>> but this time I designed the hardware focussing the 32 bit AR

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 disclose

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 firs

of
>> all I am learning the C programming language and the linux working fo

it.
>> if anyhting else is required please instruct me about that in th

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
 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Search Engine Optimization Packages India, SEO Packages Hyderabad,SEO Packages Firm visioninfosyslinks@gmail.com Apple 0 03-05-2008 09:29 AM
Board Support Packages jayanthiveerabahu@gmail.com Embedded 2 04-28-2006 02:33 PM


All times are GMT. The time now is 12:34 PM.


Welcome!
Welcome to Motherboard Point
 

Advertisment