=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:11] good morning [08:02] hey folls is there any docs other than the trello about the upcoming u-boot changes. I want to try as early as possible for the ODROID-C1. [08:03] mvo, oh, does your uboot-env command need fw_env ? [08:03] longsleep, i'll write it up once we're done [08:04] * ogra_ just noticed the livecd-rootfs upload ... i thought we dont need that with the go tool [08:04] ogra_: ok - is that happening soon? I need to check about the fw_* commands right? [08:04] ogra_: my uboot-go work does not, the current branch is based on fw_setenv/fw_printend [08:05] mvo, i think we should switch over [08:05] ogra_: I can move forward to the native go version, iirc the missing bit was that I need to implement a gettenv for a single var, thats easy to add [08:05] ogra_: sure, I work on this now [08:06] mvo, is the snappy-hub branch the actual branch we buiold the beaglebone snap from ? [08:08] fw_setenv is a different command from setenv, fw_printenv different from printenv right? [08:09] the fw_ ones are userspace commends you run from a running system [08:09] oh [08:09] thats good information thanks :) [08:09] but they are rather buggy ... thois is why https://github.com/mvo5/uboot-go exists ... and i think we'll use that instead [08:10] i see - and where is the stuff stored? Question is what does my u-boot need to load such a file? [08:11] longsleep, here are my notes http://paste.ubuntu.com/11893737/ [08:11] the uboot.env file just sits on the vfat partition next to the empty uEnv.txt file [08:12] ogra_: i see thanks. But the uboot.env needs to be loaded somehow. Do you know what feature that is in u-boot config? [08:12] we merge all env settings into a sinlge file and get rid of the scattered config that spans across multiple ones [08:13] longsleep, see line 9 [08:13] ogra_: super - thanks i think i got it [08:15] getting the exact initial env was a bit tricky ... some env vars get set from dtb values or atags, you need to make sure they are not pre-set in your .env file [08:15] ogra_: my u-boot loads a file called boot.ini - so i guess i could just load the uboot.env from there. [08:15] ogra_: see here: https://github.com/longsleep/snappy-odroidc/blob/master/oem/boot-assets/boot.ini the current script [08:16] what i did was: booting with an empty .env file ... that gets you the dtb or atag values ... then boot with a broken .env file and run printenv in the uboot shell ... [08:16] that printenv with the vars from the first step removed was my base [08:16] and to that i added the vars from snappy-system.txt and uEnv.txt [08:17] (plus "snappy_trial_boot") [08:17] that sounds complicated - these values come from u-boot tree for the particular hardware right? [08:17] yes and i'm not sure they get overwritten if they are inside the enc [08:17] *env [08:18] which is why you should exclude them [08:18] witzh the uboot patch your ini file can be empty [08:18] right [08:18] that is worth a try [08:19] all environment will be read from uboot.env [08:19] assuming my u-boot tree supports CONFIG_ENV_* / checking now [08:19] thats a pretty generic function [08:19] (usually used to write the env to a raw space on the SD or NAND though) [08:19] yeah lots of grep matches [08:20] so that looks good [08:20] great [08:20] so for testing i could just create a uboot.env manually and see if i can boot with only that? [08:20] yeah [08:20] great - let me try that [08:22] ogra_: when looking at your .evn file. Lots of values seem to be not required. Did you check already what can be cleaned up? [08:26] longsleep, no, i actually use the complete default env from uboot up to now ... not sure if we want to clean it up (to not lose any features) [08:29] ogra_: makes sense - at least if loading the .env file undefines already defined stuff [08:29] right [08:30] it is loaded before anyting else so if you wanted you could still put overrides in boot.ini or uEnv.txt (whatever you use) [08:31] depends when the boot.ini is loaded - it is a custom patch from aml doing all kind of stuff .. [08:32] as i said, uboot.env is loaded immediately on startup ... before anything else [08:32] ok === erkules_ is now known as erkules [08:38] well - my u-boot tree does not have CONFIG_ENV_IS_IN_FAT :-/ [08:38] bah [08:38] just checking when this was added [08:38] it muste be really old [08:39] i remember using it years ago on pandabaords [08:39] the tree i have to use is from early 2013 [08:40] (pandaboard went out of production in 2012) [08:40] mhm :) [08:41] you are right - added 2012-03-30 [08:41] so i shoud have it .. [08:41] but the whole file is not there in my tree .. damn! [08:42] this is the commit - just for the record: http://git.denx.de/?p=u-boot.git;a=commit;h=57210c7cc363cf2a2a28010658c7ea67388f8d21 [08:42] well, at least it should be easy to apply [08:43] yes looks easy [09:08] Good morning all; happy Monday, and happy Space Exploration Day! 😃 [09:25] ogra_: http://people.canonical.com/~mvo/tmp/snappy_armhf <- thats a updated version that uses the new native go uboot env handling code, if you have a moment, would be great if you could give it a go (I only tested via unittests so far [09:26] ogra_: next I will do a bit of code cleanup and write code to import files like the existing snappy-system.txt [09:31] you mean on updates ? [09:33] mvo, the file is still sourced by uboot, so with the first "saveenv" the content should show up in the uboot.env ... what we need to make sure is to check it matches the uboot.env content and then empty it (so it doesnt get sourced again) [09:56] well seems like my u-boot created a uboot.env file after saveenv and next boot seems to have loaded it without error [09:57] awesome ! [09:58] you should be able to use tools/mkenvimage though ... to pre-create it from a txt file [09:58] yeah [09:58] (line 16 in http://paste.ubuntu.com/11893737/) [09:58] checking the u-boot side first - patching was messy [09:58] :( [09:58] i could not cherry pick cleanly [10:01] ogra_: so the source for your uboot.env is the new-Env.txt file ? [10:01] yeah [10:02] but that indeed includes the BBB default env ... i assume you want to create your oown from scratch [10:02] ok let me see where i get this tool - or do you recommend to use https://github.com/mvo5/uboot-go instead? [10:04] mkenvimage was added to u-boot in http://git.denx.de/?p=u-boot.git;a=commit;h=a6337e6ffdea211e70dd8d6c638f6a5ec2295400 - i guess i can cherry pick that one or use the other tool [10:06] * longsleep tries the go tool first [10:16] well uboot-go says bad CRC when trying to print the file created by saveenv [10:21] at least it is consistent - u-boot says bad CRC when loading a uboot.env created by the uboot-go :) [10:21] yeah, not good [10:22] ogra_: did you try that too and have the same issue? [10:22] no, works fine for me ... but mvo develops on the BBB (and i try on the BBB) so that proves nothing [10:23] mhm - i might have an older format of the file. Let me upload it for you somewhere. [10:24] note that i'm using the armhf version *on* the BBB [10:24] armhf version of what? [10:24] uboot-go ? [10:24] of the go tool [10:24] mhm there should not be any difference in go no matter what arch [10:25] http://people.canonical.com/~mvo/tmp/ [10:25] ok let me try that build [10:27] longsleep: the uboot env format is "funny". its either 4 byte (crc) or 5 byte (crc+flags) [10:28] mvo: any idea where i could quickly upload the env file? [10:28] longsleep: it seems like the flag is for "redundant" envs, but thats just a theory from reading the u-boot code, maybe your thing expects a different header [10:28] longsleep: hexdump -C uboot.env|head is probably enough for me for now, just pastebin that :) [10:29] mvo: well i cherry picked and hacked around the env fat code so it might well be a u-boot issue as well [10:29] mvo: ok hold on [10:30] mvo: http://paste.ubuntu.com/11908556 [10:30] longsleep: for the 5 bytes image you need to pass mkenvimage -r iirc (redundant). plus the size must exactly match the size that is compiled into the uboot binary (but I guess thats all no news for you :) [10:30] longsleep: joy, looks like you have a 4 byte header [10:30] mvo: that is news - i had no idea about .env format before today [10:31] i do not even have mkenvinmage yet as this is newer than my uboot :) [10:31] but the size triggers a bell [10:31] longsleep: heh :) ok, I can tell you all I know, its going to be quick ;) [10:32] longsleep: so header is important (either 4 or 5 byte). size must match exactly the one thats compiled in, then it should work (tm) [10:32] i have CONFIG_ENV_SIZE (32 * 1024) [10:32] is that the size you mean? [10:32] yes [10:32] and CONFIG_ENV_OFFSET (512 * 1024) [10:32] that might be a problem? [10:33] I'm not sure, I *think* (but could be totally off) that this is ignored when writing to fat files [10:33] * longsleep checks the code [10:33] seems so as its not used in the FAT code. CONFIG_ENV_SIZE is used [10:33] great! [10:34] longsleep: the uboot.env from the pastebin, was that created using saveenv from your uboot prompt? [10:34] yes [10:35] hm, I wonder if there is a way to get a 5 byte header there as well. would be nice if it would be all the same on all ports [10:35] but I can probably add auto-detect magic to my go-code, but its a bit ugly, something like "if isAscii(content[4])" which feels …wrong [10:36] assuming that my file is supposted to work then yes - but i thought you have a 4 byte header as well? [10:39] we have a 5 byte header but I have not yet figured out why, I don't know if its maybe a config option in the uboot build, maybe ogra_ knows. its seems releated to "redundant" env [10:39] whatever that means [10:40] mvo: i do not know either, no redundant what so ever related to env in my build config for u-boot. [10:42] mvo: if you want to have the complete file: https://www.stdin.xyz/downloads/people/longsleep/tmp/uboot.env-odroidsaveenv [10:44] longsleep, ogra_ do you have CONFIG_SYS_REDUNDANT_ENVIRONMENT in your build config? [10:44] that seems to be the magic configuration [10:45] ogra@anubis:~/datengrab/rpi/uboot/bbb/u-boot-latest$ grep CONFIG_SYS_REDUNDANT_ENVIRONMENT configs/am335x_boneblack_defconfig [10:45] ogra@anubis:~/datengrab/rpi/uboot/bbb/u-boot-latest$ [10:45] nope [10:45] mvo: grep shows nothing in u-boot that - so does not seems so [10:46] ups, sorry, typo on my side :( [10:46] CONFIG_SYS_REDUNDAND_ENVIRONMENT [10:46] -^ [10:47] that matches but i do not have it set [10:47] nope, not either [10:47] ogra_: not set either [10:47] hmmmmm [10:47] it also seems only be used in env_embedded [10:47] and in envcrc [10:47] hold on [10:48] for me (current u-boot git) it defines the size o fenv_t [10:48] i.e. typedef struct environment_s {} env_t [10:49] but nevermind, I am pretty sure I can do the auto-detection magic, reading the code further, content[4] is either 0 or 1 when its a 5 byte header and its ascii if its a 4 byte header, so auto-detect should work [10:49] on reading at least [10:50] writing is a different matter, need to add flags or something [10:50] ogra_: but why we do not set it really confuses me, i.e. how we end up with a long header [10:50] i have no idea [10:51] ogra_: could you pastebin our config? maybe its somehow derrived [10:51] i just pushed my u-boot branch https://github.com/longsleep/u-boot-odroidc/tree/odroidc-configfat [10:51] thats the tree i have to use [10:52] mvo: what file is that with the size? [10:52] * ogra_ grumbles about sergiusens sending messages i cant open [10:52] environment.h found it [10:53] * mvo gets lunch [10:53] longsleep: include/environment.h is it for me that defines the header size [10:54] mvo: yeah i see it - maybe that has changed in later uboots [10:54] * mvo nods [10:54] mvo: see https://github.com/longsleep/u-boot-odroidc/blob/odroidc-configfat/include/environment.h - i will compare as well [10:55] * longsleep gets lunch too [10:55] looks similar at first glance [10:55] oh - CONFIG_ENV_OFFSET_REDUND [10:55] looks like it might be a derrived config value [10:57] that REDUND stuff looks like a big mess [10:57] but anyhow - i agree that you should only end up with a 5 byte header when REDUNDAND_ENVIRONMENT is set === EllieGoulding is now known as plop_its_ellie [11:55] mvo: just to confirm, when changing headerSize to 4 in your env.go the odroidc file parses just fine [11:57] ogra_: i think the reason why your u-boot has 5 bytes header and mine has 4 bytes needs to be found. [11:57] yeah, i need to check on the RPi too [12:00] ogra_: http://paste.ubuntu.com/11908839/ is the uboot.env default content - if you want to compare with yours [12:03] hi [12:04] I'd like to have a bit of web service [12:04] and I'd like to register my service to avahi [12:04] so [12:04] should I bundle avahi (seems wrong) [12:04] longsleep: great to hear that it works with that header size [12:04] or should I start to work on a avahi.framework? [12:04] mvo: hey :-) [12:04] hey zyga [12:04] zyga, you should bundle avahi [12:04] longsleep: and yeah, I need we need to figure out whats going on :) [12:04] ogra_: but how can that work if there can be only one avahi server on a host [12:04] ogra_: one to bind to the magic port [12:05] ogra_: it's a system-level feature [12:05] zyga, there was some planning that user installed snaps can override that [12:05] ogra_: two apps cannot both bundle avahi (server) [12:05] * ogra_ remembers some discussion on the ML [12:05] ogra_: can you explain how this would work ? [12:05] no [12:05] but i know that the expectation was that you bundle it [12:05] and that the preinstalled avahi goes oout of your wa< [12:05] ogra_: mmm, so I don't get it, if I do my snap with avahi server I effectively prevent all other snaps from doing that [12:05] way [12:05] ? [12:06] is there a preinstalled avahi? [12:06] no idea [12:06] yes, webdm ships avahi [12:07] hmm, does it? [12:07] I don't see that here [12:07] yes [12:07] longsleep, ogra_: lets try to get to the bottom of this, if all else fails I add the auto-magic, but I hope I don't have to do this [12:07] well, and that wouldnt help on "create" [12:08] mvo: well the question is how is the initial .env file created. [12:08] ah, so snappyd has an avahi server inside? [12:08] +is [12:08] hmmm, I still don't get how this can work with more than one app [12:09] longsleep: indeed, you guys need some default values in there right? that come from the default_env of the uenv code? [12:09] longsleep, preferably indeed by your mkenv tool [12:09] from the tools dir [12:09] that should give you the right header for your uboot [12:09] yes all kinds of stuff might need to be set in addition to snappy boot logic [12:09] longsleep: I have go code that can read a key=value\n file and create a uboot.env but I don't know about the initial defaults. I wonder if mkenvimage helps here [12:10] yes, it should be compiled with the righ defaults for your specific build [12:10] well the default could be provided in the oem package [12:10] the problem is how and where does the snappy boot logic get triggered [12:10] i assume some devices will adapt all that stuff to a possible NAND that we dont use [12:10] in ogra_ 's file he does it with uenvcmd [12:10] that only works because his defaults run this macro in bootcmd [12:11] in my file this will have to be totally different [12:11] all devices use snappy_boot [12:11] your bootcmd should already be adjusted for this [12:11] the bootcmd should directly load snappy_boot ? [12:11] yours loads uenvcmd [12:12] which the loads snappy_boot [12:12] *then [12:12] so you say that the defaults should somehow end up loading snappy_boot? [12:12] i am good with that [12:12] the final env needs to be a merger of all the former snappy- files uEnv.txt and the default env [12:12] right [12:13] like you used it before ... just now merged [12:13] i was not using uEnv.txt before - so it might be a bit different [12:13] i was using boot.ini to set stuff [12:13] well, but for rollback and stuff you used snappy-system-txt [12:13] *.txt [12:13] right [12:14] so your boot.ini somehow pulled in and called snappy_boot [12:14] correct [12:14] which has the logic [12:14] right, so now, just do the same :) [12:14] yes i can do it manually i get that [12:14] just not scattered across multiple files [12:14] the question is how to automate it [12:14] or make it generic [12:14] your initial txt file should have it [12:15] ok - so that is still shipped by the OEM snap or whatever there is in the future [12:15] yes [12:15] uboot.env will be shipped [12:15] in your snap [12:15] then the 4 or 5 byte problem should be none as well [12:15] the tool just needs to keep the header size as the same [12:16] right, if mvo can autodetect it and we can just rely on mkenvimage we should be all fine [12:16] mkenvimage - that tool is a problem - i would prefer the go version from mvo [12:16] i wouldnt like to generalize here since it might break the ability of a board to actually use the NAND [12:17] in case you want to switch to that we shouldnt break your defaults [12:17] mkenvimage guarantees that your env file will be readable for sure though [12:17] (for u-boot at least) [12:17] corret - but this would be created on OEM snap building right? So that tool is a build requiredment [12:18] yeah [12:18] well, its is a req for your port [12:19] ah - the .env file needs to be changed on update too - you want this to be done by the mkenvimage tool as well? [12:19] will ave to go into the porting documentation (once we have such a thing :P ) [12:20] ogra_: how would it break nand when we use the go version? just curious? mkenvfile can only create a file afaics [12:21] mvo, it could break NAND if we enforce a certain header in the u-boot build ... not in the go version [12:21] ogra_: oh, sure, the go version will be able to deal with both headers, thats for sure, same way as mkenvfile with a flag [12:21] ah yes - thats true - but we do not neede to enforce the header. Just make the go tool support 4 and 5 bytes and keep the size on change [12:21] what mkenvfile creates could be written to nand [12:21] but no worries, using mkenvfile is fine [12:22] I just wanted to understand if there is anything I need to support for NAND [12:22] yeah, i think thats the safest option [12:22] no [12:22] and we dont plan to support it atm ... but i want us to not break the potential use of it either :( [12:22] err [12:22] :) [12:23] so you propose to ship mkenvfile as pat of a snappy system and use this tool to modify .env files? [12:23] s/pat/part [12:23] no [12:23] i propose to ask porters to use it to create their initial uboot.env file [12:23] when they do their u-boot.img build [12:24] ok thats fine [12:24] and for updates use the go tool? [12:24] for our purpoose the go binary should be fine [12:24] +1 [12:24] jusr not for the initial creation (unless we have a header -zize option or some such and know exactly which board needs which header size) [12:25] well the developer should know, i am not so sure that the mkenvfile will know either as it needs to be compiled exactly with the same config. [12:26] right, which is what i simply assume when you build your u-boot tree [12:27] ogra_: ok - i guess this is a valid assumption [12:27] (especially since you need to patch it anyway for the uboot.env support i would expect you to recompile it) [12:29] ogra_: by patching you mean enabling the defines in the board configuration? [12:29] right [12:29] ogra_: i thought newer uboots have a config file for this instead of header files [12:30] oh,, do they ? [12:30] * ogra_ hasnt heard of that [12:30] i think so, i had some troubles backporting stuff because of this change [12:31] yes [12:31] see http://git.denx.de/?p=u-boot.git;a=tree;f=configs;h=ff6b998c4ffa4e9da3ab367141156391d5fcad3d;hb=HEAD [12:32] what about that ? that has always been the config dir [12:32] no - not in my tree [12:32] all the defconfig stuff is rather new [12:32] ah [12:33] * ogra_ remembers using it for beagle XM installs years ago [12:34] well arm u-boot is so messy, but the diff you use for BBB also does not seem to use it as your change is in a header file - or maybe i get it wrong [12:35] ogra_: well ok - it uses both, earlier it was only includes. Never mind. [12:36] yeah, it now includes the includes :) [12:36] they changed the structure a bit [12:37] i thought it was easier to change compile settings without patching in a bunch of defines [12:38] mvo: uboot-go seems to have another setting for headerSize as it seems to create 5 bytes headers even with headerSize set to 4 [12:41] * ogra_ tried a static kodi build on the weekend to use it in snap and click packages ... [12:41] longsleep: oh, let me check [12:41] seems building something static as soon as pytjhon is involved becomes a major pain :( [12:42] thats why you use Go :) [12:42] longsleep, doesnt help when wanting to build some nonn go thing like kodi (xbmc) [12:43] obviously i can only build it as static binary if i also have a static python i have to build myself [12:43] such a mess .( [12:43] having a kodi snap would be pretty awesome [12:44] longsleep: I'm fixing this right now, give me some minutes, I will yell once I have a fix [12:44] mvo: awesome thanks [12:44] well, i was more after a click :) but yeah, rolling a snap at the same time shouldnt be hard [12:44] what is a "click" - i think i missed something [12:48] longsleep, the predecessor of snap [12:49] ogra_: oh - seems i have missed that [12:50] it is what we use on the phone [12:53] * longsleep tries to compile mkenvimage [12:53] just "make all" ;) [12:54] nah - had to backport it into my u-boot :) [12:54] but seems like it compiled [12:55] anybody here on 14.04, to try the mir snap in virt-manager? [12:56] ogra_, mvo - i think i just might have found why you have 5 bytes headers [12:57] because we are the cooler kids ! [12:57] :P [12:57] in your example you have -r parameter to mkenvimage - i guess that means redundant [12:57] "the environment has multiple copies in flash" [12:57] right, and without -r we get CRC errors [12:57] ok :) [12:57] so the uboot binary expects the 5 bytes [12:58] longsleep: if you git pull from my uboot-go repo it should hopeflly work, no auto-detection yet though, you still need to set the header size manually, I add that in the next commit [12:58] mvo: cool / i will try in 2 minutes [12:59] no rush [12:59] I'm here for at least 3h [13:00] ok with the old version i can read a 4 bytes file created with mkenvimage [13:00] lets update [13:01] still works with updated version [13:01] lets see if i can create [13:01] mvo: yes works - cool [13:01] yay [13:01] yay^2 [13:01] lets try to set something :) [13:02] set works too now - now the boot test [13:02] yippies [13:03] mvo: works like a charm [13:04] \o/ [13:04] ogra_: and you were right, uboot.env removes all previously loaded defaults [13:04] i now have essentially only foo=bar in the environment [13:04] yeah [13:05] but thats something - i think i could get the odroidc platform boot fine with this ne scheme [13:05] new [13:05] just think about the kids^WATAGs ... [13:05] (respective handed through dtb settings) [13:05] longsleep: there is now also "import" to read from key=value files [13:06] mvo: oh let me try that [13:07] mvo: yeah works fine as well [13:07] (note that i have changed headerSize to 4) [13:14] I don't see an updated Mir in my updates, is there a way to check the store to make sure it's not my local system being broken? [13:15] tedg: what's up/down? [13:15] was a newer Mir uploaded to the store yet ? [13:15] you can use uappexplorer [13:15] tedg: ah, you mean the snap? [13:15] (unless that now filters snaps) [13:16] tedg: bzr branch lp:~mir-team/mir/snappy-packaging && cd snappy-packaging && make && echo YEAH [13:16] It was in the store, just need a newer version. Which kgunn said he was uploading on Friday. [13:16] I need to know whether it's my fault or not before I complain :-) [13:16] s/echo/notify-send/ [13:16] Chipaca, Sure, just trying to get everything working "out-of-the-box" [13:16] https://uappexplorer.com/app/my-world.testsnappy ... doesnt filter it seems [13:17] so if a new snap is uploaded it should show up in https://uappexplorer.com/apps [13:17] (usually sorts newest first) [13:17] I can't find the original in uappexplorer, because it's a framework? [13:17] probably [13:18] what version do you see? [13:18] snap1 [13:18] ah, right, a search for docker doesnt return anything [13:19] hmm, just because i searched wrongly [13:19] https://uappexplorer.com/app/com.ubuntu.snappy.docker [13:19] https://uappexplorer.com/apps?sort=relevance&type=snappy [13:19] that actually lists all snaps [13:19] Still don't see Mir though. [13:19] only 59 :((( [13:20] kgunn, Where you able to get Mir uploaded on Friday? [13:20] tedg: i did, altho, prolly just in store review queue...lemme check [13:21] longsleep: silly question, how terrible would it be for you to enable this redundand option? or is that not availalbe at all for your version of uboot? [13:21] tedg: ah...says published, so snappy search should say snap1.1 [13:21] mvo: good question - can give it a try [13:22] mvo: i guess i would be fine if it does not break anything [13:22] tedg: lemme know if you have issue with install [13:23] Hmm, no. I don't see it. And neither does uappexplorer. https://uappexplorer.com/app/mir.mvp-demo [13:23] (finally found it there) [13:24] * longsleep compiling u-boot with CONFIG_SYS_REDUNDAND_ENVIRONMENT [13:25] tedg, yeah, weird that uappexplorer doesnt list it at all [13:27] mvo: seems to work just fine - now i get CRC error with 4 byte env file [13:28] We may need to ping the store. [13:28] mvo: saveenv just worked fine and it seems to load the file it just created [13:28] 4 byte is so last build anyway :P [13:28] hehe [13:28] yay [13:28] moar bytes ! [13:28] now let me create a new 5 byte file [13:29] Could someone check with a "snappy search mir" on their device and see if snap1.1 is available to them? [13:29]