BareMetal-OS real-time embedded

[Fred Eckert]

Hello,

I am currently evaluating BareMetal's suitability as an OS for a real-time embedded system. With the way this particular system's real-time control algorithms are coded, it is critical that the control computer's timing be absolutely stable and any latencies be sub-microsecond.

Due to it's mono-tasking design, it seems that BareMetal may be suitable. Has anyone performed any stability/latency testing with the OS?

I am going to code up a simple program to toggle an output bit and generate a 100kHz square wave as follows:

WHILE

    OUT &H300, &HFF

    FOR X = 1 TO 10000
    OUT &H300, &H00
    FOR X = 1 TO 10000
WEND

I am curious to see if the new networking implementation will steal CPU cycles when packets come in on the wire. If this is the case, can the networking and any other background ISRs be masked on and off? Will this masking on and off kill the TCP/IP stack or will it come back to life?

Thanks,

FredE

[Ian Seyler]

Hi Fred,

BareMetal uses the computers built-in RealTime Clock for timing. The RTC is configured to trigger an interrupt 8 times per seconds (8Hz). Not ideal for your use but it can be reconfigured. The RTC supports the following rates:

  RS    Int/sec         Period
 3210      -              -
 0000   none            none
 0001    256            3.90625 ms
 0010    128            7.8125  ms
 0011   8192            122.070 Micros
 0100   4096            244.141 Micros
 0101   2048            488.281 Micros
 0110   1024            976.562 Micros
 0111    512            1.93125 ms
 1000    256            3.90625 ms
 1001    128            7.8125  ms
 1010     64            15.625  ms
 1011     32            31.25   ms
 1100     16            62.50   ms
 1101      8            125.0   ms
 1110      4            250.0   ms
 1111      2            500.0   ms

If more precision is required then we would need to look at using HPET (High Precision Event Timers).

With modern CPU's I can't see the network interrupt stealing that many cycles... however they can be disabled if required. In fact if it was an issue we could enable/disable system interrupts whenever necessary.

Your project sounds interesting and I look forward to hearing more about your testing.

-Ian

[Fred Eckert]

Hi Ian,

I was able to do some testing today. I am working with a WinSystems EBC-C384-D2. I wrote the square wave test program in assembler and set the delays to produce a 40kHz waveform. Initial stability testing shows a big hit when the RTC interrupt fires. I am using MS-DOS 6.22 as my standard benchmark. BareMetal's RTC interrupt takes 5x longer than DOS's. This was not good. Taking heed of your comments below, I masked off the interrupts using the CLI instruction just before entering the main loop. Now BareMetal proves to be 2x more stable than DOS running the same code. Very interesting...

Will shutting off the interrupts for long periods (e.g. seconds, minutes, or even hours) lead to any problems for the OS?

Thanks,

Fred

[42Bastian]

Hi Fred

> I was able to do some testing today. I am working with a WinSystems

> EBC-C384-D2 <http://sbc.winsystems.com/products/EBC-C384-D.cfm>. I wrote

> the square wave test program in assembler and set the delays to produce a
> 40kHz waveform. Initial stability testing shows a big hit when the RTC

Are you really trying to do accurate timing without a HW timer ? This is
really strange and sound like the "good old times" when cycle-counting was
used to get (at that time) µs delays.

Cycle counting on a x86 will _not_ work!

But on a 1.8GHz CPU you should be able to run high speed interrupts with
only a few ns of jitter.

And if you use one core for the interrupt only, maybe without jitter.

Regarding BMOS, you might want to make sure, the keyboard interrupt does
not wakeup all core but only the one with the command-line.

> interrupt fires. I am using MS-DOS 6.22 as my standard benchmark.
> BareMetal's RTC interrupt takes 5x longer than DOS's. This was not good.

Longer in which regard ?

> Taking heed of your comments below, I masked off the interrupts using the
> CLI instruction just before entering the main loop. Now BareMetal proves to
> be 2x more stable than DOS running the same code. Very interesting...
>
> Will shutting off the interrupts for long periods (e.g. seconds, minutes,
> or even hours) lead to any problems for the OS?

=> no keyboard interrupts !

Just a side note: On a ARM7TDMI with 50MHz we could produce a 20kHz signal
w/o any jitter !

--
42Bastian

[Fred Eckert]

Hello Bastian,

