1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Building the Board Support Packages

Discussion in 'Embedded' started by piyushpandey, May 13, 2012.

  1. piyushpandey

    piyushpandey Guest

    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
     
    piyushpandey, May 13, 2012
    #1
    1. Advertising

  2. piyushpandey

    Tim Wescott Guest

    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
     
    Tim Wescott, May 13, 2012
    #2
    1. Advertising

  3. piyushpandey

    Don Y Guest

    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!
     
    Don Y, May 13, 2012
    #3
  4. piyushpandey

    piyushpandey Guest

    >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
     
    piyushpandey, May 14, 2012
    #4
  5. piyushpandey

    Don Y Guest

    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).
     
    Don Y, May 15, 2012
    #5
  6. 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
     
    Ulf Samuelsson, May 15, 2012
    #6
  7. piyushpandey

    piyushpandey Guest

    >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
     
    piyushpandey, May 15, 2012
    #7
  8. piyushpandey

    piyushpandey Guest

    >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
     
    piyushpandey, May 16, 2012
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Geoffrey Mortimer

    BGA packages in high vibration environments

    Geoffrey Mortimer, Oct 15, 2003, in forum: Embedded
    Replies:
    14
    Views:
    985
    rickman
    Nov 11, 2003
  2. Ralph Malph

    Speaking of small packages...

    Ralph Malph, Jan 20, 2004, in forum: Embedded
    Replies:
    0
    Views:
    269
    Ralph Malph
    Jan 20, 2004
  3. Ralph Malph

    Speaking of small packages...

    Ralph Malph, Jan 20, 2004, in forum: Embedded
    Replies:
    0
    Views:
    248
    Ralph Malph
    Jan 20, 2004
  4. Board Support Packages

    , Apr 27, 2006, in forum: Embedded
    Replies:
    2
    Views:
    311
  5. Replies:
    0
    Views:
    2,270
Loading...

Share This Page