**** BEGIN LOGGING AT Wed Nov 04 02:59:58 2015 Nov 04 15:57:50 alai, yo Nov 04 15:57:52 hi Nov 04 15:58:10 ogra_, hi Nov 04 15:58:13 so the only way to successfully load dtbs on the rpi2 is to load them via config.txt and the binary blob Nov 04 15:58:23 alai, lol, sorry i meant ali1234 Nov 04 15:58:44 why would that be a thing? Nov 04 15:58:53 the blob stuff the dtb (and overlays) into 0x100 ... and uboot needs to load it from there Nov 04 15:59:09 okay so you can't load overlays directly with u-boot Nov 04 15:59:16 that is because u-boot doesn't understand them Nov 04 15:59:17 if you do a fatload or tftp load it will not initialize correctly Nov 04 15:59:28 and uboot will set ATAGs ... Nov 04 15:59:44 okay, i will test this :) Nov 04 15:59:57 so your kernel boots but you end up without /proc/device-tree and not all HW features work Nov 04 16:00:20 for snappy i chainload uboot from the blob ... and let the blob handle all dtb bits ... Nov 04 16:00:42 yes, obviously we must always chainload from the blob Nov 04 16:00:43 in uboot i only call "fdt 0x100" to load it Nov 04 16:01:06 there are some extras you want to actually get the board serial and MAC though Nov 04 16:01:46 (RaspberryPi2)ubuntu@rpi2:~$ fw_printenv |grep ^loadfdt Nov 04 16:01:46 loadfdt=fdt addr 0x100; fdt get value args /chosen bootargs Nov 04 16:01:53 thats what i use in snappy Nov 04 16:02:01 so what i'm using is pxe Nov 04 16:02:08 i then add ${args} to the commandline Nov 04 16:02:08 or rather the u-boot pxe emulation Nov 04 16:02:33 that way the serial and MAC (which only the blob knows) are handed over Nov 04 16:02:41 and you can have the codecs working etc Nov 04 16:03:05 vmlinuz-4.2.0-1014-raspi2 yeah? Nov 04 16:03:11 right Nov 04 16:03:29 and /lib/firmware/4.2.0-1014-raspi2 for the dtb files Nov 04 16:03:47 (and the overlay subdir) Nov 04 16:04:03 i won't need the overlay because u-boot can't load that... Nov 04 16:05:15 right, but you want bcm2708-rpi-b-plus.dtb Nov 04 16:05:20 err Nov 04 16:05:23 2-b Nov 04 16:05:25 bcm2709-rpi-2-b.dtb Nov 04 16:05:29 right, sorry Nov 04 16:05:30 yeah, same name as the foundation one Nov 04 16:05:42 i already have an identical named file on my server Nov 04 16:05:55 well, you want the one that matches your kernel :) Nov 04 16:06:04 nah, it doesn't really matter too much Nov 04 16:06:04 else you make a mess Nov 04 16:06:10 sure it does Nov 04 16:06:16 i'm using one built for 3.18 on a 4.1 kernel right now Nov 04 16:06:19 it works fine Nov 04 16:06:37 it is directly tied to the enabled devices from the kernel config, else you will only have half the stuff working Nov 04 16:06:48 yes, but those don't change much Nov 04 16:06:55 anyway, enough chat Nov 04 16:07:01 note that this kernel is using the ubuntu config Nov 04 16:07:09 same as -generic Nov 04 16:07:29 so you really dont want to use a foundation 3.18 dtb here :) Nov 04 16:09:59 okay here we go Nov 04 16:11:40 aw typos Nov 04 16:16:13 ogra_: it booted, i have /proc/device-tree Nov 04 16:16:41 and you have system serial and the actual HW MAC in your system ? Nov 04 16:17:03 (RaspberryPi2)ubuntu@rpi2:~$ cat /proc/cpuinfo |grep ^Serial Nov 04 16:17:03 Serial : 000000008b04db1c Nov 04 16:17:11 http://paste.ubuntu.com/13102443/ Nov 04 16:17:38 no, serial is 0 Nov 04 16:17:44 right Nov 04 16:17:51 but that is an entirely different thing Nov 04 16:18:00 so no video codecs for you and your IP will chane on every boot Nov 04 16:18:16 i'm surprised though ... what uboot version is that ? Nov 04 16:18:23 HEAD from two days ago Nov 04 16:18:27 mine is about 8 weeks old and it doesnt work here Nov 04 16:18:31 aha Nov 04 16:18:42 so perhaps it has seen some fixes Nov 04 16:18:49 must have Nov 04 16:19:03 anyway the serial number thing is not something that is stored on the SD card Nov 04 16:19:17 in any case i need the serial since people that want to build snappy kodi appliances will want to use the codecs :) Nov 04 16:19:17 the point of this whole thing was to prove you could boot a pi with nothing except u-boot and config.txt Nov 04 16:19:23 and the firmware bins Nov 04 16:19:37 the serial gets added to the devicetree by the blob when it loads it Nov 04 16:19:53 oh. well that's just stupid... Nov 04 16:19:55 as gets the MAC Nov 04 16:20:11 the blob is the only thing that talks to the HW on that level Nov 04 16:20:59 well i'll pass this on to the LTSP flks as they will no doubt want to use codecs too Nov 04 16:21:21 i discussed that with alkis quite a bit in the last weeks :) Nov 04 16:21:56 so he is aware i guess :) Nov 04 16:22:45 ali1234, so you are sure it isnt using the dtb that the blob has put into 0x100 ? Nov 04 16:22:47 since two days ago? Nov 04 16:22:53 i see you are loading to the same address Nov 04 16:23:05 no, over the past weeks Nov 04 16:23:10 yes because my config.txt is completely empty except for the line kernel=u-boot.txt Nov 04 16:23:14 we didnt talk the last two days Nov 04 16:23:26 your confi.txt has no influence on the dtb Nov 04 16:23:34 only on the overlays Nov 04 16:23:37 ogra_: well it was two days ago he asked on raspberry pi and i got it working Nov 04 16:23:53 the dtb name and path are hardcoded in the blob Nov 04 16:23:57 hmm good point Nov 04 16:24:12 do you have the dtb on Sd next to the blob ? Nov 04 16:24:15 yep Nov 04 16:24:27 tyr renaming it or removing it and see if it still boots Nov 04 16:24:35 although surely if it was doing that, it would have a serial number? Nov 04 16:24:42 also if i overwrote it, how can it use it? Nov 04 16:24:48 trying now anyway Nov 04 16:24:49 (though that wont still tell if uboot actually overwrites 0x100 ...) Nov 04 16:25:13 you will only have the serial if you handed it to the kernel cmdline Nov 04 16:25:38 bcm2709.boardrev=0xa01041 bcm2709.serial=0x8b04db1c smsc95xx.macaddr=B8:27:EB:04:DB:1C Nov 04 16:25:46 you need these three on the cmdline Nov 04 16:26:04 fdt get value args /chosen bootargs Nov 04 16:26:10 in uboot after you loaded the dtb Nov 04 16:26:34 then make sure to have ${args} on your cmdline and uboot shoudl expand it Nov 04 16:26:44 oh, so that could just be hard coded in the pxe config? Nov 04 16:27:12 well, but it will only be populated in the dtb the blob did put to 0x100 Nov 04 16:27:32 i'm not sure what happens if you overwrite that area with your tftp retrieved dtb Nov 04 16:27:33 why does it need to be on the command line and the dtb? Nov 04 16:27:45 the kernel needs it on the cmdline Nov 04 16:27:47 yeah it booted with the dt renamed Nov 04 16:27:53 the sd card one that is Nov 04 16:27:53 cool ! Nov 04 16:28:06 i guess i'll take a look then ... Nov 04 16:28:19 * ogra_ needs to update the snappy device tarball anyway for the rpi Nov 04 16:28:23 let me add those numbers on my command line Nov 04 16:28:42 so what i wonder now is if you can use a fake dtb for the blob ... just to get the args populated ... Nov 04 16:28:55 ... then overwrite it from uboot with a dtb you load Nov 04 16:28:59 and if that still boots Nov 04 16:29:10 that way you get the cake and the tea :) Nov 04 16:29:45 i don't understand Nov 04 16:30:17 you mean like pass a fake dt in and then extract out the bits the blob added? Nov 04 16:30:24 why even use a fake one? Nov 04 16:30:30 just use the real one... Nov 04 16:30:36 because the blob will try to add to it Nov 04 16:30:39 it's going to get overwritten anyway Nov 04 16:30:44 right Nov 04 16:30:53 but first you want to extract the args from it Nov 04 16:30:58 yes we want the blob to add to it Nov 04 16:31:06 to get the HW data the bkob did read Nov 04 16:31:09 so use a fake one because it will be easier? Nov 04 16:31:17 because there's less space to search Nov 04 16:31:33 i doubt the blob will add the stuff if there isnt *some* dtb Nov 04 16:31:47 okay my pi now has that serial number you pasted here Nov 04 16:31:55 well, thats mine :P Nov 04 16:32:03 it comes from the chip Nov 04 16:32:48 and you need it to obtain the codecs from broadcom .... they get tied to the device via the serial Nov 04 16:32:54 yeah Nov 04 16:33:42 so wouldn't the codecs work even if /proc/cpu shows the wrong serial? Nov 04 16:33:43 to get your serial you need to get it from the blob ... and thats only possible via the in memory dtb ... which is most likely gine once you overwrite it by loading yours Nov 04 16:33:54 sure sure Nov 04 16:34:23 but i mean if the codecs relied on /proc/cpu to validate... then there would be lots of piracy Nov 04 16:34:33 broadcom will give you a codec that only works on a specific serial ... and i would expect they keep track if they have given it out already Nov 04 16:34:54 i also guess there is more to it than the cpuinfo serial that gets checked against Nov 04 16:35:36 i.e. if the codec takes action i would expect it to verify the number against the actual SoC Nov 04 16:35:41 so at this point we need u-boot to be able to manipulate overlays etc Nov 04 16:35:53 then we can do this properly Nov 04 16:36:06 right, i havent seen a way to do this Nov 04 16:36:34 in snappy i fully rely on the blob for all dtb actiions by now Nov 04 16:36:49 yeah, can't do that when booting from the network Nov 04 16:36:51 has at least the advantage that all upstream docs still match :) Nov 04 16:37:08 you can ... but its ugly Nov 04 16:37:31 you can obtain the dtb via tftp ... fatwrtite it, set a flag and reboot Nov 04 16:37:48 hah, like the old N900 multiboot method Nov 04 16:37:54 reflash the kernel every time you switch OS Nov 04 16:37:56 as i said ... ugly Nov 04 16:38:05 no thanks :) Nov 04 16:38:36 (gets even more ugly if you want to clone the overlays subdir every time) Nov 04 16:40:33 hmm Nov 04 16:40:35 actually Nov 04 16:40:43 you now mkknlimg? Nov 04 16:40:59 for unboot.bin, yeah Nov 04 16:41:22 well i didn't run the rpi mkknlimg on my u-boot.bin Nov 04 16:41:31 which means the blob won't think it supports device tree Nov 04 16:41:36 (RaspberryPi2)ubuntu@rpi2:~$ grep uboot /boot/uboot/config.txt Nov 04 16:41:36 kernel=uboot.bin Nov 04 16:41:38 which means it won't set any device tree Nov 04 16:41:43 ah Nov 04 16:42:08 if you put a vmlinuz directly into /boot without running mkknlimg on it, not /proc/device-tree Nov 04 16:42:27 right, cant do that on snappy Nov 04 16:42:36 can't do what? Nov 04 16:42:41 so nothing i ever bothered to experiment with Nov 04 16:43:13 our kernel lives in a subdir thats selected via uboot scriptery Nov 04 16:43:22 okay that doesn't matter Nov 04 16:43:35 the thing is that mkknlimg appends a tag to the elf binary you run it on Nov 04 16:43:44 the blob look sat that tag to determine if device tree is supported Nov 04 16:43:46 right, which is needed by the blob Nov 04 16:43:55 so my u-boot does not have that tag Nov 04 16:44:10 but only for the first thng you load via the kernel= option in confi.txt Nov 04 16:44:24 yes which is u-boot.bin Nov 04 16:44:28 right Nov 04 16:44:36 which means that the blob will not put device tree at 0x100 Nov 04 16:44:44 because it does not think u-boot supports device tree Nov 04 16:44:49 oh, for you you mean Nov 04 16:44:52 yes for me Nov 04 16:44:54 yeah Nov 04 16:44:55 who else? ;) Nov 04 16:45:19 anyway so the question then is how did they pass the serial numbers before dt support was added? Nov 04 16:45:28 using those kernel params you showed? Nov 04 16:45:32 ATAGs :P Nov 04 16:45:38 if so we can rip the serial etc from ATAGS Nov 04 16:45:45 try it Nov 04 16:45:50 because those are like a million times easier to parse in u-boot Nov 04 16:46:12 but i fear if they dropped ATAG support from their kernel their last iteration of the blob might have dropped it too Nov 04 16:46:16 you ahve to check Nov 04 16:46:38 that would certainly explain why the kernel failed to boot when i loaded no DT Nov 04 16:46:46 if there were no ATAGs either... Nov 04 16:47:04 well, for me it also fails if i load an old dtb because oi forgot to replace it Nov 04 16:47:24 but no it must still support them because i booted a kernel without DT support when going direct from the blob Nov 04 16:47:26 hmm Nov 04 16:47:38 well, try to read them then Nov 04 16:47:57 i will Nov 04 16:48:11 also did you run mkknlimg on your u-boot? Nov 04 16:48:22 if you use the blob for dt management then i think you must have... Nov 04 16:48:32 * ogra_ wonders what we talked about the last ten minutes :P Nov 04 16:48:52 yes, i use mkknlimg on my uboot.bin and define it as kernel= in config.txt Nov 04 16:49:52 so that the user can define overlays and dt options in config.txt ... uboot just passes the dt trhough Nov 04 16:50:35 (all i need uboot for is the kernel and initrd selection and the auto-fallback functioality of snappy) Nov 04 16:51:02 would be nice to have a boot menu for different kernel testing... i should set that up properly at some point Nov 04 16:51:16 yeah, thats trivial with uboot Nov 04 16:51:30 especially since the rpi one has framebuffer support by default Nov 04 16:52:04 i only have serial and ssh on my pi Nov 04 16:52:19 a failsafe initrd would be handy too Nov 04 16:52:33 reimplementin snappy ? :) Nov 04 16:52:48 well snappy doesn't work on the model a :P Nov 04 16:52:49 (we call it recovery there though) Nov 04 16:52:54 and about that Nov 04 16:53:08 i did an rdepends on all those snappy packages Nov 04 16:53:12 yeah, old HW is old HW Nov 04 16:53:13 it was absolutely huge so i gave up Nov 04 16:53:35 an rdepends ? Nov 04 16:53:40 on what now ? Nov 04 16:53:51 remember we talked about porting snappy to raspbian? Nov 04 16:54:03 vaguely Nov 04 16:54:10 well it looks really hard Nov 04 16:54:17 even with jessie Nov 04 16:54:49 yeah, its a bit bloated currently Nov 04 16:54:57 we'll do some cleanup work soon Nov 04 16:55:10 snappy source is now on github btw Nov 04 16:55:21 (for the snappy binary) Nov 04 16:57:17 i calculated all the packages in the snappy core image that aren't in jessie, and then did an rdepends on them and calculated the list of those packages not in jessie Nov 04 16:57:32 the first list was about 20 packages, the second was about 80 packages Nov 04 16:57:35 did you talk to alan bell ? Nov 04 16:57:39 not recently Nov 04 16:57:48 i know he was trying to set up a compile farm some time ago Nov 04 16:57:51 he actually wanted to rebuild the archive on his cluster Nov 04 16:58:00 i funded part of his kickstarter :) Nov 04 16:58:11 doing the same raspbian did to debian but based on the ubuntu archive Nov 04 16:58:17 not sure where that went Nov 04 16:58:22 afaik nowhere Nov 04 16:58:41 (simply rebuilding everything as armv6) Nov 04 16:58:46 okay so i just dumped 0x100 and it looks like ATAGs to me Nov 04 16:59:09 and ? any valuable data in there ? Nov 04 16:59:14 http://paste.ubuntu.com/13102809/ Nov 04 16:59:19 or just random basics Nov 04 16:59:26 the serial for one thing Nov 04 16:59:35 yeah Nov 04 16:59:36 ! Nov 04 16:59:41 nice one Nov 04 17:01:57 so the way we did this on N900 was just to not touch the atags set by previous bootloader Nov 04 17:02:03 but u-boot upstream did not like that very much Nov 04 17:02:17 but the point being we never actually parsed them Nov 04 17:02:25 and we can't reuse atags when booting device tree Nov 04 17:05:05 erm... Nov 04 17:05:14 u-boot has a command "fdt get" Nov 04 17:05:34 we can just use that to read from the blob's fdt before overwriting it? Nov 04 17:05:49 is also has "set" Nov 04 17:06:09 i think that didnt work last time i tried Nov 04 17:06:14 (didnt boot anymore) Nov 04 17:13:42 how does a bootloader pass the command line to the kernel when booting with device tree? Nov 04 17:13:51 in general i mean... Nov 04 17:15:20 also, multiple device tree blobs are allowed? Nov 04 17:16:04 so then pass an empty one to the initial bootloader and then load ours into a different place? Nov 04 17:16:12 that might just work... Nov 04 17:17:40 or maybe even none at all Nov 04 17:17:44 hmm Nov 04 17:17:51 i need to run mkknlimg on my u-boot Nov 04 17:18:44 heh Nov 04 18:08:33 ogra_: mkknlimg refused to operate on my u-boot.bin, any hints? Nov 04 18:08:43 hmm, not really Nov 04 18:08:49 * Is this a valid kernel? In pass-through mode. Nov 04 18:09:10 there is a way to make it ignore that but i dont hav emy notes around Nov 04 18:09:21 okay i'll check the source Nov 04 18:10:22 ah you force the flags --dtok and --283x Nov 04 18:10:33 dunno what the atter does Nov 04 18:11:23 ah, for open source kernels Nov 04 18:39:46 ogra_: got u-boot tagged now. with no dt file at all, the broadcom blob always puts atags in 0x100 regardless