On Sunday, March 18, 2012 2:10:01 AM UTC-4, 42Bastian wrote:

Hi Fred

Are you really trying to do accurate timing without a HW timer ? This is really strange and sound like the "good old times" when cycle-counting was used to get (at that time) µs delays.

No we plan to poll a hardware timer for expiration. We want to make sure that when the timer edge goes high, we are there to respond.

 

Cycle counting on a x86 will _not_ work!

Why do you say this? Is it because Intel keeps adding "features" to the architecture. Things like the SMI, Power Management, Legacy USB support? I can turn all these features off.

But on a 1.8GHz CPU you should be able to run high speed interrupts with
only a few ns of jitter.

And if you use one core for the interrupt only, maybe without jitter.

I hope to see this someday, then I can leave all the interrupts enabled, but, I have not seen it yet.

 

Regarding BMOS, you might want to make sure, the keyboard interrupt does
not wakeup all core but only the one with the command-line.

I need to understand the architecture better. I don't know how the interrupts are wired to the system. I don't understand how multi-core works. I am looking for a good ATOM and/or Multicore Intel architecture book... Maybe the Intel Press book "Break Away with Intel® Atom™ Processors"?? I think I will get a copy...

 

> interrupt fires. I am using MS-DOS 6.22 as my standard benchmark.
> BareMetal's RTC interrupt takes 5x longer than DOS's. This was not good.

Longer in which regard ?

Longer in regards to my measurement system. I have a second processor incrementing a variable as fast as it can when the waveform is low and another when it is high. I keep track of the average counts ant the max counts. The BareMetal max count is always approx 5x bigger than than the DOS max count when interrupts are enabled. And always approx 2x smaller than DOS when interrupts are disabled.

> Taking heed of your comments below, I masked off the interrupts using the
> CLI instruction just before entering the main loop. Now BareMetal proves to
> be 2x more stable than DOS running the same code. Very interesting...
>
> Will shutting off the interrupts for long periods (e.g. seconds, minutes,
> or even hours) lead to any problems for the OS?

=> no keyboard interrupts !

I was surprised to see that with the CLI instruction asserted, the keyboard interrupt still worked! In both BareMetal and in DOS. I could press Esc in BM and Ctrl-Alt-Del in DOS and the system rebooted. Maybe the keyboard is connected to a non-maskable interrupt in the atom??

 

Just a side note: On a ARM7TDMI with 50MHz we could produce a 20kHz signal
w/o any jitter !

