Community
cancel
Showing results for 
Search instead for 
Did you mean: 
DDono2
Novice
3,919 Views

Edison Quark microcontroller firmware choice question

I am wondering about the Quark microcontroller firmware, as I may not want to use proprietary Viper RTOS (as it's getting harder for me to really trust the proprietary software amid the recent hacking news of the particular exploitations).

I'd like to be able to use either Linux Zephyr kernel or even FreeRTOS. Providing it's compiled properly, would it be possible for me to use the open source firmware on the Quark microcontroller?

Or... Am I stuck with the proprietary software (as in it's checked by the bootloader)?

17 Replies
Andriy_S_Intel
Employee
124 Views

I'm also wondering about the same. The main issue anyway is to establish protocol how to upload firmware / application at run time in host OS (Linux). Second one is sensors and pin muxing and mappings for them.

However, if you are okay with the older kernel (as used for official BSP), the task might be much more simpler.

DDono2
Novice
124 Views

I tried to build official Edison BSP, my system crashed (I suspected memory leak in BIOS) so I am using the official firmware for now... Oh well.

I may retry this on one of my laptop if I attempt that again.

idata
Community Manager
124 Views

Hi Mario,

 

 

I would not say that it is not possible but we are not aware of any method to accomplish this. Perhaps you would like consider the other Quark options like the D2000, here you can see more documentation http://www.intel.com/content/www/us/en/embedded/products/quark/mcu/d2000/documentation.html http://www.intel.com/content/www/us/en/embedded/products/quark/mcu/d2000/documentation.html. Zephyr Kernel does support the Quark D2000 CRB, https://www.zephyrproject.org/doc/board/quark_d2000_crb.html https://www.zephyrproject.org/doc/board/quark_d2000_crb.html.

 

 

Regards,

 

-Pablo
DDono2
Novice
124 Views

Looks like I may have to bypass the on-die Quark microcontroller for a while as I don't trust proprietary blobs as it's hard to know if exploitation have been patched or not. I'd rather not risk it. Instead, I think I will have to rely on Python script to ensure nothing goes wrong while controlling the IO.

idata
Community Manager
124 Views

Hi Mario,

 

 

For now, given your concerns with the proprietary OS, I believe the Python approach would be a better idea.

 

Could you please elaborate a little bit more in the exploitation issue that you mention? I can investigate about that but I would like to have some more details.

 

 

Regards,

 

-Pablo
DDono2
Novice
124 Views

None as I know as of now, it's more of the "what-ifs" statements, especially in the date where there's some bad guys who would try to exploit the 486 CPU and do nasty thing like, for instance, pulling encryption keys from on the on-die Level-2 cache RAM shared by two Atom CPUs, and use it against the manufacturer's wills like selling the user data. Open-source firmware is a lot easier to patch, while closed-source software is not easy to patch (mainly because you won't know where to fix).

Recent exploitation in Qualcomm Snapdragon processors that made the news recently (quadrooter) is an excellent example, as was bootloader unlock trust issues in their Trustzone processors last year. That, and there are several reasons why I don't trust proprietary blobs. I'd rather rely on something I can trust and fix if needs arises.

For now, I will just use Python, until I can regain the use of 486-based microcontroller on the Atom CPU die via custom mcu_fw.bin image based on either FreeRTOS or Zephyr.

idata
Community Manager
124 Views

Hi Mario,

Thank you for your explanation. I understand your point, I remember reading some news about the Quadrooter situation and all Android-running devices being vulnerable (I believe this hasn't been patched yet).

 

In any case, given that you're already working on a different approach feel free to post your questions in the Community, we will be glad to help.

Regards,

 

-Pablo
DDono2
Novice
124 Views

I have figured out that Quark firmware is already based on Linux Zephyr RTOS, so I suppose it's okay in my book. Although I wish I can configure it (making my own Quark microcontroller firmware) for priority service for external IO, saving a bit of data (even though Atom is already out-of-order, even reservation station cache is still a precious commodity - about ~200 bytes basing off program slot entry size (operands are 64-bit in this processor and many recent AMD / Intel CPUs, so they're 8 bytes in operand size once running in Long Mode) although I am sure it's not as aggressive as the Core ix series, it's viewed as a modified Pentium II processor as far as I know - I'd be still cautious about abusing the RTOS priority and data cache when it comes to linear data streaming, while on other hand, Quark is a modified 80486 CPU which is essentially a single-issue in-order processor) for external resource streaming, such as vacuum fluorescent display / serial OLED screen framebuffer, and the likes.

Python is still an option if I can figure out the decent resource usage while using it for streaming data processing while Quark could be useful. So I am going to mark it as answered, unless you guys have something to add.

idata
Community Manager
124 Views

Hi Mario,

 

 

Yes, Viper kind of evolved into Zephyr RTOS, I should have mentioned that in the first place. Custom firmware, however, is not really supported for the Edison Quark.

 

Regarding your current approach, let us know if you find a way to better handle resources. That would be helpful information for other users.

 

 

Regards,

 

-Pablo
DDono2
Novice
124 Views

Will try to figure it out. BTW, is there any event timer, or dynamic programmable timers I can use for as a real-time tick timer so Linux kernel can handle the hard real-time thread (to be handled on a separate CPU core)? And how accurate are those timers?

idata
Community Manager
124 Views

Hi Mario,

 

 

Unfortunately, there are no programmable timers available on the MCU. This is stated in the Known limitations section from this link https://software.intel.com/en-us/node/545142 https://software.intel.com/en-us/node/545142.

 

 

Regards,

 

-Pablo
DDono2
Novice
124 Views

*shrugs* Looks like I will have to find a way to keep track of priorities the different way. Many full-blown x86 CPUs already have programmable timers for keeping track of program performance and OS kernel timing, so I thought I'd ask. Oh well. I may have to experiment to see what I can find usable (and soft timer basing off CPU cycle is useless here because of out-of-order execution in Atom CPUs, even though I like to have this CPU architecture for its performance advantage; it (the soft timer loops) either gets reordered or skipped).

Also, I checked, SysTick in Quark is about 10 ms which is usually enough as Atom spits out about 70 - 150 million instructions within this time space, providing Atom is running at 500 MHz speed. I'd imagine Linux kernel on Atom has similar SysTick triggering speed.

idata
Community Manager
124 Views

Hi Mario,

 

 

I could investigate this information if you want me to. The information about the SysTick triggering speed on Linux kernel I mean.

 

 

Regards,

 

-Pablo
DDono2
Novice
124 Views

That's okay, I found a way to read for SysTick as set in the official Edison Linux kernel, I will do so when I get to it.

EDITED: This is such instance which I would use on Edison to find out how fast it can go (in hertz - which I will convert to millisecond): http://www.advenage.com/topics/linux-timer-interrupt-frequency.php Topic: How To determine Linux Kernel Timer Interrupt Frequency - ADVENAGE

idata
Community Manager
124 Views

Hi Mario,

 

 

Thank you for the information. We would appreciate if you post your results in here once you've run your tests, it would be nice to have this information in the community.

 

 

Regards,

 

-Pablo
DDono2
Novice
124 Views

Tried this usual Linux kernel systick extraction command for a bit more details; "cat /boot/config-`uname -r` | grep HZ", it failed with dosfsck running around like it's nobody's business.

However, I copied the source code from the webpage I posted last two posts ago, and compiled it after copying it onto Edison via Filezilla, I got "3,999 Hz" which is kind of okay, in accordance with the 32,768 Hz tuning fork timer (it's actually not as precision as everyone would think - only MEMS 32 KHz oscillator is that accurate).

idata
Community Manager
124 Views

Hi Mario,

 

 

Thank you very much for sharing your results.

 

 

-Pablo
Reply