Date   

Re: Running on AMD systems

Geoffroy Van Cutsem
 

Hi Lonnie,

 

I would go first to the acrn-dev mailing list [1] if you have more detailed questions on how to port to AMD, the core developers are watching that one and much less this acrn-users mailing list. I do not know if they have specific knowledge on AMD-V but they would at least be able to guide through the ACRN architecture and content of the source code folders.

 

The numbers of VMs that can be run by ACRN is something that is defined in the ACRN configuration. It’s a pre-build configuration, not a runtime configuration, which means that any ACRN binary has a limit that’s potentially different. And to change that, you need to modify the configuration and rebuild ACRN. How many VMs would you like to concurrently run?

 

If you use one of our pre-defined configuration, the “industry” scenario is the one that can run the most VMs, 8 in total (but keep in mind that the Service VM is also a VM, so that’s 7 User VMs).

 

[1] https://lists.projectacrn.org/g/acrn-dev

 

Hope this helps!
Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Lonnie Cumberland
Sent: Thursday, January 14, 2021 7:01 PM
To: acrn-users@...
Subject: Re: [acrn-users] Running on AMD systems

 

Hi Geoffroy,

 

Thanks for getting back to me on this and I will see what I can do, but highly doubt that I have the skillset to make the patches for it to run on AMD. I will give it a try though.

 

There aren't by chance any developers that I might be able to contract to help get the AMD version running is there?  Like I mentioned, I will give it a try, but do not have much confidence in my possible success.

 

On another question, I was reading over the documentation and it seems that ACRN is limited to the number of VM's that it can concurrently run. Is that correct?   What I had come across has to do with Pre-Loaded VM limits which seems to suggest that a max of 7 was possible. Perhaps I missed something.

 

Best Regard as well,

Lonnie

 

 

On Thu, Jan 14, 2021 at 12:24 PM Geoffroy Van Cutsem <geoffroy.vancutsem@...> wrote:

Hi Lonnie,

 

Happy New Year to you too!! :-)

 

The short answer is that we have not tested ACRN on AMD processors. I strongly suspect that ACRN will not run on AMD at this stage due to the differences in the HW-assisted virtualization extensions (Intel VT vs. AMD-V). Having said that, please let us know if you get it to work! We’d also be happy to take patches if you create a port for AMD.

 

Best regards,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Lonnie Cumberland
Sent: Wednesday, January 13, 2021 9:09 PM
To: acrn-users@...
Subject: [acrn-users] Running on AMD systems

 

Hi All,

 

First of all, I would like to say Happy New Year to everyone.

 

Not sure if I have asked this, or if it has already come up, but I was wondering if ACRN will run on AMD processors.  Actually, I am looking for an extremely small footprint monolithic  hypervisor that can run on AMD and Intel processors as I investigate Uni-kernel approaches for JEOS streamlined applications.

 

Hoping that ACRN can be a good starting point for this effort that I have had in mind for a very long time now.

 

Best

Lonnie

 


A question on ACRN Design

Lonnie Cumberland <lonnie@...>
 

Greetings All,

Although I am still very new to ACRN and various development efforts, I often wondered about this question as it relates to ACRN and other Type-1 Hypervisors as well.

ACRN, like XEN, uses the approach of having a Dom0 for device drivers and main control services and has DomU for the user VM's

So then, here is what I am wondering.

Why is this design used when it seems to me that there should not be a single Dom0 for the drivers and such that if one crashes hard then there is the possibility that it can crash other critical drivers and code that is currently running?

Would it not be better to have each system driver in its own Dom0 that is running independently from the other drivers such that if a crash, or malicious attack, occurs then only that driver fails while the rest of the system is protected.  Full OS's do not have to be run in these driver Dom0 instances as I was thinking along the lines of Unikernels for each driver.

It seems like there could be many ways to set this up and it appears to be safer to me, but I have wondered why this approach has not been used?

Just a Noob learning here so please forgive me if there is something blatantly obvious that I just do not see.

Cheers,
Lonnie


Dynamically adding VM's

Lonnie Cumberland <lonnie@...>
 

Hi All,

I am beginning my exploration for ACRN as I think that it could offer what I need for my project which is based upon a nUltra-Litghtweight Hypervisor & Virtualizer like ACRN that will run a number of pre-loaded and dynamically loaded VM's which are composed of streamlined Unikernel applications all of which is run in RAM.

After searching for a VERY long time for possible candidates to use as a starting point with the strong criteria of:

1. Super small footprint
2. Able to run commodity guest OS's
3. Reliable and stable to semi-stable performance
4. Monolithic in design (as much as possible)
5. Would prefer it to run on Intel & AMD X86_64 based systems (others to follow)

I was able to narrow things down to:

A.) NOVA Hyervisor (Still Experimental and not mucd development, used in the Genode project)
B.) Xvisor
C.) ACRN Hypervisor

