*** gtristan has joined #baserock | 05:06 | |
*** ssam2 has joined #baserock | 09:10 | |
*** ChanServ sets mode: +v ssam2 | 09:10 | |
gtristan | hmmm | 10:07 |
---|---|---|
* gtristan discovers http://sentryytech.blogspot.kr/2013/02/faster-compiling-on-emulated-raspberry.html | 10:07 | |
gtristan | maybe I can try that | 10:07 |
gtristan | "architectural chroot" | 10:08 |
paulsherwood | Spoiler alert: Emulating a Raspberry Pi using QEMU is slow. | 10:10 |
paulsherwood | he says the architectural chroot is much faster, but not precisely how much faster | 10:12 |
gtristan | I presume it depends on your host CPU | 10:13 |
gtristan | "This registers the static QEMU we copied as arm-interpreter to the kernel" | 10:14 |
gtristan | I'm thinking, its not *really* emulating the system, but only interpreting the instructions | 10:14 |
gtristan | worth a try anyway | 10:14 |
paulsherwood | the original link he refers to has gone, but https://gist.github.com/mikkeloscar/a85b08881c437795c1b9 | 10:19 |
gtristan | yeah | 10:20 |
gtristan | I had to go running in circles just to find a kernel / raspbian image which booted | 10:20 |
gtristan | lots of broken links out there | 10:21 |
paulsherwood | wouldn'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 broken | 10:22 | |
gtristan | paulsherwood, sure, I just didnt know where to get one :) | 10:22 |
paulsherwood | http://wiki.baserock.org/download/ ? | 10:23 |
gtristan | aha, I was familiar with the image in the 'getting started' page only | 10:23 |
ssam2 | so "architectural chroot" is basically what i called "the Scratchbox approach" | 10:25 |
ssam2 | i.e. using binfmt_misc | 10:26 |
gtristan | ssam2, right, I wouldnt call any of the virtualizations "cross compiling" | 10:26 |
gtristan | ssam2, anyway this is more of an exploration/research, not a statement that I think baserock should be cross compiling :) | 10:27 |
paulsherwood | gtristan: i think the research is very useful... it's currently reinforcing my belief that cross is the wrong way to go, though :) | 10:28 |
gtristan | me 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 work | 10:30 |
paulsherwood | plus a lot of *ongoing* work to change versions of things, iiuc | 10:36 |
ssam2 | buildroot is quite a good place to analyse how much friction the cross compile patches actually generate | 10:47 |
ssam2 | because everything happens in this one repo: https://git.buildroot.org/buildroot/log/ | 10:48 |
radiofree | regarding 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 IRC | 10:57 | |
radiofree | for now we could change the instructions to say "use commit b54bdc46b51ecb0971aa495b0fdd5ef884ccd48d (https://github.com/NVIDIA/tegra-uboot-flasher-scripts/commit/b54bdc46b51ecb0971aa495b0fdd5ef884ccd48d)" | 10:57 |
radiofree | although it might be easier to manually create the "u-boot-spl-entry" file needed when running the script | 10:58 |
radiofree | which is 0x80108000 for the jetson tk1 (ram-base + 0x00108000) | 11:00 |
*** edcragg has joined #baserock | 11:22 | |
*** gtristan has joined #baserock | 11:22 | |
paulsherwood | ssam2: 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 |
ssam2 | in terms of components: each dir in packages/ is roughly 1 component: https://git.buildroot.org/buildroot/tree/package | 11:35 |
ssam2 | but buildroot is all stuff for embedded devices, there's no GNOME or OpenStack stuff | 11:35 |
ssam2 | so, numbers are maybe similar but different focus | 11:36 |
paulsherwood | ack | 11:36 |
ssam2 | in terms of architectures: https://git.buildroot.org/buildroot/tree/arch | 11:36 |
paulsherwood | sloccount doesn't begin to describe the effort in this kind of project | 11:36 |
ssam2 | so, 14 different architectures or so :-) | 11:37 |
paulsherwood | plus be and le :) | 11:38 |
ssam2 | and for boards, https://git.buildroot.org/buildroot/tree/board has lots of files, but it's not really got a cohesive structure | 11:38 |
ssam2 | for 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 support | 11:39 |
ssam2 | yes, sloccount gives one measure, but really the number of possible combinations is significant | 11:39 |
ssam2 | and the number of combinations that are regularly used and tested | 11:39 |
radiofree | ok jetson flashing should work again now https://gitlab.com/jamesthomas/baserock-flashing-tools/commit/688e17d00caf627e128a580ee5ee57732f817de8 | 11:40 |
ssam2 | for tracking upstream their approach is "just do it", I think | 11:40 |
ssam2 | the most trivial update looks like this: https://git.buildroot.org/buildroot/commit/?id=44859e68cc52e31eb569ed0a108db156d678f198 | 11:41 |
ssam2 | i would imagine people who do a lot of those have automated the process somehow | 11:41 |
ssam2 | but I don't think the project has a formal effort to automatically update things | 11:42 |
ssam2 | radiofree: 2 line fix, nice :-) | 11:43 |
paulsherwood | how does radiofree's fix get to baserock users? that repo doesn't appear to be at gbo? | 11:48 |
radiofree | paulsherwood: the instructions say "clone from that repo" | 11:48 |
radiofree | maybe should also instruct to "if you already have the script, git pull" | 11:48 |
paulsherwood | on the wiki? | 11:49 |
radiofree | yes | 11:49 |
radiofree | i seem to remember it not being considered for gbo because it's crap | 11:49 |
paulsherwood | if it works, how can it be crap? | 11:49 |
radiofree | well it's not very elegant, there's things like https://gitlab.com/jamesthomas/baserock-flashing-tools/commit/e41f77a2de421ffaa9156807b9b255eebf762acb | 11:50 |
radiofree | maybe 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 |
radiofree | i had one for a wandboard for example | 11:50 |
ssam2 | the original discussion is here, if you want to relive the fun times: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-December/009978.html | 11:51 |
radiofree | what's the policy in baserock for upgrading bsp's to -rc kernels? | 11:55 |
ssam2 | depends who you ask | 11:55 |
paulsherwood | lol | 11:56 |
paulsherwood | could/should the flasher scripts go into definitions/scripts, irrespective of how 'elegant' they are? | 11:59 |
radiofree | :_ | 12:00 |
radiofree | ssam2: :D | 12:00 |
paulsherwood | radiofree: does that mean you wouldn't want them there? | 12:01 |
paulsherwood | wrt -rc kernels... if the expectation is that they work as well or better, i would hope folks would be happy to +1 | 12:01 |
radiofree | paulsherwood: i don't mind either way, i can fix all of richards suggestions and resubmit | 12:02 |
* paulsherwood thinks definitions would make more sense than a separate repo (easier for users to grok).... | 12:03 | |
paulsherwood | ssam2: any objection? | 12:06 |
ssam2 | no, i think it makes sense to keep it in there | 12:17 |
ssam2 | in definitions/scripts, I mean | 12:17 |
radiofree | that's nice, weston/egl working on upstream 4.4-rc6, no out of tree anything required now | 14:16 |
radiofree | however you do have to flash a new version of u-boot (still u-boot upstream, just a more recent version) | 14:16 |
radiofree | nothing Qt works... let's try mesa | 14:29 |
radiofree | aye that works http://seriousinternetbusiness.com/james/vids/weston-4.4.mp4 | 15:32 |
*** ssam2 has quit IRC | 17:21 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!