Re: Understanding the BSP concept and terms

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

A cpu vendor can put anything they like on a cpu. Embedded cpus in
particular might have "extra" features that make them more embeddable. That
said, x86 architecture should be largely compatible.

So in your case it's quite likely that you'll be fine changing out cpus.
But in the general case (CE runs on a number of processors, not just X86)
this is not true. Changing the processor typically means a *lot* of
changes.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Garratt" <Christian.H.Mikkelsen@xxxxxxxxx> wrote in message
news:OB%23bm4HDHHA.3228@xxxxxxxxxxxxxxxxxxxxxxx
Thanks for the swift answer :)

Hmm we'll now its gets a little tricky :-). A little history first:

1. We bought a PCM6892 board with a x86 VIA CPU.
a. Got a BSP from VIA that supports the cpu and chipset etc.
Observation: the VIA BSP is based on the CEPC supplied by
microsoft with very few modifications.
b. This has been up and running smoothly for 1-2 years now :).

2. We bought the next revision of the board PCM6892 Rev. B, now with a
x86 Intel CPU,
but still with all the same chipset ect, the ethernet chip being
the only exception.
a. Tried using the VIA BSP with another ethernet driver and it
works.

So as you can see the BSP was not "intended" for our platform directly due
to the cpu change.
Im a little confused now as to one of my initial questions which I will
try to refrase now:

If I had two completely identical boards (all peripihals are the same)
and installed two different
x86 cpu's on each of the boards (in our case a VIA and an Intel) would
a cepc image not run on both without problems?
I thought that the x86 among other things describes the CPU "interface"
allowing in theory any x86 cpu to run the image as long as
the rest of the system is identical? Or is this where the OAL comes in
play?



Best regards
Christian

"Dean Ramsier" <ramsiernospam@xxxxxxxxxx> wrote in message
news:OKKSvymCHHA.468@xxxxxxxxxxxxxxxxxxxxxxx
You might not need any changes. My response was general case, in your
specific scenario it may be that the processors are software compatible.
It certainly appears they are close. One thing you could do is determine
any changes, and isolate them in your existing BSP. Allow the same BSP
to build a couple of different ways depending on the platform.

Otherwise, clone the existing BSP. No need to start from CEPC if you
already have working BSP intended for your platform.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Garratt" <Christian.H.Mikkelsen@xxxxxxxxx> wrote in message
news:OlpZr%23lCHHA.468@xxxxxxxxxxxxxxxxxxxxxxx
Thanks for the swift reply

Ok I follow you so far.
I did a minor test this afternoon and simply use the same nk.bin as
would run on
the old platform and voila it ran without any problems (that I have seen
so far) so I can conclude that the number of
differences between the two board might not be as major as one could
fear.
As I told you the platform are allmost identical expcet the two things
(processor and ethernet), so ive started
making my own BSP, now basing it on the CEPC (x86) that comes with PB
and re-using some of the drivers
from my old BSP (bootloader, graphics drivers for ex) and will start the
process of writing the srouce for the
Intel processor soon. This would be the right approach dont you agree?
Or should one try simply basing the new osdesign diretcly ontop of the
CEPC?

Best regards
Christain


"Dean Ramsier" <ramsiernospam@xxxxxxxxxx> wrote in message
news:uAmCDklCHHA.3476@xxxxxxxxxxxxxxxxxxxxxxx
1 - A BSP is all of the platform specific source code that is required
in order to create an operating system image using a particular hardware
platform. It is the contents of the \WINCExxx\PLATFORM\MyBSP directory.
If you receive a different hardware platform (which you did) then you
will probably need a new or updated BSP unless the hardware platform is
identical. Different processors, even in the same family often have
different peripherals requiring different source code to access them.
It isn't just the instruction set that needs to stay the same.

2 - I didn't quite follow this one. An image is an image, it is not a
BSP. A BSP is source code (or platform specific binaries such as
drivers) that can be compiled/linked together along with OS components
from PB that together make up the image. An SDK is a set of header
files that support the OS components present in your OS design and
associated image.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Garratt" <Christian.H.Mikkelsen@xxxxxxxxx> wrote in message
news:OIAv%23tjCHHA.3396@xxxxxxxxxxxxxxxxxxxxxxx
Hello

Until today I thought I understod the concept and workings of BSP's in
general, but then I talked to a co-worker the other day
who suddenly gave some doubt. I hold my co-worker and friend in high
regards so when he says otherwise I tend to question myself alot.
Anyway there a two things:

1.
About BSP's. Here's an example

Until recently we used a PCM6892 board with an x86 VIA
processor(400 mhz). A BSP is supplied from VIA which we installed
and used without any problems.

Now the PCM6892 board comes in a Rev. B that is completely
identical EXCEPT two things:
1.we've got a new processor a Intel Celeron (650Mhz)
2.there is a new ethernet unit RTL8100BL on the board which was
a RTL8139 on the old board.

Now I would claim that since both processors are x86, they use the
same instruction set and compiles with the same compiler from PB, so
we
should be able to use the same BSP.
I thought that a BSP only was concerned with bootloader and chipset
etc. and NOT tied directly to the processor. Correct me please if im
wrong.

My co-worker claims that is not the conincidense and that a BSP
actually tells ompiler(x86 in this case) specifics about processor
instruction set, so we
should not be able to use the same BSP on the new board.

Remember here we are only talking about processor dependencies since
the ONLY other difference between the board shift is the ethernet unit
and the processor. The rest of the board is the same when it comes to
chipset, memory etc, ONLY the processor differs together with the
ethernet unit.

So who is right and who is wrong?
Does anyone has a link that might clearify the excat concept of BSP's?

2.
About terms.

My friend calls a CE image (nk.bin) supplied with a SDK for a BSP.

I call a BSP for a BSP and an CE Image supplied with a SDK for a CE
Image with a SDK. I mean that you use the BSP(Board Support Package)
for developing a OS design which eventually ends up as a CE Image
which you then generate a SDK for. For some reason my friend calls the
final
product for a BSP as well.

What are the correct terminology?

Any info/links/etc on the matters at hand would be greatly appreciated
:-D.

Best regards
Christian















.

Relevant Pages

  • Re: Understanding the BSP concept and terms
    ... For example if our new Intel CPU supported had some knid of super duper AD ... x86 architecture should be largely compatible. ... Got a BSP from VIA that supports the cpu and chipset etc. ... So as you can see the BSP was not "intended" for our platform directly ...
    (microsoft.public.windowsce.embedded)
  • Re: Understanding the BSP concept and terms
    ... We bought a PCM6892 board with a x86 VIA CPU. ... Got a BSP from VIA that supports the cpu and chipset etc. ... So as you can see the BSP was not "intended" for our platform directly due ...
    (microsoft.public.windowsce.embedded)
  • Re: Does 32 bits value assignment needs locking operation
    ... there is demonstrated need for the optimization and the optimization ... breaks when snazzy new CPU Y comes out. ... is working on x86 32-bit platform as s simple sign. ...
    (comp.programming.threads)
  • BSP for S3C2440
    ... I am having a hard time to find a BSP for the SMDK2440 ... platform (Samsung S3C2440 CPU). ...
    (comp.os.linux.embedded)
  • [git pull] x86 updates for v2.6.28, phase #6, misc
    ... tip/x86/core: various x86 updates independent of the sparse irqs support ... separate generic cpu disabling code from APIC writes in cpu_disable ... convert hardware exception 0 to an interrupt gate ... +void printk_address ...
    (Linux-Kernel)