Both ACRN and Xvisor seem to be progressing and can offer many features but need development in some areas as well.

I like the very small footprint of ACRN and also that it is industrial grade for security which makes me want to use it as a starting point.

My goal is to do what I can to see if I can get it to run on AMD systems as well as the currently supported Intel systems and then give the patch back to the ACRN project.

I would also be interested to know if there is a scenario in which ACRN can dynamically load and start VM's as I did not read that in the scenario list.

Also, maybe finding a bare-metal GUI and adding it at a later time or perhaps in a VM as well.

Anyway, I look forward to seeing what I can learn and contribute to the ACRN project.

Cheers and have a great weekend,
Lonnie


Re: Running on AMD systems

Lonnie Cumberland <lonnie@...>
 

Hi Geoffroy,

Thanks for getting back to me on this and I will see what I can do, but highly doubt that I have the skillset to make the patches for it to run on AMD. I will give it a try though.

There aren't by chance any developers that I might be able to contract to help get the AMD version running is there?  Like I mentioned, I will give it a try, but do not have much confidence in my possible success.

On another question, I was reading over the documentation and it seems that ACRN is limited to the number of VM's that it can concurrently run. Is that correct?   What I had come across has to do with Pre-Loaded VM limits which seems to suggest that a max of 7 was possible. Perhaps I missed something.

Best Regard as well,
Lonnie


On Thu, Jan 14, 2021 at 12:24 PM Geoffroy Van Cutsem <geoffroy.vancutsem@...> wrote:

Hi Lonnie,

 

Happy New Year to you too!! :-)

 

The short answer is that we have not tested ACRN on AMD processors. I strongly suspect that ACRN will not run on AMD at this stage due to the differences in the HW-assisted virtualization extensions (Intel VT vs. AMD-V). Having said that, please let us know if you get it to work! We’d also be happy to take patches if you create a port for AMD.

 

Best regards,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Lonnie Cumberland
Sent: Wednesday, January 13, 2021 9:09 PM
To: acrn-users@...
Subject: [acrn-users] Running on AMD systems

 

Hi All,

 

First of all, I would like to say Happy New Year to everyone.

 

Not sure if I have asked this, or if it has already come up, but I was wondering if ACRN will run on AMD processors.  Actually, I am looking for an extremely small footprint monolithic  hypervisor that can run on AMD and Intel processors as I investigate Uni-kernel approaches for JEOS streamlined applications.

 

Hoping that ACRN can be a good starting point for this effort that I have had in mind for a very long time now.

 

Best

Lonnie

 


Re: Running on AMD systems

Geoffroy Van Cutsem
 

Hi Lonnie,

 

Happy New Year to you too!! :-)

 

The short answer is that we have not tested ACRN on AMD processors. I strongly suspect that ACRN will not run on AMD at this stage due to the differences in the HW-assisted virtualization extensions (Intel VT vs. AMD-V). Having said that, please let us know if you get it to work! We’d also be happy to take patches if you create a port for AMD.

 

Best regards,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Lonnie Cumberland
Sent: Wednesday, January 13, 2021 9:09 PM
To: acrn-users@...
Subject: [acrn-users] Running on AMD systems

 

Hi All,

 

First of all, I would like to say Happy New Year to everyone.

 

Not sure if I have asked this, or if it has already come up, but I was wondering if ACRN will run on AMD processors.  Actually, I am looking for an extremely small footprint monolithic  hypervisor that can run on AMD and Intel processors as I investigate Uni-kernel approaches for JEOS streamlined applications.

 

Hoping that ACRN can be a good starting point for this effort that I have had in mind for a very long time now.

 

Best

Lonnie

 


Running on AMD systems

Lonnie Cumberland <lonnie@...>
 

Hi All,

First of all, I would like to say Happy New Year to everyone.

Not sure if I have asked this, or if it has already come up, but I was wondering if ACRN will run on AMD processors.  Actually, I am looking for an extremely small footprint monolithic  hypervisor that can run on AMD and Intel processors as I investigate Uni-kernel approaches for JEOS streamlined applications.

Hoping that ACRN can be a good starting point for this effort that I have had in mind for a very long time now.

Best
Lonnie


Re: Failure to boot Industry scenario on UP2 Atom x7-E3950.

Andrew Back
 

Hi Fuzhong,

Apologies, it was my error.

When I tried what you suggested, upon rebooting, Grub said that I needed
to load the kernel first, which reminded me that I'd seen the note at
the beginning of the Getting Started Guide about using "grub-2.04-7
bootloader with the following patch", but then not done anything about
this. Although the guide does go on to cover O/S installation and Grub
configuration in detail, without ever again explaining that you need to
build and install this specific version.

After installing the linked Grub version and reverting to the previous
40_custom configuration, I rebooted and could load ACRN and the Ubuntu SOS.

I should now be in a position to configure the application, but have a
few questions:

- There seemed to be a long delay after the loading ACRN message, before
Linux started

Presumably at this point there is output to the UART on the Front Panel
USB header? I've ordered the parts to make up a cable with the
appropriate JST connector.

- Why are the default platform and SOS RAM sizes for apl-up2 set to 16GB?

As I mentioned before, I'm not aware of any such board.

- hypervisor/build/.config vs. build/hypervisor/.config

After configuring the first of the above files to reduce RAM sizes, is
it normal to find the 2nd file in the build directory with the default
values? Perhaps it copies this in, but the settings placed in
hypervisor/build/.config actually take precedence?

- Could some version of Grub later than 2.04-7 be used?

Presumably later versions will incorporate the patch, but I'm guessing
you've just validated one or a small number of versions. This would be
useful to know if using another distro which has a later version, means
that I don't need to build this specific version from source each time.

- UP2 BIOS "Real Time Option"

This is disabled by default and sounds potentially useful, but I
couldn't find out anywhere what this does in practice.

Thanks for your help, it's appreciated.

Best,

Andrew

On 30/12/2020 01:25, Liu, Fuzhong wrote:
Hi Andrew
Could you please try multiboot instead of multiboot2?
multiboot2 /boot/acrn/acrn.bin -----> multiboot --quirk-modules-after-kernel /boot/acrn/acrn.32.out
If the issue is still there, please help to raise git issue and upload serial port log of ACRN.

Thanks!

BR.
Fuzhong

-----Original Message-----
From: acrn-users@... <acrn-users@...> On Behalf Of Andrew Back
Sent: Monday, December 28, 2020 8:15 PM
To: acrn-users@...
Subject: [acrn-users] Failure to boot Industry scenario on UP2 Atom x7-E3950.

Hello,

Hardware is UP Squared P/N: UPS-APLX7-A20-0464 fitted with a 240GB mSATA drive.

Followed the getting started guide at:

https://projectacrn.github.io/latest/getting-started/rt_industry_ubuntu.html

Installing the UOS to the SATA drive and SOS to the 64GB eMMC. ACRN built with:

make all BOARD_FILE=misc/vm_configs/xmls/board-xmls/apl-up2.xml
SCENARIO_FILE=misc/vm_configs/xmls/config-xmls/apl-up2/industry.xml
RELEASE=0

Proceeded to build and install the kernel, and update Grub. Upon rebooting "loading ACRN..." is printed out and there is a pause for a few seconds, following which the system reboots. No other output at all.

I saw the note in the FAQ regarding memory and it looks as though the default configuration for both CONFIG_PLATFORM_RAM_SIZE and CONFIG_SOS_RAM_SIZE is 16GB, which seems odd, since AFAICT there is no
UP2 board available with more than 8GB fitted. In any case, I followed the instructions at:

https://projectacrn.github.io/latest/faq.html#how-do-i-configure-acrn-s-memory-size

Setting the aforementioned parameters both to 4GB and reducing CONFIG_UOS_RAM_SIZE to 1GB. Then rebuilt with 'make all RELEASE=0'
(specifying the XMLs this time resulted in error) and installed ACRN again. However, this didn't seem to make any difference. Though I saw after build that there was a .config file in build/hypervisor/ which had the default higher RAM values configured, instead of those which I'd set in hypervisor/build/.config. See the attached. Is the custom config somehow being ignored? Maybe this is not the main issue even if so...

My guess is that ACRN is not being loaded at all / the build is very broken, else I would expect this to at least print something out. Also wondered if using a serial console would help in debugging? Wasn't sure if this could provide greater insight into early boot failures.

Let me know if this looks like it may be an actual bug and I should log this on the issue tracker. At this point however I'm suspecting user error :o)

Regards,

Andrew

--
Andrew Back
http://abopen.com










--
Andrew Back
http://abopen.com


Re: Failure to boot Industry scenario on UP2 Atom x7-E3950.

Liu, Fuzhong
 

Hi Andrew
Could you please try multiboot instead of multiboot2?
multiboot2 /boot/acrn/acrn.bin -----> multiboot --quirk-modules-after-kernel /boot/acrn/acrn.32.out
If the issue is still there, please help to raise git issue and upload serial port log of ACRN.

Thanks!

BR.
Fuzhong

-----Original Message-----
From: acrn-users@... <acrn-users@...> On Behalf Of Andrew Back
Sent: Monday, December 28, 2020 8:15 PM
To: acrn-users@...
Subject: [acrn-users] Failure to boot Industry scenario on UP2 Atom x7-E3950.

Hello,

Hardware is UP Squared P/N: UPS-APLX7-A20-0464 fitted with a 240GB mSATA drive.

Followed the getting started guide at:

https://projectacrn.github.io/latest/getting-started/rt_industry_ubuntu.html

Installing the UOS to the SATA drive and SOS to the 64GB eMMC. ACRN built with:

make all BOARD_FILE=misc/vm_configs/xmls/board-xmls/apl-up2.xml
SCENARIO_FILE=misc/vm_configs/xmls/config-xmls/apl-up2/industry.xml
RELEASE=0

Proceeded to build and install the kernel, and update Grub. Upon rebooting "loading ACRN..." is printed out and there is a pause for a few seconds, following which the system reboots. No other output at all.

I saw the note in the FAQ regarding memory and it looks as though the default configuration for both CONFIG_PLATFORM_RAM_SIZE and CONFIG_SOS_RAM_SIZE is 16GB, which seems odd, since AFAICT there is no
UP2 board available with more than 8GB fitted. In any case, I followed the instructions at:

https://projectacrn.github.io/latest/faq.html#how-do-i-configure-acrn-s-memory-size

Setting the aforementioned parameters both to 4GB and reducing CONFIG_UOS_RAM_SIZE to 1GB. Then rebuilt with 'make all RELEASE=0'
(specifying the XMLs this time resulted in error) and installed ACRN again. However, this didn't seem to make any difference. Though I saw after build that there was a .config file in build/hypervisor/ which had the default higher RAM values configured, instead of those which I'd set in hypervisor/build/.config. See the attached. Is the custom config somehow being ignored? Maybe this is not the main issue even if so...

My guess is that ACRN is not being loaded at all / the build is very broken, else I would expect this to at least print something out. Also wondered if using a serial console would help in debugging? Wasn't sure if this could provide greater insight into early boot failures.

Let me know if this looks like it may be an actual bug and I should log this on the issue tracker. At this point however I'm suspecting user error :o)

Regards,

Andrew

--
Andrew Back
http://abopen.com


Failure to boot Industry scenario on UP2 Atom x7-E3950.

Andrew Back
 

Hello,

Hardware is UP Squared P/N: UPS-APLX7-A20-0464 fitted with a 240GB mSATA
drive.

Followed the getting started guide at:

https://projectacrn.github.io/latest/getting-started/rt_industry_ubuntu.html

Installing the UOS to the SATA drive and SOS to the 64GB eMMC. ACRN
built with:

make all BOARD_FILE=misc/vm_configs/xmls/board-xmls/apl-up2.xml
SCENARIO_FILE=misc/vm_configs/xmls/config-xmls/apl-up2/industry.xml
RELEASE=0

Proceeded to build and install the kernel, and update Grub. Upon
rebooting "loading ACRN..." is printed out and there is a pause for a
few seconds, following which the system reboots. No other output at all.

I saw the note in the FAQ regarding memory and it looks as though the
default configuration for both CONFIG_PLATFORM_RAM_SIZE and
CONFIG_SOS_RAM_SIZE is 16GB, which seems odd, since AFAICT there is no
UP2 board available with more than 8GB fitted. In any case, I followed
the instructions at:

https://projectacrn.github.io/latest/faq.html#how-do-i-configure-acrn-s-memory-size

Setting the aforementioned parameters both to 4GB and reducing
CONFIG_UOS_RAM_SIZE to 1GB. Then rebuilt with 'make all RELEASE=0'
(specifying the XMLs this time resulted in error) and installed ACRN
again. However, this didn't seem to make any difference. Though I saw
after build that there was a .config file in build/hypervisor/ which had
the default higher RAM values configured, instead of those which I'd set
in hypervisor/build/.config. See the attached. Is the custom config
somehow being ignored? Maybe this is not the main issue even if so...

My guess is that ACRN is not being loaded at all / the build is very
broken, else I would expect this to at least print something out. Also
wondered if using a serial console would help in debugging? Wasn't sure
if this could provide greater insight into early boot failures.

Let me know if this looks like it may be an actual bug and I should log
this on the issue tracker. At this point however I'm suspecting user
error :o)

Regards,

Andrew

--
Andrew Back
http://abopen.com


Canceled: 2020 ACRN Project Technical Community Meeting (2020/7~2020/12): @ Weekly Wednesday 4PM (China-Shanghai), Wednesday 9AM (Europe-London), Tuesday 0AM (US-West Coast),

Zou, Terry
 

Merry Christmas and Happy New Year to all !!!

 

Special Notes: If you have Zoom connection issue by using web browser, please install & launch Zoom application, manually input the meeting ID (320664063) to join the Zoom meeting.

 

Agenda & Archives:

WW

Topic

Presenter

Status

WW28

Inter-VM communication Introduction (DM land)

Liu, Yuan1

7/8/2020

WW30

PTM virtualization Introduction

Wang, Qian

7/22/2020

WW32

TSN pass through Introduction

Wu, Binbin

8/5/2020

WW34

Safety VM introduction

Mao Junjie

8/19/2020

WW36

TCC feature introduction-split lock

Li Fei/Tao Yuhong

9/2/2020

WW38

Inter-VM communication Introduction (DM land)

