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