linaro-validation January 2012

linaro-validation@lists.linaro.org

11 participants
5 discussions

by Zygmunt Krynicki

Hi guys. This is just a note, perhaps we'll be able to go down this route (eventually) perhaps it will never be viable. SD cards are utter crap. USB disks are fantastic. I'm currently recovering my home server that died yesterday night due to a bad SD card. Luckily I kept the image as l-m-c would crash attempting to write it to my SD card adapter. Now I'm just finishing the final configuration bits (sadly those parts were lost with that card) and came to realize how painless and efficient a simple USB disk is. Would it be possible to change our deployment to use SD _just_ to store a recovery uboot and recovery kernel? Could we try to stick the master rootfs and test rootfs (and all those android partitions) directly on the HDD? PS: Apart from just working, it seems that current kernels have a big issue with very slow storage (like thumb drives and sd cards) and transparent huge tables. I cannot say it is directly the case on my iMX53 but "idle" system load on a regular SD card was around 4-5 (writing to syslog, keeping up with small squid traffic of my home users) while the same system, with the same set of services on a run off the mill 2.5" HDD can barely climb above 0.5. Best regards ZK

12 years, 11 months

Linaro kernel tree for A15 for daily builds

by Zygmunt Krynicki

HI. I'm building a LAVA service for running fast models. Quite soon (*) we'll be ready to open an alpha access. Right now you will need to bring your own root filesystem and kernel image to use it. With that in mind I wanted to start a discussion about the state of A15 support in Linaro kernel(s). I need to understand two things: 1) Are we ready to do automatic builds for A15 kernels? 2) If so, which configs and trees should we consider Thanks Zygmunt Krynicki

12 years, 11 months

On a possible fuse of the scheduler and dashboard?

by Zygmunt Krynicki

Hi. This a brainstorm message. I'd like to hear your pros and cons on merging the scheduler and dashboard. For me the advantages outweigh the disadvantages: Pros: * A simple model for tracking a result back to a job, without having to jump through javascript hoops and hard synchronization/availability issues (and back!) * A stronger case that lava-{dashboard,scheduler} has all the key models - devices, tests, results - all in one place. Easier for extension developers to target as their backend. * Less fuss for extension developers that don't really consider the implications of this distributed system * Easier workflow, one less component to release ;-) * We get to clean up dashboard_app and rename it to lava-* Cons: * We may need to do a flag day when we have one big migration that will rename tables, etc * This will break sql-based reports (but I don't think that we really care about them anymore) * I'm not sure what we'd do with the lava-dashboard, lava-scheduler projects on launchpad PS: We could move this a step forward and consider merging with lava-server (at the source code repo level) where we''d have clear separation from the core (server,scheduler,dashboard) and extensions that build on the core. Thanks ZK

12 years, 11 months

On top-level API (lava.something) and namespace packages

by Zygmunt Krynicki

For the past few weeks I've been consistently using namespace packages (like zope does if you are familiar with that) to streamline LAVA APIs. From the end user's point of view there is no difference, for developers it is a bit easier as everything comes from a nested lava package, like this: >>> from lava.serial.console import xxx >>> from lava.utils.data_tables.backends import ... Technically this means that any python package (thing with a setup.py file) can add modules to a shared "lava" namespace. Currently I've setup two namespaces: lava. and lava.utils. Eventually I'd like to move each lava module there (after a grace period, with possible eternal backwards compatibility modules). Unless there is a strong voice against adopting this pattern across all new code I'd like to request this to be the standard way of writing new modules. For some tips/guides on how to do this please refer to the following resources: [1], [2], [3], also, you can look at lava-serial and lava-server (the new parts) [1]: http://stackoverflow.com/questions/1675734/how-do-i-create-a-namespace-pack… [2]: http://www.python.org/dev/peps/pep-0382/ [3]: http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages Thanks ZK

12 years, 11 months

Fast model issues and progress

by Zygmunt Krynicki

Hi folks This is my first public mail to our own validation mailing list ;-). I'm CCing a few people that could be interested in this topic. Now to the topic at hand. I'm trying to make it possible to use fast models (in any way) by the end of this week. I'm tracking this blueprint [1] but right now it is just an empty shell as I'm still wrapping my head around this. A few observations so far: 1) Running a fast model on a 32bit VM is not practical, it seems to crash after a few / dozen minutes due to insufficient address space 2) I still have not managed to get autologin to work. This is mildly annoying but should be possible to get over. 3) A poweroff in the machine causes kernel panic 4) A reboot in the machine seems to just hang and do nothing 5) After much tinkering (installing additional packages, etc, etc) I managed to run stream, I've attached the bundle if anyone is interested. 6) If you need to modify the rootfs in any way it is about 10x faster to do it via chroot + qemu than to run the fast model (on core i7) 7) The system boots with nfsroot, the IP of the server and the directory to mount is burned in the .axf file 8) An axf file is created from a kernel image and some other bits that I don't yet understand. It seems that boot-wrapper is a kind of bootloader for linux in the fast model. I've found at least two sources for that [2] (from the wiki page by Peter Maydell) and [3] (from Michael Hope) 9) I'm not at all sure why we need to cross compile qemu for arm (as instructed in [4]) - is this so that we can test visualization support in a15? 10) The instructions did miss a few things and I had to run apt-get -f install / install extra cross packages. In the end I'm not sure how much of this is only required to build qemu, how much is required to build the rootfs and how much is required to build the kernel. It seems to be too messy ATM, I'd like to split this into separate problems that could be automated with standalone scripts we could fire in a VM or chroot (so that we are sure we got the dependencies right and everything really works fine) 11) I'm not at all sure what's the difference between model_shell's terminal_[0123] and uart[0123]. That is, I'd like to know what those options do with a little bit more precision. Looking at the pdfs that came with the program did not help. The major roadblock: *) I'm still trying to parametrize the kernel command line. There seem to be a few possible ways to do it. One based on just rebuilding the axf file (longest/ugilest), one on changing the boot-wrapper bootloader to accept some extra data at the end and pass that down to the kernel (not my specialty, could take a moment to get to work), looking at model_shell -l output it seems there is a way to pass something known as 'cluster.cpu0.semihosting-cmd_line='. Perhaps that could be used to put some data that the kernel can read at runtime. That's it. Keep fighting ZK [1]: https://blueprints.launchpad.net/lava-dispatcher/+spec/lava-fast-model-clie… [2]: git://git.ncl.cs.columbia.edu/pub/git/boot-wrapper [3]: https://github.com/virtualopensystems/boot-wrapper [4]: https://wiki.linaro.org/PeterMaydell/A15OnFastModels#Cross_compile_QEMU

12 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation January 2012