Liu, Yuan1

9/16/2020

 

Project ACRN: A flexible, light-weight, open source reference hypervisor for IoT devices

https://projectacrn.org  ||  https://github.com/projectacrn  ||  info@...

We're still in the early stages of forming this TSC, so instead we invite you to attend a weekly "Technical Community" meeting where we'll meet community members and talk about the ACRN project and plans. As we explore community interest and involvement opportunities, we'll (re)schedule these meetings at a time convenient to most attendees:

  • Meets every Wednesday, Starting Nov 07, 2018: 11AM-12AM (China-Shanghai), 7PM-8PM (US-West Coast), 3AM-4AM (Europe-London)
  • Chairperson: Hongbo Wang, hongbo.wang@... (Intel)
  • Online conference link: https://zoom.com.cn/j/320664063
  • Zoom Meeting ID: 320 664 063
  • Special Notes: If you have Zoom connection issue by using web browser, please launch Zoom application, manually input the meeting ID (320664063) to join the Zoom meeting.
  • Online conference phone:
    • China: +86 010 87833177  or 400 669 9381 (Toll Free)
    • Germany: +49 (0) 30 3080 6188  or +49 800 724 3138 (Toll Free)
    • US: +1 669 900 6833  or +1 646 558 8656   or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
    • Additional international phone numbers
  • Meeting Notes:

Or visit Github wiki if you can’t access Google doc: https://github.com/projectacrn/acrn-hypervisor/wiki/ACRN-Committee-and-Working-Group-Meetings#technical-community-meetings


Re: Intel Core i7 board options.

Andrew Back
 

On 18/12/2020 17:48, Geoffroy Van Cutsem wrote:
Hi! I agree with you. It has been a challenge to decide what and to what
level of granularity we describe what we validate, support and "Should
Work". Let me take that comment back to the engineering team, I'm not
too sure how to address it properly but I agree it's less than ideal at
the moment.

The second part of your comment is really the out of the box experience,
and there too it's not very straight-forward to install ACRN even on a
board that's known to work. We have some ideas on how to make that
easier, and with ACRN features maturing, this is climbing up the
priority ladder... so hopefully we'll have something better there in the
near future. If you have ideas yourself on how to make that easier,
please feel free to share them here... and if you have code/scripts to
help us, we'd also certainly welcome contributions in that area ;-)

Are you still having issues with your ACRN set-up by the way? If so,
please tell us more about these and we'll try to help you!
We've not made a start as yet and it will now likely be the new year
before we do. In addition to the Core i7 NUC, we'll also be evaluating
the UP2 Atom E3950, for use in a reduced performance configuration.

Thank you for the offer of help, it's much appreciated. I'll be in touch
should we run into any issues.

Best,

Andrew

--
Andrew Back
http://abopen.com


Re: Intel Core i7 board options.

Andrew Back
 

Hi Geoffroy,

Many thanks.

The DSP/PHY will be running as a Linux application, with an IP connection to another process running in the non-RT VM.

Are there embedded boards with processors that feature CAT support? And also which are presently supported by Acrn? Hopefully this won't be something we need, but would be good to know.

Any passthrough devices would be dedicated to a single VM, running a single transceiver process. Is there any tuning in particular for I/O? We can saturate USB 3.0 and need to make sure that this gives us the best performance possible, both in terms of throughput and latency.

Best,

Andrew

On 18/12/2020 16:52, Geoffroy Van Cutsem wrote:

Hi Andrew,

 

It sounds like the best starting point would be to use the classical industrial scenario for you. It allows you to start a Real-Time VM (RTVM) once ACRN and its Service VM is up and running. This is the Getting Started Guide for it: https://projectacrn.github.io/latest/getting-started/rt_industry_ubuntu.html

 

Are you running the DSP/PHY part of the stack under a Linux environment? If so, the tutorial above includes instructions on how to bring up a Linux environment and run a PREEMPT_RT kernel in it. That part would have to be adjusted if you need something different of course.

 

That NUC is based on a Kaby Lake processor, which does not support CAT (Cache Allocation Technology). This is something that could be useful if you are not getting the real-time performance you need when other apps are running in separate VMs. In any case, do not hesitate to reach out again if you face any issues and/or want some help with the performance tuning! We also have some notes that you may want to read on things to watch out for for real-time apps: https://projectacrn.github.io/latest/tutorials/rtvm_workload_design_guideline.html

 

Cheers,

Geoffroy

 

 

From: acrn-users@... <acrn-users@...> On Behalf Of Andrew Back
Sent: Friday, December 18, 2020 11:36 AM
To: acrn-users@...
Subject: Re: [acrn-users] Intel Core i7 board options.

 

Hi Geoffroy,

Decided to go with a NUC7i7DNBE board.

We don't need graphics virtualisation, but will need to pass through USB 3.0 and possibly PCIe devices.