Maybe the days of the PC based control system is over :-( ?

 

--
42Bastian

Fred

[42Bastian]

Hi Fred

>> Are you really trying to do accurate timing without a HW timer ? This
>> is really strange and sound like the "good old times" when cycle-counting
>> was used to get (at that time) µs delays.
>>
> No we plan to poll a hardware timer for expiration. We want to make sure
> that when the timer edge goes high, we are there to respond.

Why poll ? Why not setup an interrupt ? It is by far more accurate then
polling.

>> Cycle counting on a x86 will _not_ work!
>>
>> Why do you say this? Is it because Intel keeps adding "features" to the
> architecture. Things like the SMI, Power Management, Legacy USB support? I
> can turn all these features off.

It has nothing to do with the USB or SMI. Maybe with power management. But
for sure with the pipelines, out of order execution and the cache.

> But on a 1.8GHz CPU you should be able to run high speed interrupts with
>> only a few ns of jitter.
>>
>> And if you use one core for the interrupt only, maybe without jitter.
>>
>> I hope to see this someday, then I can leave all the interrupts enabled,
> but, I have not seen it yet.
>
>
>> Regarding BMOS, you might want to make sure, the keyboard interrupt does
>> not wakeup all core but only the one with the command-line.
>>
>
> I need to understand the architecture better. I don't know how the
> interrupts are wired to the system. I don't understand how multi-core
> works. I am looking for a good ATOM and/or Multicore Intel architecture
> book... Maybe the Intel Press book "Break Away with Intel® Atom™ Processors"??
> I think I will get a copy...

If I understand the code correctly (Ian please correct me) from init_64.s
mov rcx, 8 ; Enable RTC
mov rax, 0x0100000000000928 ; Lowest priority
; mov rax, 0x28 ; Handled by APIC ID 0 (BSP)

the RTC interrupt is send to the CPU with the lowest cpu.

Try removing the comment, then let your "toggle-code" run on AP.
This should give you the best values you can get even with interrupts
enabled, since the interrupts are handled by the BSP.

>>> interrupt fires. I am using MS-DOS 6.22 as my standard benchmark.
>>> BareMetal's RTC interrupt takes 5x longer than DOS's. This was not good.
>>
>> Longer in which regard ?
>>
> Longer in regards to my measurement system. I have a second processor
> incrementing a variable as fast as it can when the waveform is low and
> another when it is high. I keep track of the average counts ant the max
> counts. The BareMetal max count is always approx 5x bigger than than the
> DOS max count when interrupts are enabled. And always approx 2x smaller
> than DOS when interrupts are disabled.

Excuse me, but this sounds strange and not correct way to measure such thing.

If you want an accurate wave-form (which is you max. frequency?) a simple
PIC can achieve such. No need for the big iron.

Todays micro-controller (nearly) all come with HW timers and PWM output.

Anyway, if you want to use the big iron, I strongly suggest to use interrupts.

> I was surprised to see that with the CLI instruction asserted, the keyboard
> interrupt still worked!

Do you use CLI in your program ? If it runs on the AP, it is clear. You
are disabling interrupts only on one core. KBD is already directed to the
BSP, and RTC will because on the AP interrupts are disabled.

In both BareMetal and in DOS. I could press Esc in
> BM and Ctrl-Alt-Del in DOS and the system rebooted. Maybe the keyboard is
> connected to a non-maskable interrupt in the atom??

Don't know about DOS. Does it handle multiple cores ?

>> Just a side note: On a ARM7TDMI with 50MHz we could produce a 20kHz signal
>> w/o any jitter !
>>
>> Maybe the days of the PC based control system is over :-( ?

For sure when it comes to such simple jobs. It is always the question how
much work needs to be done in the Core (heavy floating point math) and how
much on the peripherals (toggle I/Os, serial, ethernet).
For example, a PowerPC MPC5121@400MHz can handle TCP/IP on a 100MB
Ethernet as quick as an Core2 D...@2.4GHz. => No benefit to use the more
power consuming Core2 Duo.

Just a note: The 1.8GHz are not good for comparing. You need to know the
bus speed.
Just check how fast you can toggle an I/O pin on a x86 and compare it with
any uC around.

Just my 2cents
--
42Bastian

[Ian Seyler]

That makes sense the the RTC interrupt takes longer than DOS. Just out of curiosity can your try re-enabling the RTC interrupt but commenting out the following 4 lines in the RTC section of interrupt.asm?

	cmp byte [os_show_sysstatus], 0
	je rtc_no_sysstatus
	call system_status		; Show System Status information on screen
rtc_no_sysstatus:

system_status is the function that displays the cpu, memory, network info at the top of the screen and the code for it isn't the best I've ever done.

There is no problem with disabling the RTC interrupt permanently but I would try commenting out the lines I mentioned first. The RTC interrupt does restart the CLI after a program finishes its execution.

I am also working on a HPET driver for BareMetal OS.

-Ian

[frede...@gmail.com]

Oh yeah big improvement. I can't even see the RTC fire anymore. Now BareMetal is 2x more stable than DOS out of the box!

I seem to have an issue with my build of the OS though... I checked out ReturnInfinity-BareMetal-OS-637a3bb.zip, built with modified interrupt.asm, compiled using nasm kernel64.asm -o kernel64.sys. The problem is: When I run the program, it starts execution and keeps running but the command prompt immediately returns with the following message (spacing is messed up as shown below):

Co mm an d o r p r o g r a m n o t f o u n d d
> >

The square wave continues to run "in the background" as I type and execute commands in the BMOS CLI. Just garbage comes back: Stuff like:

AT16 > > dir
Command or program nCootm mfo u n d or program not found
>>
>
>

typing and running commands affects the timing of the wave...

I built using Debian 6.0 using the packaged NASM version 2.08.01 compiled on June 2 2010.

Any ideas why my build is so messed up?

Thanks,
Fred

[42Bastian]

Hi

> typing and running commands affects the timing of the wave...

The keyboard interrupt sends an interrupt to all cores.

Try replacing

call os_smp_wakeup_all ; A terrible hack
by
mov al, 0
call os_smp_wakeup

to wakeup only the BSP in interrupt.asm .

--
42Bastian

[Fred Eckert]

On Monday, March 19, 2012 3:40:31 AM UTC-4, 42Bastian wrote:

Hi Fred

>> Are you really trying to do accurate timing without a HW timer ? This
>> is really strange and sound like the "good old times" when cycle-counting
>> was used to get (at that time) µs delays.
>>
> No we plan to poll a hardware timer for expiration. We want to make sure
> that when the timer edge goes high, we are there to respond.

Why poll ? Why not setup an interrupt ? It is by far more accurate then
polling.

We are polling because we are trying to get rid of all the latencies. Intel has a whitepaper Microcontroller to Intel® Architecture Conversion Programmable Logic Controller (PLC) Using Intel® Atom™ Processor. It shows on page 19 a best worst case latency of 3.56 uS using CentOS with kernel 2.6.18. Embedded Menlow platform with 1.6GHz CPU. We would like to be sub-microsecond worst case (Maybe this latency is because of the linux OS?).

 

>> Cycle counting on a x86 will _not_ work!
>>
>> Why do you say this? Is it because Intel keeps adding "features" to the
> architecture. Things like the SMI, Power Management, Legacy USB support? I
> can turn all these features off.

It has nothing to do with the USB or SMI. Maybe with power management. But
for sure with the pipelines, out of order execution and the cache.

OK I understand. I saw an online presentation last year on how you really can't know what is going on in the processor anymore. All this branch prediction etc, leads to very unpredictable time of execution.

 

> But on a 1.8GHz CPU you should be able to run high speed interrupts with
>> only a few ns of jitter.
>>
>> And if you use one core for the interrupt only, maybe without jitter.
>>
>> I hope to see this someday, then I can leave all the interrupts enabled,
> but, I have not seen it yet.
>  
>
>> Regarding BMOS, you might want to make sure, the keyboard interrupt does
>> not wakeup all core but only the one with the command-line.
>>
>
> I need to understand the architecture better. I don't know how the
> interrupts are wired to the system. I don't understand how multi-core
> works. I am looking for a good ATOM and/or Multicore Intel architecture
> book... Maybe the Intel Press book "Break Away with Intel® Atom™ Processors"??
> I think I will get a copy...

If I understand the code correctly (Ian please correct me) from init_64.s
        mov rcx, 8                        ; Enable RTC
        mov rax, 0x0100000000000928        ; Lowest priority
;        mov rax, 0x28                        ; Handled by APIC ID 0 (BSP)

the RTC interrupt is send to the CPU with the lowest cpu.

Try removing the comment, then let your "toggle-code" run on AP.
This should give you the best values you can get even with interrupts
enabled, since the interrupts are handled by the BSP.

Did not try this.

 

>>> interrupt fires. I am using MS-DOS 6.22 as my standard benchmark.
>>> BareMetal's RTC interrupt takes 5x longer than DOS's. This was not good.
>>
>> Longer in which regard ?
>>
> Longer in regards to my measurement system. I have a second processor
> incrementing a variable as fast as it can when the waveform is low and
> another when it is high. I keep track of the average counts ant the max
> counts. The BareMetal max count is always approx 5x bigger than than the
> DOS max count when interrupts are enabled. And always approx 2x smaller
> than DOS when interrupts are disabled.

Excuse me, but this sounds strange and not correct way to measure such thing.

If you want an accurate wave-form (which is you max. frequency?) a simple
PIC can achieve such. No need for the big iron.

Todays micro-controller (nearly) all come with HW timers and PWM output.

Anyway, if you want to use the big iron, I strongly suggest to use interrupts.

Yes we want to use the most powerful processor available for our system. We like to use the extra horsepower to make our job as programmers easy. Maybe I need to learn more about using interrupts. If we could assign certain interrupts to certain cores, this could be an advantage.

 

> I was surprised to see that with the CLI instruction asserted, the keyboard
> interrupt still worked!

Do you use CLI in your program ? If it runs on the AP, it is clear. You
are disabling interrupts only on one core. KBD is already directed to the
BSP, and RTC will because on the AP interrupts are disabled.

I don't understand this yet. What is the AP and the BSP? I see Intel has a MultiProcessor Specification that explains these terms. I will need to read it.

 

 In both BareMetal and in DOS. I could press Esc in
> BM and Ctrl-Alt-Del in DOS and the system rebooted. Maybe the keyboard is
> connected to a non-maskable interrupt in the atom??

Don't know about DOS. Does it handle multiple cores ?

I don't think so. DOS development finished in 1994. Intel Multi-core came out around 2005.

 

>> Just a side note: On a ARM7TDMI with 50MHz we could produce a 20kHz signal
>> w/o any jitter !
>>
>> Maybe the days of the PC based control system is over :-( ?

For sure when it comes to such simple jobs. It is always the question how
much work needs to be done in the Core (heavy floating point math) and how
much on the peripherals (toggle I/Os, serial, ethernet).
For example, a PowerPC MPC5121@400MHz can handle TCP/IP on a 100MB
Ethernet as quick as an Core2 D...@2.4GHz. => No benefit to use the more
power consuming Core2 Duo.

This test is just a simple job to evaluate BareMetal, it is not the real job. On the real job we like to perform the heavy floating point math in real-time fully using the powerful processor.

 

Just a note: The 1.8GHz are not good for comparing. You need to know the
bus speed.
Just check how fast you can toggle an I/O pin on a x86 and compare it with
any uC around.

Yes I have seen this. For example: I have seen that an FPGA can toggle an IO really,really fast but, try to add a processor core to the FPGA, perform floating point math in it and then manipulate the IO based upon the math results. Things slow down quite a bit. **This observation was made in early 2000 so maybe FPGA processor cores are better now.

 

Just my 2cents

Thank you for the 2cents. I need all the common sense I can get.

Fred

 

--
42Bastian

[Fred Eckert]

This did not do anything different than the original version. Waveform output still slowed down when commands were launched in the CLI. Never could actually get anything to launch after the first app. Seems like memory is getting trashed.

Fred

[42Bastian]

Hi

>> Why poll ? Why not setup an interrupt ? It is by far more accurate then
>> polling.
>>
> We are polling because we are trying to get rid of all the latencies. Intel
> has a whitepaper Microcontroller to
> Intel® Architecture Conversion Programmable Logic Controller (PLC) Using

> Intel® Atom™ Processor<http://download.intel.com/design/intarch/papers/323213.pdf>.

> It shows on page 19 a best worst case latency of 3.56 uS using CentOS with
> kernel 2.6.18. Embedded Menlow platform with 1.6GHz CPU. We would like to
> be sub-microsecond worst case (Maybe this latency is because of the linux
> OS?).

This is pretty sure related to Linux. Linux is and was never an RTOS and
does lock out interrupts for a quite long time in the kernel.
Check out, if you can get figures for QNX or VxWorks on x86.

Why? Because a 72MHz ARM CPU is already at 1us interrupt latency running
my companies RTOS!
A 400MHz-PowerPC is arround 500ns!

> OK I understand. I saw an online presentation last year on how you really
> can't know what is going on in the processor anymore. All this branch
> prediction etc, leads to very unpredictable time of execution.

Right.

>>>> Regarding BMOS, you might want to make sure, the keyboard interrupt does
>>>> not wakeup all core but only the one with the command-line.
>>>>
>>>
>>> I need to understand the architecture better. I don't know how the
>>> interrupts are wired to the system. I don't understand how multi-core
>>> works. I am looking for a good ATOM and/or Multicore Intel architecture
>>> book... Maybe the Intel Press book "Break Away with Intel® Atom™
>> Processors"??
>>> I think I will get a copy...

I suggest reading the (x2)APIC chapters in the
<http://www.intel.com/content/dam/doc/specification-update/64-architecture-x2apic-specification.pdf>
and in the 64-ia-32-architectures-software-developer-manual-325462.pdf

>> Do you use CLI in your program ? If it runs on the AP, it is clear. You
>> are disabling interrupts only on one core. KBD is already directed to the
>> BSP, and RTC will because on the AP interrupts are disabled.
>>
>> I don't understand this yet. What is the AP and the BSP? I see Intel has a
> MultiProcessor Specification that explains these terms. I will need to read
> it.

It took me a while to understand Intels naming: BSP - BootStrapProcessor,
AP - ApplicationProcessor.

>> Yes I have seen this. For example: I have seen that an FPGA can toggle an
> IO really,really fast but, try to add a processor core to the FPGA, perform
> floating point math in it and then manipulate the IO based upon the math
> results. Things slow down quite a bit. **This observation was made in early
> 2000 so maybe FPGA processor cores are better now.

I am not sure. Most Soft-Cores do not have floating point.

When it comes to FPU, there are very few real micro controllers.
Mostly they only have single precision floating point.

--
42Bastian

[Ian Seyler]

The command prompt should not appear until after the program has finished. Can you post your interrupt.asm file somewhere for testing?

-Ian 

On Monday, March 19, 2012 2:27:16 PM UTC-4, Fred Eckert wrote:

Oh yeah big improvement. I can't even see the RTC fire anymore. Now BareMetal is 2x more stable than DOS out of the box!

I seem to have an issue with my build of the OS though... I checked out ReturnInfinity-BareMetal-OS-637a3bb.zip, built with modified interrupt.asm, compiled using nasm kernel64.asm -o kernel64.sys. The problem is: When I run the program, it starts execution and keeps running but the command prompt immediately returns with the following message (spacing is messed up as shown below):

Co mm an d o r p r o g r a m n o t f o u n d d
> >

The square wave continues to run "in the background" as I type and execute commands in the BMOS CLI. Just garbage comes back: Stuff like:

AT16 > > dir
Command or program nCootm mfo u n d or program not found
>>
>
>

typing and running commands affects the timing of the wave...

I built using Debian 6.0 using the packaged NASM version 2.08.01 compiled on June 2 2010.

Any ideas why my build is so messed up?

Thanks,
Fred

On , Ian Seyler wrote:

[Fred Eckert]

I attach my interrupt.asm and my sqrwav2.asm test program for analysis.

I think I may have an incomplete OS checkout from the repository. I see this when building the test programs:

administrator@CMS-0186-Debian:~/ReturnInfinity-BareMetal-OS-637a3bb/programs$ nasm ping.asm -o ping.app
ping.asm:20: error: symbol `b_parse_ip_addr' undefined
ping.asm:33: error: symbol `b_icmp_send_request' undefined
administrator@CMS-0186-Debian:~/ReturnInfinity-BareMetal-OS-637a3bb/programs$ nasm ipconf.asm -o ipconf.app
ipconf.asm:15: error: symbol `b_get_ip_config' undefined
ipconf.asm:29: error: symbol `b_parse_ip_addr' undefined
ipconf.asm:39: error: symbol `b_parse_ip_addr' undefined
ipconf.asm:53: error: symbol `b_parse_ip_addr' undefined
ipconf.asm:61: error: symbol `b_set_ip_config' undefined
ipconf.asm:66: error: symbol `b_ip_addr_to_str' undefined
ipconf.asm:70: error: symbol `b_ip_addr_to_str' undefined
ipconf.asm:74: error: symbol `b_ip_addr_to_str' undefined
administrator@CMS-0186-Debian:~/ReturnInfinity-BareMetal-OS-637a3bb/programs$ nasm arp.asm -o arp.app
arp.asm:13: error: symbol `b_get_arp_table' undefined
arp.asm:21: error: symbol `b_ip_addr_to_str' undefined
arp.asm:24: error: symbol `b_mac_addr_to_str' undefined
administrator@CMS-0186-Debian:~/ReturnInfinity-BareMetal-OS-637a3bb/programs$ nasm arpreq.asm -o arpreq.app
arpreq.asm:20: error: symbol `b_parse_ip_addr' undefined
arpreq.asm:26: error: symbol `b_arp_request' undefined

Fred

[Ian Seyler]

This was an error on my part. The updated bmdev.asm file was not in Git. I have added it now and with it you should be able to compile the new IP apps.

I'll take a look at your program and see if I can duplicate it on my end.

-Ian

[Ian Seyler]

I was not able to duplicate the results of running your sqrwav2 program:

Execution continued until I hit Esc to reboot. What is attached to those IO ports?

-Ian

[Fred Eckert]

I wonder if it is because of my build environment or my test hardware... I will try a few different combinations to see if I can figure out what is going on. What Linux distro are you developing in? I see you are using QEMU. I am using VBOX.

There is nothing special attached to the ports just a PC104 digital IO board.

Fred

BTW: There is a small bug in my test program. The second out that forms the bottom of the square wave is using ax by accident. It should be using al.

[Fred Eckert]

I have another data point. The problem persists on the Advantech PCM-9562 with the Intel ATOM D510 processor. I am pretty confident the issue is my build environment. I just need to know what to use to get a solid build. Anybody?

Fred

On Wednesday, March 21, 2012 2:40:40 AM UTC-4, Fred Eckert wrote:

I wonder if it is because of my build environment or my test hardware... I will try a few different combinations to see if I can figure out what is going on. What Linux distro are you developing in? I see you are using QEMU. I am using VBOX.

There is nothing special attached to the ports just a PC104 digital IO board.

Fred

BTW: There is a small bug in my test program. The second out that forms the bottom of the square wave is using ax by accident. It should be using al.

[42Bastian]

Hi Fred

> build environment. I just need to know what to use to get a solid build.
> Anybody?

Maybe you should wind back to the releases of pure64 and bmos ?! Not the
GIT checkout.

--
42Bastian

[frede...@gmail.com]

A very good idea! Thank you. I will try this when I get some time.

[Ian Seyler]

Very odd. Can you post the compiled binaries of the kernel and your app? What Pure64 version are you using?

I would like to test what you have on my hardware.

-Ian

[Fred Eckert]

Hi Ian,

I attach my kernel64 and my sqrwav2 binaries. I had to rename the kernel to get it to upload.

I am using the 0.5.3 .vmdk version of Pure64.

Fred

[Ian Seyler]

I used your binaries in my VM and didn't see any issues. Are you noticing this bug on real hardware as well as VirtualBox?

-Ian

[Fred Eckert]

I only see this problem on real hardware.

Fred

[Ian Seyler]

Ok. I will test on real hardware as well.

-Ian

[Fred Eckert]

Ian,

It appears that two OS calls are still missing from the bmdev.asm:

ethdrv.asm:14: error: symbol `b_get_ethernet_driver' undefined

arpreq.asm:26: error: symbol `b_arp_request' undefined

Fred

[Ian Seyler]

Fixed in GIT. Thanks for letting me know.

Are you still having issues with your program? I haven't had a chance to test it here yet.

-Ian

[Fred Eckert]

Thank you for fixing this.

I am still having problems with running the program from the CLI. I trust that the issues will be resolved in time...

In the meantime, I have begun looking at networking support. I have acquired a WinSystems PPM-GIGABIT networking board which has the Intel 82541ER chipset. This card seems to be initialized the by OS. The MAC address displays upon boot and the LEDs on the card illuminate but, haven't been able to ping anything.

Is there a specific set of steps that must be performed to have the networking test programs work? I have tried both the built in IPCONFIG and the external IPCONF without success.

Fred

[Ian Seyler]

That chip should be supported. Were you able to run the ethtool program with success?

-Ian

[Fred Eckert]

To simplify testing I am just working within vbox using the intel 82540EM emulation. Out of 20+ reboots, I have seen only 1 time where I could transmit and receive with ethtool, At that time, ping worked in both directions. I can't seem to get a predictable result. I can see packets going out on the wire all the time but only sometimes do I see BareMetal-OS respond. When the problem is occurring, I see ARP requests going out but BareMetal doesn't seem to see them coming in.

Fred

[Ian Seyler]

In the VirtualBox VM config is the IO APIC enabled?

-Ian

[Fred Eckert]

Yes the IO APIC is enabled. I selected WinXP64 as the VM guest OS in the New Virtual Machine Wizard. I'm using vbox 4.1.10.

I can't seem to identify a pattern to the issue. it just seems to occasionally work for me about 1 out of every 10 tries.

I hope to get the real hardware back today and do some testing on real hardware.

Fred

[Ian Seyler]

I'll give this a try. I have the same version of VirtualBox installed.

[Fred Eckert]

Thanks for checking on this Ian...

We are pretty much in a holding pattern right now due to a lack of hardware. We have sent our ATOM based hardware back to the vendors for rework. It seems that there is a major decline in the I/O bandwidth achievable over the Intel LPC bus (PC104 ISA bus) that support ATOM processors.

We need both I/O bandwidth and I/O determinism. It seems that Intel is moving further and further away from the legacy deterministic I/O interfaces. Does anyone on the list know what is the "Intel high-bandwidth deterministic I/O interface of today"?

Thanks,

Fred