Building the Board Support Packages

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

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).

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

Simple, eh? :>

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!

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.

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.

direction.

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.

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.

:) :)

yeah until I start doing it.

emulator

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.

I didn't get this one :( :(

thanks for your reply

--------------------------------------- Posted through

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

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 :>

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.

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.

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.

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).

Check out

- more useful or - easier

BR Ulf Samuelsson

for a

direction.

emulator

thanks ulf for providing these beautiful links.

--------------------------------------- Posted through

get

refrences

refrences

have

microcontrollers

processor

anything

of

it.

software

the

hardware

am

to

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