The application is software-defined radio, where we will need to have a VM with real-time performance which is hosting the DSP/PHY part of the stack, plus a second non-RT VM which hosts other applications. Any pointers as to good starting points and best fit existing usage scenarios etc. would be much appreciated.

Cheers,

Andrew

-- 
Andrew Back
http://abopen.com


Re: Intel Core i7 board options.

Geoffroy Van Cutsem
 

Hi! I agree with you. It has been a challenge to decide what and to what level of granularity we describe what we validate, support and "Should Work". Let me take that comment back to the engineering team, I'm not too sure how to address it properly but I agree it's less than ideal at the moment.

The second part of your comment is really the out of the box experience, and there too it's not very straight-forward to install ACRN even on a board that's known to work. We have some ideas on how to make that easier, and with ACRN features maturing, this is climbing up the priority ladder... so hopefully we'll have something better there in the near future. If you have ideas yourself on how to make that easier, please feel free to share them here... and if you have code/scripts to help us, we'd also certainly welcome contributions in that area ;-)

Are you still having issues with your ACRN set-up by the way? If so, please tell us more about these and we'll try to help you!


Cheers!

Geoffroy


Re: Intel Core i7 board options.

Geoffroy Van Cutsem
 

Hi Andrew,

 

It sounds like the best starting point would be to use the classical industrial scenario for you. It allows you to start a Real-Time VM (RTVM) once ACRN and its Service VM is up and running. This is the Getting Started Guide for it: https://projectacrn.github.io/latest/getting-started/rt_industry_ubuntu.html

 

Are you running the DSP/PHY part of the stack under a Linux environment? If so, the tutorial above includes instructions on how to bring up a Linux environment and run a PREEMPT_RT kernel in it. That part would have to be adjusted if you need something different of course.

 

That NUC is based on a Kaby Lake processor, which does not support CAT (Cache Allocation Technology). This is something that could be useful if you are not getting the real-time performance you need when other apps are running in separate VMs. In any case, do not hesitate to reach out again if you face any issues and/or want some help with the performance tuning! We also have some notes that you may want to read on things to watch out for for real-time apps: https://projectacrn.github.io/latest/tutorials/rtvm_workload_design_guideline.html

 

Cheers,

Geoffroy

 

 

From: acrn-users@... <acrn-users@...> On Behalf Of Andrew Back
Sent: Friday, December 18, 2020 11:36 AM
To: acrn-users@...
Subject: Re: [acrn-users] Intel Core i7 board options.

 

Hi Geoffroy,

Decided to go with a NUC7i7DNBE board.

We don't need graphics virtualisation, but will need to pass through USB 3.0 and possibly PCIe devices.

The application is software-defined radio, where we will need to have a VM with real-time performance which is hosting the DSP/PHY part of the stack, plus a second non-RT VM which hosts other applications. Any pointers as to good starting points and best fit existing usage scenarios etc. would be much appreciated.

Cheers,

Andrew


Re: Intel Core i7 board options.

Andrew Back
 

Hi Geoffroy,

Decided to go with a NUC7i7DNBE board.

We don't need graphics virtualisation, but will need to pass through USB 3.0 and possibly PCIe devices.

The application is software-defined radio, where we will need to have a VM with real-time performance which is hosting the DSP/PHY part of the stack, plus a second non-RT VM which hosts other applications. Any pointers as to good starting points and best fit existing usage scenarios etc. would be much appreciated.

Cheers,

Andrew


Re: Intel Core i7 board options.

Geoffroy Van Cutsem
 

Hi Andrew,

 

I am not aware of a distributor in Europe. There are a couple of options I’m aware of:

 

I have never tried to order from Aliexpress but it says on the product page for example that they would ship to Belgium (where I’m located 😊), e.g.: https://www.aliexpress.com/store/5255223/search?origin=y&SearchText=whiskey

 

Regarding your question about validation, the short answer is that in most cases, it’s that we do not validate a particular combination. For some specific features, the obvious is that the underlying processor/platform needs to support it. A prime example of that would be Cache Allocation Technology (aka CAT), not all processor families support this. The one feature that seems to be causing the most trouble across CPU families is the graphics virtualization, i.e. GTV-g (for graphics sharing) and GVT-d (for graphics pass-through).

 

Now, the fact a combination of board/scenario is not validated today, does not mean we cannot add it. The project does not have unlimited resources but if there is enough interest for one, let’s talk about it!

 

Do you have a particular combination in mind already? Or more specific requirements you can share?

 

Cheers,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Andrew Back
Sent: Thursday, December 17, 2020 11:43 AM
To: acrn-users@...
Subject: Re: [acrn-users] Intel Core i7 board options.

 

Hi Terry,

Many thanks for the clarification.

Do you happen to know if there is a distributor in Europe for the WL-10 board? I cannot seem to find anywhere to buy this.

