Project

General

Profile

TestingInfrastructure » History » Revision 54

Revision 53 (Denis 'GNUtoo' Carikli, 03/31/2022 01:40 PM) → Revision 54/55 (Denis 'GNUtoo' Carikli, 04/27/2022 02:10 AM)

{{<toc}} 

 h1. TestingInfrastructure 

 h2. Applications that can be used to do some testing on the device 

 * https://f-droid.org/wiki/page/org.zeroxlab.zeroxbenchmark 

 h2. Projects and/or hardware that can be used to do functional testing 

 h3. Lava 

 "Lava":https://www.linaro.org/engineering/projects/lava/ can be used to do functional tests on real hardware. It can be easily installed on PureOS, an FSDG compliant GNU/Linux distribution. 

 h3. Labgrid 

 "Labgrid":https://labgrid.readthedocs.io/en/latest/ has features similar to Lava but it is probably easier to learn because it's probably way easier to get started with it. 

 h3. OsmoGSMTester 

 The "OsmoGSMTester project":https://osmocom.org/projects/osmo-gsm-tester is able to be interfaced with the Android RIL through ofono and can emulate a GSM network with the help of a compatible GSM base station or SDR. 


 This "presentation from 2019":https://media.ccc.de/v/osmodevcon2019-119-osmo-gsm-tester-e-gprs-test-setup has many insights on what kind of issue we might expect in interfacing it with smartphones. 

 h3. Simtrace2 

 The "Simtrace 2 project":https://osmocom.org/projects/simtrace2/wiki can be used, along with SIM card readers to programmatically feed a SIM card to a smartphone. This can be used to run test on real networks. 

 h2. Replicant supported devices and testing 

 h3. Requirements 

 * Antenna connector for the modem 
 * The ability to control the device buttons in order to be able to programmatically power on and off the device, and trigger boots into the bootloader and recovery 
 * Optionally a way to connect to the serial port, programmatically 

 h3. Galaxy SII (GT-I9100) 

 * The Galaxy SII (GT-I9100) has: 
 ** An antenna connector. According to the "External Antenna Socket - WARNING forum thread on XDA":https://forum.xda-developers.com/t/external-antenna-socket-warning.1273292/page-6 , it's an MS-162 
 ** The SOC serial port that is accessible behind the USB connector at a low voltage 
 ** A full size mini-sim (easier to interface with) 

 Holding the smartphone in place: 
 * The smartphone could either be screwed on a metallic surface or an external case could be screwed on a metallic surface enabling the smartphone not to move. 

 SIM cards: 
 * Simtrace and Simtrace 2 both "lacks screw holes":https://osmocom.org/issues/3711 so a way must be found to make sure that it doesn't move as it uses flex cables to interface with the SIM socket of the smartphone. That may be fixed in a subsequent hardware revision. 

 Serial port and USB: 

 Buttons: 

 Battery: 

 Antenna connector and GSM tower or SDR: 
 The Galaxy SII (GT-I9100) has two antenna connectors: 
 * One internal connector, TODO: find the connector type 
 * One external connector, TODO: Find the connector type 

 h4. Example setup 

 See also the links inside the [[Serial_port]] article for more background on how to get serial port access on devices like the Galaxy SIII (GT-I9300) or the Galaxy SII (GT-I9100). 

 !i9100.jpg! 

 See https://git.replicant.us/contrib/GNUtoo/test-infrastructure.git for the source of the file. 

 h4. Using a device without a battery. 

 * "How to use a Galaxy SIII without a battery":https://techblog.jeppson.org/2017/12/revive-old-samsung-galaxy-s3/ : It doesn't look very safe to do that as the phone is probably not expecting 5V on the battery connector but it gives some idea of the peak tolerances. 

 * The Galaxy SIII 4G (GT-I9305) could probably work at lower voltages like 3.3V through the battery connector, but it would require testing it. In that case it might also be a good idea to test it in all configurations (all hardware features being used, cpuburn etc). 

 * The 4 pin 'FPC' style battery connector available from amazon, marketed as being for the 'S4 value edition i9515' (https://amazon.de/gp/product/B0813JBW8S) is capable of contacting the Galaxy SIII (GT-I9300)'s battery. 

 h4. Sumarry  

 | Device                    | Modem antenna connector | Compatible software         | Comments                                                                                                    |                          
 | Motorolla C155            | MS-147                    | * OsmocomBB 
                                                       * Old Nuttx revisions       | Could be used as reference phone as it's probably already supported by the Osmocom testing infrastructure | 
 | Galaxy SII (GT-I9100)     | MS-162                    | * Replicant 4.0, 4.2, 6.0 
                                                      * Upstream Linux (partial) | 
 | Galaxy Nexus (GT-I9250) | ?                         | * Replicant 4.0, 4.2, 6.0 | We can get some GSM traces in wireshark with xgoldmon                                                       | 
 | Galaxy SIII (GT-I9300)    | ?                         | * Replicant 4.0, 4.2, 6.0 
                                                      * Upstream Linux (partial) | 

 h2. USB modems 

 When [[XMMProtocolInterfaces|trying to enable protocol tracing in modems]] we can connect the device modem (somewhat directly) to a laptop 

 Questions: 
 * Do we have samsung-ipc on top of the virtual UARTs? 
 * The cbd daemon mentioned "in the blog post about booting the Galaxy S7 modem":https://eighty-twenty.org/2020/09/10/booting-samsung-galaxy-s7-modem    doesn't list UART as main link though. 
 * Adding the modem USB id when in debug mode (1519:0020) in a search engine shows various usb keys 
 * Do phones like the Galaxy SII have smasung-ipc on top of the USB link or UART links when in debug mode? 

 h2. Pure software setup 

 

 h3. lightweight test infrastructure for libsamsung-ipc 

 It might be possible to have a pure software test infrastructure with libsamsung-ipc. 

 It could be done more or less like that: 

 test script <-> ipc-modem or other programs <-> libsamsung-ipc <-> Linux kernel <-> VHCI <-> software sending USB packets 

 We have several choices for the Linux kernel: 

 | Kernels                     | Comments | 
 | User mode Linux (ARCH=um) | + Very lightweight, runs completely in userspace 
                               + Very simple setup. Probably works on armv7 too without dedicated hardware like Intel vt-x 
                                 -Requires 
                               - Requires patches for USB / VHCI- VHCI 
                               - Require dedicated RAM                                                                        | 
 | Linux + libvirt + kvm       | - Require some virtualization setup that requires dedicated RAM  
                               + Probably works unpatched                                                                   | 

 And there is already some projects emulating usb devices: 
 | Project                       | Description                 |     comments                           | 
 | gnuk                          | USB token software          | can build for gnulinux               | 
 | choptix                       | Library used by gnuk        | More simple examples                 | 
 | osmo-ccid-firmware[1][2][3] | CCID emulation              | Probably uses vusb for testing too | 


 fn1. https://git.osmocom.org/osmo-ccid-firmware/tree/ccid_host 

 fn2. https://git.osmocom.org/osmo-ccid-firmware/tree/ccid_host/README.linux-dummy_hcd-ffs 

 fn3. https://media.ccc.de/v/osmodevcon2019-128-osmo-ccid-firmware-libosmocore-talloc-on-uc-usb-testing-from-ttcn-3 

 So it might be possible to modify them to send some simple USB packets captured with wireshark / tshark / tcpdump. 

 h4. user mode Linux 

 I've already managed to find a configuration that works in an FSDG compliant way: 
 | Settings                                                                        | Status             | 
 | *kernel*: kernel_replicant_linux  
   *commit*: 843565d21f78 [WIP] ARM: dts: exynos: Add reboot modes to midas 
   *compilation settings*: ARCH=um 
   *Host architecture*: x86_64 
   *kernel defconfig*: x86_64_defconfig 
   *Target Distribution*: Parabola x86_64 
   *commandline arguments*: ./linux mem=2047M ubd0=parabola.img root=/dev/ubda1    | Boots fine            | 
 | *kernel*: kernel_replicant_linux 
   *commit*: 063228e445e2 net: sipc: core: fix code style 
   *compilation settings*: ARCH=um 
   *Host architecture*: i686 
   *kernel defconfig*: i386_defconfig                                              | Fails to compile[1] | 
 | *kernel*: linux 
   *commit*: f1baf68e1383 Merge tag 'net-5.17-rc4' of [...]kernel/git/netdev/net 
   *compilation settings*: ARCH=um 
   *Host architecture*: x86_64 
   *kernel defconfig*: i386_defconfig                                              | Boots fine            | 
 | *Target Distribution*: Replicant 11 
   *Build command*: source build/envsetup.sh && lunch uml-userdebug && make dist 
   *kernel*: ? 
   *kernel defconfig*: ?                                                           | Fails to compile[2] | 

 fn1. <pre> 
   CC        arch/x86/um/user-offsets.s 
 cc1: error: code model ‘large’ not supported in the 32 bit mode 
 cc1: sorry, unimplemented: 64-bit mode not compiled in 
 make[1]: *** [scripts/Makefile.build:117: arch/x86/um/user-offsets.s] Error 1 
 make: *** [arch/um/Makefile:118: archprepare] Error 2 
 </pre> 

 fn2. <pre>[ 52% 179/339] including external/mesa3d/Android.mk ... 
 FAILED:  
 In file included from build/make/core/prebuilt.mk:53: 
 In file included from external/mesa3d/Android.mk:124: 
 In file included from external/mesa3d/src/mesa/Android.mk:23: 
 external/mesa3d/src/mesa/Android.libmesa_glsl_utils.mk:74: error: BUILD_HOST_STATIC_LIBRARY is obsolete. Please convert to Soong. 
 12:25:14 ckati failed with: exit status 1 

 #### failed to build some targets (02:04 (mm:ss)) #### 
 </pre> 

 h5. Booting Parabola 

 To run Parabola first you need to create an image. 
 Then you need to chroot (with arch-chroot) insde the image and change the password. 
 Once you exited the chroot and unmounted the image and removed the loop mapping, you can boot it. 

 During boot you'll see a message like that at the end: 
 <pre> 
 Virtual console 1 assigned device '/dev/pts/4' 
 </pre> 

 You can then login in this way: 
 <pre> 
 $ sudo picocom /dev/pts/4  
 picocom v3.1 

 port is          : /dev/pts/4 
 flowcontrol      : none 
 baudrate is      : 9600 
 parity is        : none 
 databits are     : 8 
 stopbits are     : 1 
 escape is        : C-a 
 local echo is    : no 
 noinit is        : no 
 noreset is       : no 
 hangup is        : no 
 nolock is        : no 
 send_cmd is      : sz -vv 
 receive_cmd is : rz -vv -E 
 imap is          :  
 omap is          :  
 emap is          : crcrlf,delbs, 
 logfile is       : none 
 initstring       : none 
 exit_after is    : not set 
 exit is          : no 

 Type [C-a] [C-h] to see available commands 
 Terminal ready 

 parabola login: root 
 Password:  
 [root@parabola ~]# cat /etc/os-release  
 NAME="Parabola" 
 PRETTY_NAME="Parabola GNU/Linux-libre" 
 ID=parabola 
 ID_LIKE=arch 
 BUILD_ID=rolling 
 ANSI_COLOR="1;35" 
 HOME_URL="https://www.parabola.nu/" 
 DOCUMENTATION_URL="https://wiki.parabola.nu/" 
 SUPPORT_URL="irc://chat.freenode.net#parabola" 
 BUG_REPORT_URL="https://labs.parabola.nu/" 
 LOGO=parabola 
 [root@parabola ~]#  
 </pre> 

 h5. network support 

 With @vec0:transport=raw,ifname=p-veth0,depth=128,gro=1@ in Linux command line, we can have a regular Ethernet interface that can be configured as usual, bridges also work. 

 See the kernel documentation (user_mode_linux_howto_v2.rst) for more details on how to setup UML networking. 

 h5. USB support 

 With Linux 5.17-rc3 it's possible to have USB in user-mode-linux and I validated it by exporting an rtl_sdr with usbip and testing the receiving of FM with rtl_fm -f 88M | hexdump -C. 

 It seems to be there since Linux 5.14 since this commit: 
   68f5d3f3b654 um: add PCI over virtio emulation driver 

 Unfortunately we use Linux 5.10.70 in replicant 11 right now. 

 h5. User Mode Linux TODO 

 * We probably need to make i686 and armv7 to work too. 
 * -We We need to find and port the USB patches on top of kernel_replicant_linux 
 * We also need to setup USB somehow with vhci_hcd and so on- on 
 * We need to make USB work with Replicant 11 kernel or upgrade the Replicant 11 kernel. 
 * We still need to find a very simple stack to send URBs. 
 * We then need to test it for real, see if we can collect kernel crashes in this way and so on.