TEXT   21

arm m ael alip evaluation

Guest on 28th May 2022 03:01:51 PM

  1. AEL/ALIP evaluation
  2.  
  3. Agenda:
  4. * AEL/ALIP introduction
  5. * Discussion
  6.  * use-cases
  7.  * procedures
  8.  * delivery formats
  9.  * cross compiling
  10.  
  11. === AEL information and resources ===
  12.  
  13.   * http://www.arm.com/linux
  14.  
  15. === ALIP Information and Resources ===
  16.  
  17.   * http://linux.onarm.com/index.php/Main_Page
  18.  
  19. === Discussion ===
  20.  
  21. Packages and filesystem
  22.  * When pulling updates into ALIP, generally choose the latest upstream versions
  23.  * Filesystem tarballs distributed per architecture baseline
  24.   * ARMv5
  25.   * ARMv6
  26.   * ARMv7 +NEON
  27.   * ARMv7 +-Thumb2 +NEON
  28.   * Generally, compiler options enable as many processor features as possible.
  29.      -> this is an explicit intention to exercise build scenarios and processor features
  30.   * System is flexible so the user can do a build with the right compiler options to target their use case / platform.
  31.   * about 200 packages
  32.   * Don't necessarily need to produce builds for all possible scenarios - this can be left to the user if they have specific requirements
  33.    
  34. Packaging
  35.   * Git repository based on upstream
  36.   * Some arm-specific patches held in git - but these are proactively pushed
  37.     upstream also.
  38.   * The AEL kernel typically contains some patches which are unlikely to be merged upstream.
  39.  
  40. Do people really need to rebuild everything?
  41.   * People find the flexibility useful
  42.   * If the user cannot rebuild, they are restricted with the common subset of the architecture.
  43.   * In debian packages, copmiler options are often overridden during the build process, making it difficult to do a clean build with user-specified options
  44.   * Currently the default compiler flags are set in the toolchain scratchbox
  45.   * Currently, different compilers are used - gcc , armcc (RVCT).
  46.   * Supporting multiple toolchains can create packaging complications e.g., dependencies on libgcc don't make sense between different toolchains.  Proper dependencies are needed if we want to use the Debian/Ubuntu tools to construct filesystems.
  47.   * Build-dependencies can be addressed by a static chroot which provides the functionality of build-essential.
  48.   * An options is to base off Debian source packages, without using prebuild binary packages.
  49.   * Info on switching toolchains in scratchbox: http://www.scratchbox.org/wiki/ForeignToolchains
  50.   * A service for building packages (such as Ubuntu PPAs) is conceivable as a way to simplify life for users/developers, but not a priority for now?
  51.  
  52. Testsuites
  53.   * Can consider running build-time tests ("make check") but not currently done by default.  Does not work with true cross-compiling.
  54.  
  55. Use cases:
  56.  * rootfs for different architectures to do validation/testing/demoes/benchmarks
  57.    - armv5
  58.    - armv6
  59.    - armv7 neon
  60.    - armv7 thumb2 neon
  61.    - uclinux and eglibc versions for armv6 onwards
  62.  * contains ~200 packages to provide a small minimum demo image
  63.  * need to allow rebuild of the rootfs for different architecture opts
  64.    - 4 hours to rebuild ~200 packages in QEMU on a desktop PC
  65.  * set of packages hosted in git repos:
  66.    - light: busybox for the small fs use case; our busybox would need a new flav
  67. or based on uclinux
  68.    - medium: xserver/x11 test environment
  69.    - full: allows running a browser, webkit or mozilla, gtk or qt; need to provi
  70. de both of them
  71.  * packages have patches which are being pushed upstream
  72.  * rebuild with different compiler or compiler flags
  73.  * in practice, it's hard to support uClinux without a different toolchain (though it's possible in principle); it might be possible for the prebuilt images, but needs to be investigated
  74.  * Should be really easy and really solid as to allow newbies to do rebuilds
  75.  * A key problem is in package dependencies with outside toolchains: when building with armcc, we want packages to pickup dependencies on the toolchain runtime libs
  76.    - We need to take the assumption that the armcc toolchain is packaged
  77.  * ARM did a Debian rebuild using armcc; it would be highly interesting to know how they solved that; Will Deacon to check this out  :-)
  78.  * We want to be able to test with new toolchains
  79.    - We need to take the assumption that the armcc toolchain is packaged
  80.  
  81.  * Problems:
  82.    * packaging and updating to new major toolchain is hard to do
  83.    * building with armcc might require packages - binaries only is OK -> not trying to solve the toolchain bootstrapping problem
  84.  
  85. === Actions ===
  86.  * Will Deacon to get details on the ARM internal Debian build using armcc
  87.  * Ubuntu folks to try out ALIP!  :-)  arm.com/linux

Raw Paste


Login or Register to edit or fork this paste. It's free.