Regarding "supported", it's still not clear to me what this means. I appreciate that the level of granularity is scenario rather than feature, but I cannot ascertain whether lack of support for a particular board and scenario means "will not work" or "we have not validated". The distinction is quite important.

Best,

Andrew

On 17/12/2020 02:40, Zou, Terry wrote:

Hi Andrew, thanks very much for your interests of ACRN project. Yes ACRN is growing up very quickly, we enabled several HW platforms in: https://projectacrn.github.io/latest/reference/hardware.html

Started from Apollo Lake (NUC6CAYH/UP2) and Kaby Lake(NUC7i7BNH) with v1.0/…/6 releases for automotive usage, and enabled Whiskey Lake(WHL-IPC-I7) with v2.0/…/3 for Industrial scenario. Then started latest 11th Gen Intel® Core™ processors (codenamed Tiger Lake-UP3).  Actually we are also looking for mature/commercial TGL NUC or UP Xtreme(www.aaeon.com/) on market, but no available board and conclusion yet. So welcome any preference/suggestion from you and community : )

 

So for Industrial usage, Whiskey Lake and Maxtang WL-10 board is still preferred platform. If you do not have available Kaby Lake NUC7i7xxx, you may wait for sometime, when TGL NUC or UP Xtreme ready in market. We will also keep you updated and refresh Supported Hardware in ACRN project page.

 

For ‘supported’ platform, we did not break-down each feature on HW, but general separated user scenario, e.g., Apollo Lake/Kaby Lake only for SDC scenario, but Whiskey Lake for all scenarios: Safety VM, Logical Partition…

 

Best Regards

Terry

 

From: acrn-users@... <acrn-users@...> On Behalf Of Andrew Back
Sent: Wednesday, December 16, 2020 6:44 PM
To: acrn-users@...
Subject: [acrn-users] Intel Core i7 board options.

 

Hi All,

New to ACRN and wondering what the best options currently are for Intel Core i7 hardware? The documentation lists two NUC7i7xxx boards, but these are now a few years old. The v2.3 release notes mention 11th Gen Intel Core processors, but NUC models with these don't appear to be available yet and I am also not sure if going with the very latest hardware would be wise, considering that we want to focus our efforts on the application, and not debugging and ACRN development. Perhaps there are currently available more recent NUC i7 boards, that would be suitable? Also doesn't have to be NUC and could be some other, similar SFF board that is suited to embedded use. E.g. UP Xtreme.

It's also not entirely clear to me what "supported" means in this context. For example, perhaps it is the case that other Intel Core boards may work, but are not officially supported. Similarly with usage scenarios in the Supported Hardware matrix — are these those which have simply been verified with each platform, or perhaps some boards may lack certain features to support a particular scenario?

Regards,

Andrew

-- 
Andrew Back
http://abopen.com


Re: Intel Core i7 board options.

Andrew Back
 

Hi Terry,

Many thanks for the clarification.

Do you happen to know if there is a distributor in Europe for the WL-10 board? I cannot seem to find anywhere to buy this.

Regarding "supported", it's still not clear to me what this means. I appreciate that the level of granularity is scenario rather than feature, but I cannot ascertain whether lack of support for a particular board and scenario means "will not work" or "we have not validated". The distinction is quite important.

Best,

Andrew

On 17/12/2020 02:40, Zou, Terry wrote:

Hi Andrew, thanks very much for your interests of ACRN project. Yes ACRN is growing up very quickly, we enabled several HW platforms in: https://projectacrn.github.io/latest/reference/hardware.html

Started from Apollo Lake (NUC6CAYH/UP2) and Kaby Lake(NUC7i7BNH) with v1.0/…/6 releases for automotive usage, and enabled Whiskey Lake(WHL-IPC-I7) with v2.0/…/3 for Industrial scenario. Then started latest 11th Gen Intel® Core™ processors (codenamed Tiger Lake-UP3).  Actually we are also looking for mature/commercial TGL NUC or UP Xtreme(www.aaeon.com/) on market, but no available board and conclusion yet. So welcome any preference/suggestion from you and community : )

 

So for Industrial usage, Whiskey Lake and Maxtang WL-10 board is still preferred platform. If you do not have available Kaby Lake NUC7i7xxx, you may wait for sometime, when TGL NUC or UP Xtreme ready in market. We will also keep you updated and refresh Supported Hardware in ACRN project page.

 

For ‘supported’ platform, we did not break-down each feature on HW, but general separated user scenario, e.g., Apollo Lake/Kaby Lake only for SDC scenario, but Whiskey Lake for all scenarios: Safety VM, Logical Partition…

 

Best Regards

Terry

 

From: acrn-users@... <acrn-users@...> On Behalf Of Andrew Back
Sent: Wednesday, December 16, 2020 6:44 PM
To: acrn-users@...
Subject: [acrn-users] Intel Core i7 board options.

 

Hi All,

