IRC logs for #baserock for Thursday, 2015-12-24

*** gtristan has joined #baserock05:06
*** ssam2 has joined #baserock09:10
*** ChanServ sets mode: +v ssam209:10
gtristanhmmm10:07
* gtristan discovers http://sentryytech.blogspot.kr/2013/02/faster-compiling-on-emulated-raspberry.html10:07
gtristanmaybe I can try that10:07
gtristan"architectural chroot"10:08
paulsherwoodSpoiler alert: Emulating a Raspberry Pi using QEMU is slow.10:10
paulsherwoodhe says the architectural chroot is much faster, but not precisely how much faster10:12
gtristanI presume it depends on your host CPU10:13
gtristan"This registers the static QEMU we copied as arm-interpreter to the kernel"10:14
gtristanI'm thinking, its not *really* emulating the system, but only interpreting the instructions10:14
gtristanworth a try anyway10:14
paulsherwoodthe original link he refers to has gone, but https://gist.github.com/mikkeloscar/a85b08881c437795c1b910:19
gtristanyeah10:20
gtristanI had to go running in circles just to find a kernel / raspbian image which booted10:20
gtristanlots of broken links out there10:21
paulsherwoodwouldn't the same approach work with a baserock arm image?10:21
* gtristan has followed these instructions: http://paulscott.co.za/blog/full-raspberry-pi-raspbian-emulation-with-qemu/ ... but had to find the correct image/kernel as those links also broken10:22
gtristanpaulsherwood, sure, I just didnt know where to get one :)10:22
paulsherwoodhttp://wiki.baserock.org/download/ ?10:23
gtristanaha, I was familiar with the image in the 'getting started' page only10:23
ssam2so "architectural chroot" is basically what i called "the Scratchbox approach"10:25
ssam2i.e. using binfmt_misc10:26
gtristanssam2, right, I wouldnt call any of the virtualizations "cross compiling"10:26
gtristanssam2, anyway this is more of an exploration/research, not a statement that I think baserock should be cross compiling :)10:27
paulsherwoodgtristan: i think the research is very useful... it's currently reinforcing my belief that cross is the wrong way to go, though :)10:28
gtristanme too, I did vaguely recall that you always needed the host / target paths, but looking closer at what buildroot is doing and it's patches and module makefiles is enlightening: it's a lot of work10:30
paulsherwoodplus a lot of *ongoing* work to change versions of things, iiuc10:36
ssam2buildroot is quite a good place to analyse how much friction the cross compile patches actually generate10:47
ssam2because everything happens in this one repo: https://git.buildroot.org/buildroot/log/10:48
radiofreeregarding qiu's probably from last night, looks like it should get the SPL entry when you *build* (i.e using their scripts), which we don't do (we've already built u-boot as part of baserock)10:56
*** gtristan has quit IRC10:57
radiofreefor now we could change the instructions to say "use commit b54bdc46b51ecb0971aa495b0fdd5ef884ccd48d (https://github.com/NVIDIA/tegra-uboot-flasher-scripts/commit/b54bdc46b51ecb0971aa495b0fdd5ef884ccd48d)"10:57
radiofreealthough it might be easier to manually create the "u-boot-spl-entry" file needed when running the script10:58
radiofreewhich is 0x80108000 for the jetson tk1 (ram-base + 0x00108000)11:00
*** edcragg has joined #baserock11:22
*** gtristan has joined #baserock11:22
paulsherwoodssam2: could you summarise the similarities/differences between that repo and definitions?11:26
paulsherwood(eg, is buildroot.git representing more/less systems/components/architectures... what's their approach vs tracking upstream etc)11:27
ssam2in terms of components: each dir in packages/ is roughly 1 component: https://git.buildroot.org/buildroot/tree/package11:35
ssam2but buildroot is all stuff for embedded devices, there's no GNOME or OpenStack stuff11:35
ssam2so, numbers are maybe similar but different focus11:36
paulsherwoodack11:36
ssam2in terms of architectures: https://git.buildroot.org/buildroot/tree/arch11:36
paulsherwoodsloccount doesn't begin to describe the effort in this kind of project11:36
ssam2so, 14 different architectures or so :-)11:37
paulsherwoodplus be and le :)11:38
ssam2and for boards, https://git.buildroot.org/buildroot/tree/board has lots of files, but it's not really got a cohesive structure11:38
ssam2for some boards there is just a README, for some there are flashing scripts, or specific configs... it's all ad-hoc much like our board support11:39
ssam2yes, sloccount gives one measure, but really the number of possible combinations is significant11:39
ssam2and the number of combinations that are regularly used and tested11:39
radiofreeok jetson flashing should work again now https://gitlab.com/jamesthomas/baserock-flashing-tools/commit/688e17d00caf627e128a580ee5ee57732f817de811:40
ssam2for tracking upstream their approach is "just do it", I think11:40
ssam2the most trivial update looks like this: https://git.buildroot.org/buildroot/commit/?id=44859e68cc52e31eb569ed0a108db156d678f19811:41
ssam2i would imagine people who do a lot of those have automated the process somehow11:41
ssam2but I don't think the project has a formal effort to automatically update things11:42
ssam2radiofree: 2 line fix, nice :-)11:43
paulsherwoodhow does radiofree's fix get to baserock users? that repo doesn't appear to be at gbo?11:48
radiofreepaulsherwood: the instructions say "clone from that repo"11:48
radiofreemaybe should also instruct to "if you already have the script, git pull"11:48
paulsherwoodon the wiki?11:49
radiofreeyes11:49
radiofreei seem to remember it not being considered for gbo because it's crap11:49
paulsherwoodif it works, how can it be crap?11:49
radiofreewell it's not very elegant, there's things like https://gitlab.com/jamesthomas/baserock-flashing-tools/commit/e41f77a2de421ffaa9156807b9b255eebf762acb11:50
radiofreemaybe if it had more flashing scripts it would be useful (the idea was you'd "drop in" your board script and implement the required functions for the board)11:50
radiofreei had one for a wandboard for example11:50
ssam2the original discussion is here, if you want to relive the fun times: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-December/009978.html11:51
radiofreewhat's the policy in baserock for upgrading bsp's to -rc kernels?11:55
ssam2depends who you ask11:55
paulsherwoodlol11:56
paulsherwoodcould/should the flasher scripts go into definitions/scripts, irrespective of how 'elegant' they are?11:59
radiofree:_12:00
radiofreessam2: :D12:00
paulsherwoodradiofree: does that mean you wouldn't want them there?12:01
paulsherwoodwrt -rc kernels... if the expectation is that they work as well or better, i would hope folks would be happy to +112:01
radiofreepaulsherwood: i don't mind either way, i can fix all of richards suggestions and resubmit12:02
* paulsherwood thinks definitions would make more sense than a separate repo (easier for users to grok)....12:03
paulsherwoodssam2: any objection?12:06
ssam2no, i think it makes sense to keep it in there12:17
ssam2in definitions/scripts, I mean12:17
radiofreethat's nice, weston/egl working on upstream 4.4-rc6, no out of tree anything required now14:16
radiofreehowever you do have to flash a new version of u-boot (still u-boot upstream, just a more recent version)14:16
radiofreenothing Qt works... let's try mesa14:29
radiofreeaye that works http://seriousinternetbusiness.com/james/vids/weston-4.4.mp415:32
*** ssam2 has quit IRC17:21

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!