Hi all,
Do we have, or do we have plans for, an image that's based on Ubuntu that's usable with the foundation model? The only part I don't know how to do for myself is build the .axf file, which I guess I can teach myself but it would be even easier to just download something :-)
Cheers, mwh
On 26 November 2013 21:51, Michael Hudson-Doyle michael.hudson@linaro.orgwrote:
Hi all,
Do we have, or do we have plans for, an image that's based on Ubuntu that's usable with the foundation model? The only part I don't know how to do for myself is build the .axf file
AXF is sooo unfashionable these days ;-) It's all ARM Trusted Firmware, UEFI and a proper Image file.
, which I guess I can teach myself but it would be even easier to just download something :-)
You can just use the AXF or firmware & Image file from the OpenEmbedded AArch64 releases [1]. The kernel will/should be the same for Ubuntu and OpenEmbedded. At least it is for ARMv7.
Then, "all" you need is an initrd and rootfs for AArch64.
Cheers, mwh
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Hi Ryan,
On 11/27/2013 01:49 AM, Ryan Harkin wrote:
On 26 November 2013 21:51, Michael Hudson-Doyle <michael.hudson@linaro.org mailto:michael.hudson@linaro.org> wrote:
Hi all, Do we have, or do we have plans for, an image that's based on Ubuntu that's usable with the foundation model? The only part I don't know how to do for myself is build the .axf fileAXF is sooo unfashionable these days ;-) It's all ARM Trusted Firmware, UEFI and a proper Image file.
By how much does this increase the number and variety of storage media a simulator must implement? By how much does this increase the number of instructions that must executed prior to running the kernel? Why would one prefer these more heavy-handed boot methods if one's primary interest is running the Linux kernel, Linux userspace processes, or both in a simulator? Are there instructions for running this stuff on QEMU?
By the way I find the terminology of "AXF" very confusing. As far as I understand it, AXF is essentially synonymous with the ARM ELF file format. What's really being discussed, though, is the boot-wrapper, right?
Thanks, Christopher
On 27 November 2013 15:07, Christopher Covington cov@codeaurora.org wrote:
Are there instructions for running this stuff on QEMU?
There's no 64 bit system emulation support in QEMU just yet, so the first item in the instructions is "1. wait until end of Q1 2014" :-)
By the way I find the terminology of "AXF" very confusing. As far as I understand it, AXF is essentially synonymous with the ARM ELF file format. What's really being discussed, though, is the boot-wrapper, right?
Correct. Usually when people say "AXF" (in the context of talking about linux on the Foundation Model) they just mean "the file that happens to be an ELF file which wraps up the kernel and a little bit of stub booting code to start it".
-- PMM
Hi Peter,
On 11/27/2013 10:20 AM, Peter Maydell wrote:
On 27 November 2013 15:07, Christopher Covington cov@codeaurora.org wrote:
Are there instructions for running this stuff on QEMU?
There's no 64 bit system emulation support in QEMU just yet, so the first item in the instructions is "1. wait until end of Q1 2014" :-)
Ah yes. I would expect that UEFI and Trusted Foundations would theoretically build and run on ARMv7, but I guess in that configuration they're maybe not as interesting or well tested.
Thanks, Christopher
On 27/11/13 15:07, Christopher Covington wrote:
Hi Ryan,
On 11/27/2013 01:49 AM, Ryan Harkin wrote:
On 26 November 2013 21:51, Michael Hudson-Doyle <michael.hudson@linaro.org mailto:michael.hudson@linaro.org> wrote:
Hi all, Do we have, or do we have plans for, an image that's based on Ubuntu that's usable with the foundation model? The only part I don't know how to do for myself is build the .axf fileAXF is sooo unfashionable these days ;-) It's all ARM Trusted Firmware, UEFI and a proper Image file.
By how much does this increase the number and variety of storage media a simulator must implement? By how much does this increase the number of instructions that must executed prior to running the kernel? Why would one prefer these more heavy-handed boot methods if one's primary interest is running the Linux kernel, Linux userspace processes, or both in a simulator? Are there instructions for running this stuff on QEMU?
By the way I find the terminology of "AXF" very confusing. As far as I understand it, AXF is essentially synonymous with the ARM ELF file format. What's really being discussed, though, is the boot-wrapper, right?
Thanks, Christopher
AXF is a filename extension and its origins are historical. It dates to the pre-elf days when ARM's internal toolchain used proprietary object and executable file formats. AOF was the extension used for linkable Object files and AXF for eXecutable files. When the switch to ELF occurred, the extension AXF was maintained as it helped users know that the file was firstly executable, and secondly not a windows executable (windows works by mapping file extensions onto programs that can operate on them, like the ARM debugger).
R.
Hi Richard,
On 11/27/2013 10:27 AM, Richard Earnshaw wrote:
On 27/11/13 15:07, Christopher Covington wrote:
By the way I find the terminology of "AXF" very confusing. As far as I understand it, AXF is essentially synonymous with the ARM ELF file format. What's really being discussed, though, is the boot-wrapper, right?
AXF is a filename extension and its origins are historical. It dates to the pre-elf days when ARM's internal toolchain used proprietary object and executable file formats. AOF was the extension used for linkable Object files and AXF for eXecutable files. When the switch to ELF occurred, the extension AXF was maintained as it helped users know that the file was firstly executable, and secondly not a windows executable (windows works by mapping file extensions onto programs that can operate on them, like the ARM debugger).
I've often wondered. Thanks for the history lesson!
Christopher
+++ Michael Hudson-Doyle [2013-11-27 10:51 +1300]:
Hi all,
Do we have, or do we have plans for, an image that's based on Ubuntu that's usable with the foundation model? The only part I don't know how to do for myself is build the .axf file, which I guess I can teach myself but it would be even easier to just download something :-)
Which sort of image did you have in mind? presumably arm64 as you are using the model?
I've used ubuntu rootfs with the .axf files from the OE image. The only thing you have to change is the kernel command line (which of course the axf wrapper makes awkward - see below).
Here is an ubuntu arm64 rootfs + suitable kernel images http://people.debian.org/~wookey/bootstrap/rootfs/ (and a debian one as of last week) https://wiki.debian.org/Arm64Port#Pre-built_Rootfs
They also work (a whole lot faster) with qemu.
There is a wiki page somewhere for wrapping your own kernel with bootwrapper foo, but I found it much easier to use a handy internal tool which rewrites the kernel command line inside a .axf file, which makes it a one-liner to turn a working OE kernel .axf from linaro snapshots into one that works for an ubuntu image.
This is nothing more than some unpacking + objdump runes, but of course being arm-written software (by Jim) would probably take months of tiresome effort arguing with lawyers to get it released, so you can't use it. :-(
It could get turned into a wiki page of runes if there is demand...
Wookey
Hi Wookey,
On 11/27/2013 10:58 AM, Wookey wrote:
+++ Michael Hudson-Doyle [2013-11-27 10:51 +1300]:
Hi all,
Do we have, or do we have plans for, an image that's based on Ubuntu that's usable with the foundation model? The only part I don't know how to do for myself is build the .axf file, which I guess I can teach myself but it would be even easier to just download something :-)
Which sort of image did you have in mind? presumably arm64 as you are using the model?
I've used ubuntu rootfs with the .axf files from the OE image. The only thing you have to change is the kernel command line (which of course the axf wrapper makes awkward - see below).
Here is an ubuntu arm64 rootfs + suitable kernel images http://people.debian.org/~wookey/bootstrap/rootfs/ (and a debian one as of last week) https://wiki.debian.org/Arm64Port#Pre-built_Rootfs
They also work (a whole lot faster) with qemu.
There is a wiki page somewhere for wrapping your own kernel with bootwrapper foo, but I found it much easier to use a handy internal tool which rewrites the kernel command line inside a .axf file, which makes it a one-liner to turn a working OE kernel .axf from linaro snapshots into one that works for an ubuntu image.
This is nothing more than some unpacking + objdump runes, but of course being arm-written software (by Jim) would probably take months of tiresome effort arguing with lawyers to get it released, so you can't use it. :-(
It could get turned into a wiki page of runes if there is demand...
In my opinion, the nicer solution is to port the semihosting boot wrapper to 64-bit. We've done that internally, but don't currently have approval to share that work. It's not too difficult though--basically just drop the AArch64 boot.S into the 32-bit bootwrapper code with semihosting support and you're most of the way there. A simulator with instruction tracing or stepping is probably necessary for debugging.
One can also use UEFI as a semihosting bootloader, hence my interest in data on the overhead.
Regards, Christopher
+++ Christopher Covington [2013-11-27 11:17 -0500]:
Hi Wookey,
There is a wiki page somewhere for wrapping your own kernel with bootwrapper foo, but I found it much easier to use a handy internal tool which rewrites the kernel command line inside a .axf file, which makes it a one-liner to turn a working OE kernel .axf from linaro snapshots into one that works for an ubuntu image.
This is nothing more than some unpacking + objdump runes, but of course being arm-written software (by Jim) would probably take months of tiresome effort arguing with lawyers to get it released, so you can't use it. :-(
It could get turned into a wiki page of runes if there is demand...
In my opinion, the nicer solution is to port the semihosting boot wrapper to 64-bit. We've done that internally, but don't currently have approval to share that work. It's not too difficult though--basically just drop the AArch64 boot.S into the 32-bit bootwrapper code with semihosting support and you're most of the way there. A simulator with instruction tracing or stepping is probably necessary for debugging.
I didn't understand a lot of those words, but it really doesn't sound easier than 'a little shell script that lets me change the command line in a working .axf kernel'. Turns out said shell script was actually written wearing a linaro hat so I'll stick it somewhere and add a wiki page.
Wookey
On 11/27/13 13:27, Wookey wrote:
+++ Christopher Covington [2013-11-27 11:17 -0500]:
Hi Wookey,
There is a wiki page somewhere for wrapping your own kernel
Wow. Curiosity has gotten the best of me. (new to the list).
I didn't understand a lot of those words, but it really doesn't sound easier than 'a little shell script that lets me change the command line in a working .axf kernel'. Turns out said shell script was actually written wearing a linaro hat so I'll stick it somewhere and add a wiki page.
Wookey
Hi Wookey, remember me? (hint: anakin).....
So, being clueless to Linaro (but good intentions) is not the simple method to set up a tool chain for either native or cross compiling depending whatever is needed, kernel, gcc, tools, libraries, etc etc?
With this approach compiling (or fixing code) is a similar effort, one piece of software at a time. The methodology of booting, from bootloaders or with a custom boostrap, processor specific, should be straightforward and all supported.
Is linaro trying to be one of those (useless) commercial embedded system, where any really neat or useful code is a bolt_on with little or no documentation on how to build the desired code from sources?
Why all the gymnastics on images and such; why use what others have packaged up, in lieu of just compiling the code, kernel or otherwise?
Once that is done, packaging for a particular distro should be straightforward, if not trivial; or do I "not get the focus of linaro"?
To me, "embedded" means from sources up.....
sincerely,
(James)
On 27 November 2013 18:27, Wookey wookey@wookware.org wrote:
+++ Christopher Covington [2013-11-27 11:17 -0500]:
In my opinion, the nicer solution is to port the semihosting boot wrapper to 64-bit. We've done that internally, but don't currently have approval to share that work. It's not too difficult though--basically just drop the AArch64 boot.S into the 32-bit bootwrapper code with semihosting support and you're most of the way there. A simulator with instruction tracing or stepping is probably necessary for debugging.
I didn't understand a lot of those words, but it really doesn't sound easier than 'a little shell script that lets me change the command line in a working .axf kernel'. Turns out said shell script was actually written wearing a linaro hat so I'll stick it somewhere and add a wiki page.
Christopher is advocating that somebody should fix the boot wrapper, so you have a single trivial .axf file which doesn't include the kernel at all, and you then pass on the command line to the model (a) the kernel you actually want to boot and (b) the command line to be passed to the kernel. This is how the boot wrapper for 32 bit models works (because I did that because I was fed up with rerolling .axf files for new kernels). It's much nicer to use and means you don't have to mess around with altering .axf files at all. I entirely agree that it would be a good idea if somebody wanted to do this work :-)
-- PMM
On 27 November 2013 19:13, Peter Maydell peter.maydell@linaro.org wrote:
On 27 November 2013 18:27, Wookey wookey@wookware.org wrote:
+++ Christopher Covington [2013-11-27 11:17 -0500]:
In my opinion, the nicer solution is to port the semihosting boot
wrapper to
64-bit. We've done that internally, but don't currently have approval
to share
that work. It's not too difficult though--basically just drop the
AArch64
boot.S into the 32-bit bootwrapper code with semihosting support and
you're
most of the way there. A simulator with instruction tracing or stepping
is
probably necessary for debugging.
I didn't understand a lot of those words, but it really doesn't sound easier than 'a little shell script that lets me change the command line in a working .axf kernel'. Turns out said shell script was actually written wearing a linaro hat so I'll stick it somewhere and add a wiki
page.
Christopher is advocating that somebody should fix the boot wrapper, so you have a single trivial .axf file which doesn't include the kernel at all, and you then pass on the command line to the model (a) the kernel you actually want to boot and (b) the command line to be passed to the kernel. This is how the boot wrapper for 32 bit models works (because I did that because I was fed up with rerolling .axf files for new kernels). It's much nicer to use and means you don't have to mess around with altering .axf files at all. I entirely agree that it would be a good idea if somebody wanted to do this work :-)
I entirely disagree and think it's a terrible idea. And Linaro isn't going to support it if someone does it.
-- PMM
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 28 November 2013 07:54, Ryan Harkin ryan.harkin@linaro.org wrote:
On 27 November 2013 19:13, Peter Maydell peter.maydell@linaro.org wrote:
Christopher is advocating that somebody should fix the boot wrapper, so you have a single trivial .axf file which doesn't include the kernel at all
I entirely agree that it would be a good idea if somebody wanted to do this work :-)
I entirely disagree and think it's a terrible idea. And Linaro isn't going to support it if someone does it.
On the basis that we should be moving away from the bootwrapper entirely? Or that you think that a bootwrapper with builtin kernel is a good thing?
-- PMM
On 28 November 2013 09:05, Peter Maydell peter.maydell@linaro.org wrote:
On 28 November 2013 07:54, Ryan Harkin ryan.harkin@linaro.org wrote:
On 27 November 2013 19:13, Peter Maydell peter.maydell@linaro.org
wrote:
Christopher is advocating that somebody should fix the boot wrapper, so you have a single trivial .axf file which doesn't include the kernel at all
I entirely agree that it would be a good idea if somebody wanted to do this work :-)
I entirely disagree and think it's a terrible idea. And Linaro isn't
going
to support it if someone does it.
On the basis that we should be moving away from the bootwrapper entirely?
Yes, exactly.
Or that you think that a bootwrapper with builtin kernel is a good thing?
Shudder! No! :-)
-- PMM
Wookey wookey@wookware.org writes:
+++ Michael Hudson-Doyle [2013-11-27 10:51 +1300]:
Hi all,
Do we have, or do we have plans for, an image that's based on Ubuntu that's usable with the foundation model? The only part I don't know how to do for myself is build the .axf file, which I guess I can teach myself but it would be even easier to just download something :-)
Which sort of image did you have in mind? presumably arm64 as you are using the model?
Yes, ARM64. I've since (internally) been pointed to https://wiki.ubuntu.com/ARM64/FoundationModel which answered my immediate need...
I've used ubuntu rootfs with the .axf files from the OE image. The only thing you have to change is the kernel command line (which of course the axf wrapper makes awkward - see below).
Here is an ubuntu arm64 rootfs + suitable kernel images http://people.debian.org/~wookey/bootstrap/rootfs/ (and a debian one as of last week) https://wiki.debian.org/Arm64Port#Pre-built_Rootfs
They also work (a whole lot faster) with qemu.
There is a wiki page somewhere for wrapping your own kernel with bootwrapper foo, but I found it much easier to use a handy internal tool which rewrites the kernel command line inside a .axf file, which makes it a one-liner to turn a working OE kernel .axf from linaro snapshots into one that works for an ubuntu image.
This is nothing more than some unpacking + objdump runes, but of course being arm-written software (by Jim) would probably take months of tiresome effort arguing with lawyers to get it released, so you can't use it. :-(
It could get turned into a wiki page of runes if there is demand...
*I* just wanted something that works, for now! Thanks anyway!
Cheers, mwh
-
Christopher Covington -
Michael Hudson-Doyle -
Peter Maydell -
Richard Earnshaw -
Ryan Harkin -
wireless -
Wookey