Just heard from Ryan that

semihost-cmd would not work ):

 

We need to have the images at the location from where the models invocation is being made.

 

So the alternate question now is where does LAVA makes the model invocation from. I am thinking of having a symbolic links created to overcome this issue.

 

Thanks

Basil Eljuse…

 

 

From: Basil Eljuse
Sent: 12 February 2014 19:20
To: 'Tyler Baker'
Cc: Linaro Validation; Dean Arnold
Subject: RE: [Linaro-validation] Query on 5.3 Foundation model support in LAVA

 

Hi Tyler,

 

Thanks a lot for the clarifications. We gave it a go today, however are stuck at the point where we need help. Let me retrace the sequence of steps we took.

 

·         Ryan Harkin confirmed that image_foundation.axf is used only with the legacy foundation models which is not supported with our trusted fw. For the 5.3 FVP foundation model we should not specify the .axf not the uefi_foundation.bin from the hardware packs.

·         We created a custom device type. Please see the attached reference which has anything relevant with .axf cleaned up and our needed arguments/flags added.

simulator_command = sudo -u www-data /fastmodels/current/Foundation_v8 --block-device={IMG} --network=nat --no-secure-memory --visualization --gicv3 --cores=4 --data="/test-binaries/foundation/bl1.bin"@0x0 --data="/test-binaries/foundation/uefi_fvp-base.bin"@0x8000000

·         Initially we tried with this and could see that LAVA foundation model instance successfully loads the bootloader images and launches uefi. However uefi fails saying unable to detect the kernel. Please see the error message below.

