Hi,
I am trying to port klibc to aarch64. My code is available from:
git clone git://git.linaro.org/people/anil.singhar/klibc-aarch64.git
At this point, I am trying to fix the following issues. Any help / comment / advice / suggestion is highly appreciated.
1. Need to find the correct value for *KLIBCSHAREDFLAGS *(What value should I set *Ttext* to in the aarch64 specific MCONFIG file?). Right now the MCONFIG looks as follows:
# -*- makefile -*- # # arch/aarch64/MCONFIG # # Special rules for this architecture. Note that this is actually # included from the main Makefile, and that pathnames should be # accordingly. #
CPU_ARCH ?= armv8-a CPU_TUNE ?= generic
KLIBCOPTFLAGS += -Os -march=$(CPU_ARCH) -mtune=$(CPU_TUNE) KLIBCBITSIZE = 64 KLIBCREQFLAGS += -fno-exceptions #KLIBCSTRIPFLAGS += -R .ARM.exidx
# Extra linkflags when building the shared version of the library # This address needs to be reachable using normal inter-module # calls, and work on the memory models for this architecture *#KLIBCSHAREDFLAGS = -Ttext 0x01800200* *<-- Is this value correct..?* #KLIBCREQFLAGS += #KLIBCOPTFLAGS += -mgeneral-regs-only
2. The *stat* family of syscalls don't work correctly. There is only one actual syscall: fstat, which is used by lstat and stat. The syscall doesn't seem to return valid values for target files. e.g. The following fields are wrong:
toot@genericarmv8:~/anilss/AArch64/klibc-aarch64/usr/klibc/tests# ./stat test.out Path = test.out st_dev = 0x11 (0,17) st_ino = 5910539 st_mode = 0 st_nlink = 4295000484 <-- This is wrong st_uid = 0 st_gid = 0 st_rdev = 0x0 (0,0) st_size = 15 st_blksize = 1380537164 st_blocks = 223008806 st_atim = 1048576.000000008 st.mtim = 1380612975.029926968 st.ctim = 1380537164.223008806
Because the fields are wrong, the parsed values are also wrong. Applications such as ls, gzip etc. fail to work because they rely on this syscall.
Since I am doing the development on ARMv8 Foundation model using linaro openembedded image, is there a debug version of the kernel (the one * img-foundation.axf*) that I can use to debug the syscall itself in kernel mode using kgdb? Any other debugging ideas..?
Thanks and Regards, Anil
On Tue, Oct 01, 2013 at 05:49:12PM +0530, Anil Singhar wrote:
I am trying to port klibc to aarch64. My code is available from:
Have you seen https://github.com/codehelp/klibc-aarch64 ?
Probably worth collaborating and cleaning that up.
... Adam
Hi Adam,
I did adopt Neil's (codehelp) code as my baseline. This is close to complete, but I am still stuck at one syscall (the stat family of syscalls). Let me know if you know someone who can help.
Thanks, Anil
On 2 October 2013 23:07, Adam Conrad adconrad@0c3.net wrote:
On Tue, Oct 01, 2013 at 05:49:12PM +0530, Anil Singhar wrote:
I am trying to port klibc to aarch64. My code is available from:
Have you seen https://github.com/codehelp/klibc-aarch64 ?
Probably worth collaborating and cleaning that up.
... Adam
On 1 October 2013 15:19, Anil Singhar anil.singhar@linaro.org wrote:
Hi,
I am trying to port klibc to aarch64. My code is available from:
git clone git://git.linaro.org/people/anil.singhar/klibc-aarch64.git
At this point, I am trying to fix the following issues. Any help / comment / advice / suggestion is highly appreciated.
- Need to find the correct value for KLIBCSHAREDFLAGS (What value should I
set Ttext to in the aarch64 specific MCONFIG file?). Right now the MCONFIG looks as follows:
It is hard to answer to this question as I don't know what klibc uses KLIBCSHAREDFLAGS for.
S += -mgeneral-regs-only
- The stat family of syscalls don't work correctly. There is only one
actual syscall: fstat, which is used by lstat and stat. The syscall doesn't seem to return valid values for target files. e.g. The following fields are wrong:
toot@genericarmv8:~/anilss/AArch64/klibc-aarch64/usr/klibc/tests# ./stat test.out Path = test.out st_dev = 0x11 (0,17) st_ino = 5910539 st_mode = 0 st_nlink = 4295000484 <-- This is wrong st_uid = 0 st_gid = 0 st_rdev = 0x0 (0,0) st_size = 15 st_blksize = 1380537164 st_blocks = 223008806 st_atim = 1048576.000000008 st.mtim = 1380612975.029926968 st.ctim = 1380537164.223008806
Because the fields are wrong, the parsed values are also wrong. Applications such as ls, gzip etc. fail to work because they rely on this syscall.
This would imply that the struct stat is defined incorrectly for Aarch64. Looking into the kernel sources ( ./arch/arm64/include/uapi/asm/stat.h points to ./include/uapi/asm-generic/stat.h ) the definition in klibc sources ( ./usr/include/arch/aarch64/klibc/archstat.h ) is indeed incorrect. Once you fix the "struct stat" definition to match what is in the kernel, you should se better results.
Since I am doing the development on ARMv8 Foundation model using linaro openembedded image, is there a debug version of the kernel (the one img-foundation.axf) that I can use to debug the syscall itself in kernel mode using kgdb? Any other debugging ideas..?
Generally speaking it is better to first read the kernel sources related to system call failing before attempting to step in debugger.
Hi Riku,
Thanks for your response.
(1) I tried correcting the klibc definition of struct stat with the kernel definition of stat64, but still I don't get the correct results. e.g. root@genericarmv8:~/anilss/AArch64/klibc-aarch64/usr/klibc/tests# ./stat test.out Path = test.out st_dev = 0x11 (0,17) st_ino = 4194908 st_mode = 0 st_nlink = 0 st_uid = 0 st_gid = 0 st_rdev = 0xf (0,15) st_size = 8 st_blksize = 1380795825 st_blocks = 129482584 st_atim = 1380537164.223008806 st.mtim = 1380537164.223008806
*New definition of stat that I tried is:* /* This matches struct stat64 in glibc2.1, hence the absolutely * insane amounts of padding around dev_t's. * Note: The kernel zero's the padded region because glibc might read them * in the hope that the kernel has stretched to using larger sizes. */ struct stat { __stdev64 (st_dev); unsigned char __pad0[4];
unsigned long __st_ino; unsigned int st_mode; unsigned int st_nlink;
unsigned long st_uid; unsigned long st_gid;
__stdev64 (st_rdev); unsigned char __pad3[4];
long long st_size; unsigned long st_blksize;
unsigned long long st_blocks; /* Number 512-byte blocks allocated. */
struct timespec st_atim; struct timespec st_mtim; struct timespec st_ctim;
unsigned long long st_ino; };
This is same as that in ARM.
Plus I noticed that the original definition that was in klibc for aarch64 (the one with which I have issues) is exactly same as that in x86_64 and there the test works fine. That is bit confusing. On x86_64 it gives the following result (with the same definition that was in aarch64): anilss@anilss:~/Native/klibc-2.0.1/usr/klibc/tests$ ./stat test.out Path = test.out st_dev = 0x801 (8,1) st_ino = 4857342 st_mode = 0100664 st_nlink = 1 st_uid = 1000 st_gid = 1000 st_rdev = 0x0 (0,0) st_size = 8399061 st_blksize = 4096 st_blocks = 16408 st_atim = 1380802488.081739059 st.mtim = 1379586488.807291875 st.ctim = 1379586488.807291875
(2) Per what I have gathered from elsewhere on web, the value of Ttext in KLIBCSHAREDFLAGS should prevent klibc.so from occupying same virtual address space as some other module. May be this understanding is not sufficient.
# Extra linkflags when building the shared version of the library # This address needs to be reachable using normal inter-module # calls, and work on the memory models for this architecture KLIBCSHAREDFLAGS = -Ttext 0x01800200 #KLIBCREQFLAGS += #KLIBCOPTFLAGS += -mgeneral-regs-only
Thanks and Regards, Anil
On 3 October 2013 12:29, Riku Voipio riku.voipio@linaro.org wrote:
On 1 October 2013 15:19, Anil Singhar anil.singhar@linaro.org wrote:
Hi,
I am trying to port klibc to aarch64. My code is available from:
git clone git://git.linaro.org/people/anil.singhar/klibc-aarch64.git
At this point, I am trying to fix the following issues. Any help /
comment /
advice / suggestion is highly appreciated.
- Need to find the correct value for KLIBCSHAREDFLAGS (What value
should I
set Ttext to in the aarch64 specific MCONFIG file?). Right now the
MCONFIG
looks as follows:
It is hard to answer to this question as I don't know what klibc uses KLIBCSHAREDFLAGS for.
S += -mgeneral-regs-only
- The stat family of syscalls don't work correctly. There is only one
actual syscall: fstat, which is used by lstat and stat. The syscall
doesn't
seem to return valid values for target files. e.g. The following fields
are
wrong:
toot@genericarmv8:~/anilss/AArch64/klibc-aarch64/usr/klibc/tests# ./stat test.out Path = test.out st_dev = 0x11 (0,17) st_ino = 5910539 st_mode = 0 st_nlink = 4295000484 <-- This is wrong st_uid = 0 st_gid = 0 st_rdev = 0x0 (0,0) st_size = 15 st_blksize = 1380537164 st_blocks = 223008806 st_atim = 1048576.000000008 st.mtim = 1380612975.029926968 st.ctim = 1380537164.223008806
Because the fields are wrong, the parsed values are also wrong.
Applications
such as ls, gzip etc. fail to work because they rely on this syscall.
This would imply that the struct stat is defined incorrectly for Aarch64. Looking into the kernel sources ( ./arch/arm64/include/uapi/asm/stat.h points to ./include/uapi/asm-generic/stat.h ) the definition in klibc sources ( ./usr/include/arch/aarch64/klibc/archstat.h ) is indeed incorrect. Once you fix the "struct stat" definition to match what is in the kernel, you should se better results.
Since I am doing the development on ARMv8 Foundation model using linaro openembedded image, is there a debug version of the kernel (the one img-foundation.axf) that I can use to debug the syscall itself in kernel mode using kgdb? Any other debugging ideas..?
Generally speaking it is better to first read the kernel sources related to system call failing before attempting to step in debugger.
On 3 October 2013 22:13, Anil Singhar anil.singhar@linaro.org wrote:
Plus I noticed that the original definition that was in klibc for aarch64 (the one with which I have issues) is exactly same as that in x86_64 and there the test works fine.
The struct stat layout differs from architecture to architecture. "This layout works on x86-64" says absolutely nothing about whether it is the right layout for any other architecture.
I don't know where you got the stat layout you say you tried, but that doesn't match what the kernel has:
arm64 uses the generic stat layout: http://lxr.linux.no/#linux+v3.11.3/arch/arm64/include/uapi/asm/stat.h which is defined here: http://lxr.linux.no/#linux+v3.11.3/include/uapi/asm-generic/stat.h
-- PMM
Hi Peter,
Thanks for your help and feedback. The definition from your links did work for me. Now at least stat gives valid outputs and my gzip and ls, which depends on stat, work OK though gzip still doesn't compress for some unknown reason.
Best Regards, Anil
On 3 October 2013 18:54, Peter Maydell peter.maydell@linaro.org wrote:
On 3 October 2013 22:13, Anil Singhar anil.singhar@linaro.org wrote:
Plus I noticed that the original definition that was in klibc for aarch64 (the one with which I have issues) is exactly same as that in x86_64 and there the test works fine.
The struct stat layout differs from architecture to architecture. "This layout works on x86-64" says absolutely nothing about whether it is the right layout for any other architecture.
I don't know where you got the stat layout you say you tried, but that doesn't match what the kernel has:
arm64 uses the generic stat layout: http://lxr.linux.no/#linux+v3.11.3/arch/arm64/include/uapi/asm/stat.h which is defined here: http://lxr.linux.no/#linux+v3.11.3/include/uapi/asm-generic/stat.h
-- PMM
Hi Neil / Riku / Peter,
Thanks for your help.
Now that I have some confidence that the changes are working fine, is it possible for one of you to review the code..? Or could you suggest someone who could do that for me. The code is available at: ( git clone git:// git.linaro.org/people/anil.singhar/klibc-aarch64.git )
I would like to implement review feedback and make it available for upstreaming this week.
Thanks and Regards, Anil
On 4 October 2013 20:31, Anil Singhar anil.singhar@linaro.org wrote:
Hi Peter,
Thanks for your help and feedback. The definition from your links did work for me. Now at least stat gives valid outputs and my gzip and ls, which depends on stat, work OK though gzip still doesn't compress for some unknown reason.
Best Regards, Anil
On 3 October 2013 18:54, Peter Maydell peter.maydell@linaro.org wrote:
On 3 October 2013 22:13, Anil Singhar anil.singhar@linaro.org wrote:
Plus I noticed that the original definition that was in klibc for
aarch64
(the one with which I have issues) is exactly same as that in x86_64 and there the test works fine.
The struct stat layout differs from architecture to architecture. "This layout works on x86-64" says absolutely nothing about whether it is the right layout for any other architecture.
I don't know where you got the stat layout you say you tried, but that doesn't match what the kernel has:
arm64 uses the generic stat layout: http://lxr.linux.no/#linux+v3.11.3/arch/arm64/include/uapi/asm/stat.h which is defined here: http://lxr.linux.no/#linux+v3.11.3/include/uapi/asm-generic/stat.h
-- PMM
On 5 October 2013 08:13, Anil Singhar anil.singhar@linaro.org wrote:
Hi Neil / Riku / Peter,
Thanks for your help.
Now that I have some confidence that the changes are working fine
Well done!
, is it possible for one of you to review the code..? Or could you suggest someone who could do that for me. The code is available at: ( git clone git://git.linaro.org/people/anil.singhar/klibc-aarch64.git )
Have you been able to run the mksh tests? Do you have results available somewhere? I never got to that stage.
I would like to implement review feedback and make it available for upstreaming this week.
Upstream will insist on seeing the test results, I'm afraid. (So rather than using the linaro.org pastebin, it would be best to put the results in your public_html directory on people.linaro.org)
Hi Neil,
Thanks for your response. I prepared the mksh test and ran them. There were 5 failures (out of the 436 tests) as follows. Right now, I don't know if these are failures due to klibc implementation or due to problems with the way I have build mksh itself. To some extent I suspect mksh as well because (i) I could not get mksh_44 (from this link: dget http://ftp.de.debian.org/debian/pool/main/m/mksh/mksh_44-1.dsc , the link seems to be broken) but I used whatever I got ( mksh_44.orig.tar.gz , this may be missing some patches, how to get that.. ).(ii) While building mksh, encountered some compiler errors (e.g. conftest.c) but the building seemed to go fine despite these errors, so I went ahead with testing and ended up with 5 failures out of which mksh ignores 4 and didn't expect 1 as it reports.
So, do you have any idea if I am doing the right thing..? Should I worry about getting mksh build without any compiler error or warning first before attempting to use the tests..? ---------------------------------------------------------------------------------------------------------------- root@genericarmv8:~/anilss/AArch64/mksh# ./mksh test.sh -p $PWD/mksh Testing mksh for conformance: # $MirOS: src/bin/mksh/check.t,v 1.599 2013/02/24 14:22:41 tg Exp $ @(#)MIRBSD KSH R44 2013/02/24 This shell is actually: @(#)MIRBSD KSH R44 2013/02/24 test.sh built for mksh R44 2013/02/24 Trying Perl interpreter 'perl5'... test.sh[70]: perl5: not found Errorlevel 127, running on '' => not using Trying Perl interpreter 'perl'... Errorlevel 0, running on 'linux, Perl version 5.014003' => using it + perl ./check.pl -p /home/root/anilss/AArch64/mksh/mksh -C shell:legacy-no,int:32 -v -s ./check.t pass ./check.t:KSH_VERSION pass ./check.t:selftest-1 pass ./check.t:selftest-2 . . . pass ./check.t:cd-history *FAIL ./check.t:cd-pe (ignored)* Description: Check package for cd -Pe unexpected stdout - first difference: line 2, char 5 (wanted 'n', got 'l' wanted: 0=0 1=0,noread/target 2=0,noread/target/subdir now with -e: 0=0 1=0,noread/target 2=1,noread/target/subdir got: 0=0 1=0,link/target 2=0,link/target/subdir now with -e: 0=0 1=0,link/target 2=1,link/target/subdir pass ./check.t:env-prompt pass ./check.t:expand-ugly . . . pass ./check.t:glob-bad-1 *FAIL ./check.t:glob-bad-2* Description: Check that symbolic links aren't stat()'d unexpected stdout - first difference: line 2, char 2 (wanted 'i', got '*' wanted: dir/abc dir/abc got: dir/abc d*/abc pass ./check.t:glob-range-1 pass ./check.t:glob-range-2 . . . pass ./check.t:history-subst-4 pass ./check.t:history-subst-5 *FAIL ./check.t:history-ed-1 (ignored)* Description: Basic (ed) editing works (assumes you have generic ed editor that prints no prompts). This is for newish ed(1) and stderr. unexpected exit status 32512 (exit-code 127), expected 0 unexpected stdout - got too little output wanted: abc def FOOBAR def got: abc def unexpected stderr - wanted pattern: /^X*13\n16\necho FOOBAR def\nX*$/ got: XX/home/root/anilss/AArch64/mksh/mksh: /bin/ed: not found X/home/root/anilss/AArch64/mksh/mksh: <stdin>[3]: s/abc/FOOBAR/: not found X/home/root/anilss/AArch64/mksh/mksh: <stdin>[4]: w: not found X/home/root/anilss/AArch64/mksh/mksh: <stdin>[5]: q: not found X [incomplete last line] *FAIL ./check.t:history-ed-2 (ignored)* Description: Correct command is edited when number given unexpected exit status 32512 (exit-code 127), expected 0 unexpected stdout - got too little output wanted: line 1 line 2 is here line 3 line 4 line 2 is changed got: line 1 line 2 is here line 3 line 4 unexpected stderr - wanted pattern: /^X*20\n23\necho line 2 is changed\nX*$/ got: XXXXX/home/root/anilss/AArch64/mksh/mksh: /bin/ed: not found X/home/root/anilss/AArch64/mksh/mksh: <stdin>[6]: s/is: not found X/home/root/anilss/AArch64/mksh/mksh: <stdin>[7]: w: not found X/home/root/anilss/AArch64/mksh/mksh: <stdin>[8]: q: not found X [incomplete last line] *FAIL ./check.t:history-ed-3 (ignored)* Description: Newly created multi line commands show up as single command in history. unexpected stdout - first difference: line 2, char 1 (wanted 'F', got 'a' wanted: abc def FOOBAR def a new line 1 echo abc def 2 echo FOOBAR def 3 echo a new line got: abc def a new line 1 echo abc def 2 fc echo 3 s/abc/FOOBAR/ 4 $a 5 echo a new line 6 . 7 w 8 q unexpected stderr - wanted pattern: /^X*13\n32\necho FOOBAR def\necho a new line\nX*$/ got: XX/home/root/anilss/AArch64/mksh/mksh: /bin/ed: not found X/home/root/anilss/AArch64/mksh/mksh: <stdin>[3]: s/abc/FOOBAR/: not found XXX/home/root/anilss/AArch64/mksh/mksh: <stdin>[6]: .: missing argument X/home/root/anilss/AArch64/mksh/mksh: <stdin>[7]: w: not found X/home/root/anilss/AArch64/mksh/mksh: <stdin>[8]: q: not found XX [incomplete last line] pass ./check.t:IFS-space-1 pass ./check.t:IFS-colon-1 . . . pass ./check.t:command-shift pass ./check.t:duffs-device Total failed: 5 (4 ignored) (1 unexpected) Total passed: 431 root@genericarmv8:~/anilss/AArch64/mksh# --------------------------------------------------------------------------------------------------------------------------------------------
Best Regards, Anil
On 6 October 2013 02:31, Neil Williams neil.williams@linaro.org wrote:
On 5 October 2013 08:13, Anil Singhar anil.singhar@linaro.org wrote:
Hi Neil / Riku / Peter,
Thanks for your help.
Now that I have some confidence that the changes are working fine
Well done!
, is it possible for one of you to review the code..? Or could you suggest
someone
who could do that for me. The code is available at: ( git clone git://git.linaro.org/people/anil.singhar/klibc-aarch64.git )
Have you been able to run the mksh tests? Do you have results available somewhere? I never got to that stage.
I would like to implement review feedback and make it available for upstreaming this week.
Upstream will insist on seeing the test results, I'm afraid. (So rather than using the linaro.org pastebin, it would be best to put the results in your public_html directory on people.linaro.org)
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On 7 October 2013 13:08, Anil Singhar anil.singhar@linaro.org wrote:
Hi Neil,
Thanks for your response. I prepared the mksh test and ran them. There were 5 failures (out of the 436 tests) as follows.
Well done! 4 of those 5 are listed in the output as ignored.
Right now, I don't know if these are failures due to klibc implementation or due to problems with the way I have build mksh itself. To some extent I suspect mksh as well because (i) I could not get mksh_44 (from this link: dget http://ftp.de.debian.org/debian/pool/main/m/mksh/mksh_44-1.dsc , the link seems to be broken)
Since I started on this (and got that link), mksh has been updated. You can get 44-1.dsc from snapshot.debian.org:
http://snapshot.debian.org/archive/debian/20130305T212453Z/pool/main/m/mksh/...
but I used whatever I got ( mksh_44.orig.tar.gz , this may be missing some patches, how to get that.. ).(ii) While building mksh, encountered some compiler errors (e.g. conftest.c) but the building seemed to go fine despite these errors, so I went ahead with testing and ended up with 5 failures out of which mksh ignores 4 and didn't expect 1 as it reports.
So, do you have any idea if I am doing the right thing..?
I think you've done the right thing.
Should I worry about getting mksh build without any compiler error or warning first before attempting to use the tests..?
Compare with the Debian build log for 44-1: https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=amd64&ver=4...
There's a different failure there.
I think this is ready to take to klibc upstream, let them decide on the mksh test results.
Thanks a lot..Neil, let me try the new mksh and see how it goes.
Best Regards, Anil
On 8 October 2013 13:46, Neil Williams neil.williams@linaro.org wrote:
On 7 October 2013 13:08, Anil Singhar anil.singhar@linaro.org wrote:
Hi Neil,
Thanks for your response. I prepared the mksh test and ran them. There
were
5 failures (out of the 436 tests) as follows.
Well done! 4 of those 5 are listed in the output as ignored.
Right now, I don't know if these are failures due to klibc implementation or due to problems with
the
way I have build mksh itself. To some extent I suspect mksh as well
because
(i) I could not get mksh_44 (from this link: dget http://ftp.de.debian.org/debian/pool/main/m/mksh/mksh_44-1.dsc , the
link
seems to be broken)
Since I started on this (and got that link), mksh has been updated. You can get 44-1.dsc from snapshot.debian.org:
http://snapshot.debian.org/archive/debian/20130305T212453Z/pool/main/m/mksh/...
but I used whatever I got ( mksh_44.orig.tar.gz , this may be missing some patches, how to get that.. ).(ii) While building
mksh,
encountered some compiler errors (e.g. conftest.c) but the building
seemed
to go fine despite these errors, so I went ahead with testing and ended
up
with 5 failures out of which mksh ignores 4 and didn't expect 1 as it reports.
So, do you have any idea if I am doing the right thing..?
I think you've done the right thing.
Should I worry about getting mksh build without any compiler error or warning first
before
attempting to use the tests..?
Compare with the Debian build log for 44-1:
https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=amd64&ver=4...
There's a different failure there.
I think this is ready to take to klibc upstream, let them decide on the mksh test results.
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On Tue, Oct 08, 2013 at 09:16:00AM +0100, Neil Williams wrote:
I think this is ready to take to klibc upstream, let them decide on the mksh test results.
This touches a fair bit of architecture independent code, changing how stat works (or doesn't). Have you tried building this on any arch other than aarch64? It fails fairly miserably.
... Adam
Hi Adam,
I have uploaded one change that should fix the build issue resulting from stat definition. I have tested this on aarch64 and x86_64.
Thanks, Anil
On 13 October 2013 20:41, Adam Conrad adconrad@0c3.net wrote:
On Tue, Oct 08, 2013 at 09:16:00AM +0100, Neil Williams wrote:
I think this is ready to take to klibc upstream, let them decide on the mksh test results.
This touches a fair bit of architecture independent code, changing how stat works (or doesn't). Have you tried building this on any arch other than aarch64? It fails fairly miserably.
... Adam
-
Adam Conrad -
Anil Singhar -
Neil Williams -
Peter Maydell -
Riku Voipio