New to ACRN and wondering what the best options currently are for Intel Core i7 hardware? The documentation lists two NUC7i7xxx boards, but these are now a few years old. The v2.3 release notes mention 11th Gen Intel Core processors, but NUC models with these don't appear to be available yet and I am also not sure if going with the very latest hardware would be wise, considering that we want to focus our efforts on the application, and not debugging and ACRN development. Perhaps there are currently available more recent NUC i7 boards, that would be suitable? Also doesn't have to be NUC and could be some other, similar SFF board that is suited to embedded use. E.g. UP Xtreme.

It's also not entirely clear to me what "supported" means in this context. For example, perhaps it is the case that other Intel Core boards may work, but are not officially supported. Similarly with usage scenarios in the Supported Hardware matrix — are these those which have simply been verified with each platform, or perhaps some boards may lack certain features to support a particular scenario?

Regards,

Andrew

-- 
Andrew Back
http://abopen.com


Re: Intel Core i7 board options.

Zou, Terry
 

Hi Andrew, thanks very much for your interests of ACRN project. Yes ACRN is growing up very quickly, we enabled several HW platforms in: https://projectacrn.github.io/latest/reference/hardware.html

Started from Apollo Lake (NUC6CAYH/UP2) and Kaby Lake(NUC7i7BNH) with v1.0/…/6 releases for automotive usage, and enabled Whiskey Lake(WHL-IPC-I7) with v2.0/…/3 for Industrial scenario. Then started latest 11th Gen Intel® Core™ processors (codenamed Tiger Lake-UP3).  Actually we are also looking for mature/commercial TGL NUC or UP Xtreme(www.aaeon.com/) on market, but no available board and conclusion yet. So welcome any preference/suggestion from you and community : )

 

So for Industrial usage, Whiskey Lake and Maxtang WL-10 board is still preferred platform. If you do not have available Kaby Lake NUC7i7xxx, you may wait for sometime, when TGL NUC or UP Xtreme ready in market. We will also keep you updated and refresh Supported Hardware in ACRN project page.

 

For ‘supported’ platform, we did not break-down each feature on HW, but general separated user scenario, e.g., Apollo Lake/Kaby Lake only for SDC scenario, but Whiskey Lake for all scenarios: Safety VM, Logical Partition…

 

Best Regards

Terry

 

From: acrn-users@... <acrn-users@...> On Behalf Of Andrew Back
Sent: Wednesday, December 16, 2020 6:44 PM
To: acrn-users@...
Subject: [acrn-users] Intel Core i7 board options.

 

Hi All,

New to ACRN and wondering what the best options currently are for Intel Core i7 hardware? The documentation lists two NUC7i7xxx boards, but these are now a few years old. The v2.3 release notes mention 11th Gen Intel Core processors, but NUC models with these don't appear to be available yet and I am also not sure if going with the very latest hardware would be wise, considering that we want to focus our efforts on the application, and not debugging and ACRN development. Perhaps there are currently available more recent NUC i7 boards, that would be suitable? Also doesn't have to be NUC and could be some other, similar SFF board that is suited to embedded use. E.g. UP Xtreme.

It's also not entirely clear to me what "supported" means in this context. For example, perhaps it is the case that other Intel Core boards may work, but are not officially supported. Similarly with usage scenarios in the Supported Hardware matrix — are these those which have simply been verified with each platform, or perhaps some boards may lack certain features to support a particular scenario?

Regards,

Andrew


Re: Intel Core i7 board options.

AshKay
 

ACRN is a great platform and understand that it is still maturing however within community there is certainly a need for a clear deployment instructions or some sort of matrix of what's supported. With platform/hardware variations out there not sure if it is possible to create such matrix. We have made investments on the recommended platform and now we have been spending cycles on ACRN debugging and not on our core application, still we have been making every effort to get the basic UOS working. Currently ACRN not being a out of box solution can certainly cause obstruction in adaption for many..


Intel Core i7 board options.

Andrew Back
 

Hi All,

New to ACRN and wondering what the best options currently are for Intel Core i7 hardware? The documentation lists two NUC7i7xxx boards, but these are now a few years old. The v2.3 release notes mention 11th Gen Intel Core processors, but NUC models with these don't appear to be available yet and I am also not sure if going with the very latest hardware would be wise, considering that we want to focus our efforts on the application, and not debugging and ACRN development. Perhaps there are currently available more recent NUC i7 boards, that would be suitable? Also doesn't have to be NUC and could be some other, similar SFF board that is suited to embedded use. E.g. UP Xtreme.

It's also not entirely clear to me what "supported" means in this context. For example, perhaps it is the case that other Intel Core boards may work, but are not officially supported. Similarly with usage scenarios in the Supported Hardware matrix — are these those which have simply been verified with each platform, or perhaps some boards may lack certain features to support a particular scenario?

Regards,

Andrew

421 - 440 of 1237