Booting trusted firmware boot loader stage 1

 Built : 11:33:25, Feb 12 2014

 Booting trusted firmware boot loader stage 2

 BL2 Built : 14:39:42, Nov 22 2013

 Booting trusted firmware boot loader stage 3

 sh: 1: xterm: not found

 BL31 Built : 14:39:43, Nov 22 2013

 PROGRESS CODE: V3020003 I0

 PROGRESS CODE: V3020002 I0

 PROGRESS CODE: V3020003 I0

 PROGRESS CODE: V3021001 I0

 [2J[01;01H[=3h[2J[01;01H[2J[01;01H[=3h[2J[01;01H[2J[01;01H[=3h[2J[01;01H[2J[01;01H[=3h[2J[01;01H[2J[01;01H[=3h[2J[01;01H[2J[01;01H[=3h[2J[01;01H[0m[35m[40m[0m[37m[40mThe default boot selection will start in  10 seconds  9 seconds

   8 seconds

   7 seconds  6 seconds

   5 seconds

   4 seconds  3 seconds

   2 seconds

   1 seconds

 ERROR: Did not find Linux kernel.

 [1] Linaro disk image on virtio

        - VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/Image

        - Arguments: console=ttyAMA0 earlyprintk=pl011,0x1c090000 debug user_debug=31 loglevel=9 root=/dev/vda2

        - FDT: VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/fdt.dtb

        - LoaderType: Linux kernel with Local FDT

 -----------------------

 Global FDT Config

        - VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/fdt.dtb

 -----------------------

 [a] Boot Manager

 [b] Shell

 [c] Reboot

 [d] Shutdown

 Start:

 

·         After asking around we were adviced to use the –semihost-cmd flag of foundation model to tell the model where to look for kernel and fdt, so we extended our config to have below entries, but still failed with the same message.  Attaching our json  and log also for reference. We are bit stuck at this point. Need help in understanding what is missing from our end.

boot_options =

        semihost-cmd

 

[semihost-cmd]

default=/test-binaries/foundation

·         We also came across another issue which would be great to be addressed. We initially gave both semihost-cmd and cores in the boot options but for some reason LAVA is treating it as a single argument and is appending the whole string together without any space. It is clear from the args statement that it is treating this as a single option than 2. This need to get fixed.

<LAVA_DISPATCHER>2014-02-12 04:59:22 PM INFO: launching fastmodel with command u'sudo -u www-data /fastmodels/current/Foundation_v8 --block-device=/srv/lava/instances/production/var/www/lava-server/images/tmpJ01X2A/sd.img --network=nat --no-secure-memory --visualization --gicv3 --cores=1--semihost-cmd=/test-binaries/foundation'

 

args: [u'/usr/bin/sudo', u'-u', u'www-data', u'/fastmodels/current/Foundation_v8', u'--block-device=/srv/lava/instances/production/var/www/lava-server/images/tmpJ01X2A/sd.img', u'--network=nat', u'--no-secure-memory', u'--visualization', u'--gicv3', u'--cores=1--semihost-cmd=/test-binaries/foundation']

·         The other issue we are facing is the series of flags like –visualisation –gicv3 –no-secure-memory, which does not have the typical flag=value pair usage. We would ideally like this to be specified similar to boot_options so they can be over-ridden by json and crucially we can have ‘empty’ defaults so that it gets applied only if specified in json. I am hoping that this get addressed by the request we already made with you on the provision to have empty flags. But highlighting here that it is more critical on foundation models now.

 

Please advice.

 

Thanks

Basil Eljuse…

 

 

 

From: Tyler Baker [mailto:tyler.baker@linaro.org]
Sent: 11 February 2014 22:17
To: Basil Eljuse
Cc: Linaro Validation; Dean Arnold
Subject: Re: [Linaro-validation] Query on 5.3 Foundation model support in LAVA

 

Hi Basil,

 

 

Please see my responses inline:

 

On 11 February 2014 13:51, Basil Eljuse <Basil.Eljuse@arm.com> wrote:

A gentle reminder !

 

From: Basil Eljuse
Sent: 09 February 2014 16:06
To: 'Linaro Validation'
Cc: Dean Arnold
Subject: Query on 5.3 Foundation model support in LAVA

 

Hi,

 

We were trying to get the latest published (5.3) foundation models in LAVA.

 

Using the reference as http://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/default-config/lava-dispatcher/device-types/rtsm_foundation-armv8.conf

 

# The new (2013-10-03) Foundation model install places the simulator binary at Foundation_v8pkg/models/Linux64_GCC-4.1/Foundation_v8

21 # A symbolic link has been created in our arm_models-2013-10-03.tgz package to workaround this change for compatibilty sake. If you are getting an error

22 # chances are you are running a newer Foundation model and need to adjust this path. 

23 simulator_command = sudo -u www-data /opt/arm/Foundation_v8pkg/Foundation_v8 --image={AXF} --block-device={IMG} --network=nat

 

Not quite sure what the comment refers to. However the key point for me is that rather than using the axf file I was hoping to define the boot options similar to what we have for the Base models.

 

This comment refers to the older foundation models:

 

 - Older version of the foundation models have binaries in different locations:

 

tyler@i5-vm:~/Downloads/models/Foundation_v8pkg$ ls -al

total 24

drwxrwxrwx 5 tyler tyler 4096 Jan 22 16:37 .

drwxr-xr-x 7 tyler tyler 4096 Jan 22 16:38 ..

drwxrwxrwx 2 tyler tyler 4096 Jan 22 16:35 doc

drwxrwxrwx 2 tyler tyler 4096 Jan 22 16:35 examples

lrwxrwxrwx 1 tyler tyler   36 Jan 22 16:36 Foundation_v8 -> models/Linux64_GCC-4.1/Foundation_v8

-rwxrwxrwx 1 tyler tyler   80 Nov  8 01:59 Internal_use_only.txt

lrwxrwxrwx 1 tyler tyler   39 Jan 22 16:37 libarmctmodel.so -> models/Linux64_GCC-4.1/libarmctmodel.so

lrwxrwxrwx 1 tyler tyler   58 Jan 22 16:37 libMAXCOREInitSimulationEngine.so.2 -> models/Linux64_GCC-4.1/libMAXCOREInitSimulationEngine.so.2

drwxrwxrwx 3 tyler tyler 4096 Jan 22 16:35 models

 

 

So symlinks were created inside the foundation model tar ball package that we deploy into the lab to maintain backward compatibility with the older models.

 

If you don't care about older version of the foundation models, you need to adjust your simulator_command to the proper path for the new model:

 

New model:

 

 - simulator_command = sudo -u www-data /opt/arm/Foundation_v8pkg/models/Linux64_GCC-4.1/Foundation_v8--image={AXF} --block-device={IMG} --network=nat

 

Old model:

 

 - simulator_command = sudo -u www-data /opt/arm/Foundation_v8pkg/Foundation_v8--image={AXF} --block-device={IMG} --network=nat

 

 

The following is the typical boot options I wanted to use

 

<path-to>/Foundation_v8                   \

--cores=4                                 \

--no-secure-memory                        \

--visualization                           \

--gicv3                                   \

--data="<path to bl1.bin>"@0x0            \

--data="<path to UEFI binary>"@0x8000000  \

--block-device="<path-to>/vexpress64-openembedded_lamp-armv8_20130927-7.img"

 

This would let me override the various argument like number of cores / --gicv3 or –no-gicv3 flag.

 

 

At Linaro we have only had the need to use the boot_option "cores" as seen above. Feel free to add any options you would like here :) You can add these options in either your device configuration or device-type configuration.

 

 

My understanding is that foundation models are quite cutdown version of Base models and hence does   not have semihosting capabilitie etc, hence the uefi and blockdevice path should be relative to that of the foundation model location.

 

I believe you are correct here. I have never tried this with a foundation model though.

 

 

Question:: Can we use the boot options for foundation model the similar way it is used for base models?  Is there an example for the same where we could cross-reference?

 

The answer is yes you can, here is an example on the base model:

 

 

Works the same way on the foundation model as it does on the base model.

 

 

Thanks

Basil Eljuse…


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782


_______________________________________________
linaro-validation mailing list
linaro-validation@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-validation

 

Hopefully that helps some, let me know if you still have any questions!

 

 

Cheers,

 

--

Tyler Baker
Technical Architect, LAVA
Linaro.org | Open source software for ARM SoCs
Follow Linaro: 
http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782