[08:02] <hrw> morgen
[12:39] <furibondox> hello everybody
[12:40] <furibondox> I'm trying to use rootstock on ubuntu lucid but I have a blocking problem...
[12:40] <furibondox> anybody have a suggestion?
[12:41] <furibondox> the error is: /usr/bin/rootstock: line 282:  6890 Segmentation fault      qemu-system-arm $QEMUOPTS -append "${APPEND}" > $QEMUFIFO 2>&1
[12:41] <furibondox> it seems a problem related to qemu itself...
[12:46] <furibondox> anybody use rootstock from ubuntu lucid?
[13:00] <furibondox> anybody use rootstock with ubuntu lucid?
[13:30] <vstehle> furibondox: You may want to report this into launchpad.
[13:31] <furibondox> vstehle: I've just reported... https://bugs.launchpad.net/ubuntu/+source/rootstock/+bug/570588 (item 13)
[13:32] <ubot2> Launchpad bug 570588 in rootstock (Ubuntu) (and 1 other project) "qemu-system-arm can not handle more than 256M in versatile machine mode using the -m option (affects: 2) (heat: 53)" [Undecided,Invalid]
[13:33] <furibondox> I just would like to know if someone experienced the same behaviour and have found a solution/workaround...
[13:34] <ogra> if you see the exact same bug, just revert your changes to the rootstock script
[13:40] <furibondox> ogra: which change?
[13:40] <ogra> furibondox, did you read the bug before commenting ?
[13:40] <furibondox> yes
[13:41] <ogra> its about someone who hacked his rootstock script to use 512M
[13:41] <ogra> so revert that and it will work
[13:42] <furibondox> I've also tried to use 512M changing the rootstock script but it fails again
[13:43] <ogra> well, qemu cant use 512M
[13:43] <ogra> thats what the bug is about
[13:44] <furibondox> sorry ogra, I know that but I've read some bug report on google describing the same error but in different threads... and I took the 570588 to add a comment
[13:45] <furibondox> may be is not the more approriate item opened
[13:45] <ogra> well, if you changed the script to use 512M thats the bug, if you didnt, its not that bug and should be filed as a new one
[13:47] <furibondox> I tell you my tests: 1) with 512M 2) with 256M 3) with more seeds 4) with only one seed
[13:47] <furibondox> the result is the same
[13:48] <ogra> and you are onyl using packaged versions of rootstock, qemu and friends ?
[13:48]  * ogra knows that pleanty of people use rootstock under lucid and it works for them
[13:50] <berco> ogra: just to let you know that your udev script worked fine in the end. Can't think I told you.
[13:51]  * ogra hugs berco 
[13:51] <ogra> perfect !
[13:57] <furibondox> yes ogra, all my packages (qemu, rootstock, debootstrap etc) come from the lucid repository
[13:57] <ogra> in your pm you used rootstock-native, thats definately not packaged
[13:59] <furibondox> yes sorry... it was just a test...
[14:01] <furibondox> ii  rootstock                                  0.1.99.3-0ubuntu1                               shellscript to create armel rootfs tarballs
[14:02] <furibondox> May be there's something wrong with my command line?
[14:03] <furibondox> sudo rootstock -f NGP --seed setserial,openssh-server,ubuntu-minimal -i 1G --serial ttyS2 --doswap --swapsize 256 --restore-package-cache
[14:03] <ogra> setserial should be included in ubuntu-minimal, beyond that all looks fine
[14:03] <ogra> and adding setserial shouldnt cause issues
[14:03] <furibondox> ok
[14:04] <furibondox> but, as far as you know, do you think that is a qemu problem or rootstock problem?
[14:05] <furibondox> if you think that is a rootstock problem I can try to uninstall/re-install qemu and try again
[14:05] <furibondox> what do you think?
[14:07] <ogra> well, qemu segfaults
[14:07] <ogra> its definately not a rootstock problam
[14:07] <ogra> *problem
[14:08] <furibondox> ok
[14:08] <furibondox> I try to remove all and reinstall
[14:09] <ukleinek> ogra: it's not long ago when I told you how to spell definitely :-)
[14:10] <ogra> ukleinek, i blame the heat
[14:10]  * ogra melts slowly
[14:10] <ukleinek> ogra: so Berlin is hot, too?
[14:10] <ogra> ukleinek, kassel here
[14:10] <ogra> 28°C in my office, 36°C outside
[14:10] <ukleinek> ogra: oh, Kassel, I thought you'd live in Berlin
[14:11] <ukleinek> ogra: similar here
[14:11] <ogra> i'd love to ... (who wants to live in kassel anyway)
[14:11] <ukleinek> ogra: so why do you?
[14:11] <amitk> b-----i------g house
[14:11] <ogra> free living :)
[14:11] <amitk> :-p
[14:12] <ogra> no rent, solar heating system ... major cost factor :)
[14:12]  * ukleinek has a solar heat here for free, too
[14:13] <furibondox> ogra: I'm retring...
[14:16] <rsalveti> morning
[14:21] <rsalveti> hm, another qemu segfault
[14:21] <rsalveti> interesting that this is happening with lucid
[14:22] <rsalveti> ogra: was finally able to create the rootfs as user, but still have many issues to solve
[14:22] <ogra> rsalveti, might be realted to amd64 systems
[14:22] <ogra> rsalveti, good to hear :)
[14:22] <rsalveti> first, fuseext2 is incredibly  unstable =\
[14:23] <rsalveti> I can create the same image many times, just with 'ro', and get different results everytime
[14:23] <rsalveti> lots of files get the wrong size and data
[14:24] <rsalveti> so just after running the second stage, to be able to test, I mounted as loop, until we get this solved
[14:24] <ogra> k
[14:24] <rsalveti> ogra: but my biggest problem is the seg fault that I'm getting most of the time
[14:24] <ogra> qemu segfault too ?
[14:24] <rsalveti> ogra: yep :-(
[14:24] <ogra> crap
[14:24] <rsalveti> just after running the second stage
[14:24] <ogra> x86 or amd64 ?
[14:24] <rsalveti> amd64, this could be the issue
[14:24] <ogra> yeah
[14:24] <rsalveti> will try on x86 to see
[14:25] <lag> sebjan: Ping
[14:25] <rsalveti> ogra: see comment 54 on bug 532733
[14:25] <ubot2> Launchpad bug 532733 in qemu-kvm (Ubuntu Lucid) (and 2 other projects) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 7) (dups: 1) (heat: 79)" [High,Incomplete] https://launchpad.net/bugs/532733
[14:25] <ogra> rsalveti, that bug isnt about segfaults
[14:26] <rsalveti> yeah, I know
[14:26] <rsalveti> but many people reported about the segfault while trying to reproduce it
[14:26] <ogra> that bug slowly turns into a mess :(
[14:26] <rsalveti> that's why I posted there, cause it can be similar to what people was getting
[14:26] <rsalveti> bug for sure, it's different
[14:26] <ogra> the hang doesnt produce any segfaults at all
[14:27] <rsalveti> ogra: are you using x86?
[14:27] <ogra> upstream already refused to look at it because of the confusing comments
[14:27] <ogra> yes
[14:27]  * rsalveti wasn't able to get just the 'hang'
[14:27] <rsalveti> oh, ok
[14:28] <ogra> the hang only shows up if you install a big task like ubuntu-desktop or ubuntu-netbook
[14:28] <ogra> dpkg hangs at some point
[14:28] <rsalveti> ogra: yeah, but I'm getting the seg fault before that :-), but I'm using amd64
[14:28] <ogra> your segfault seems userspace related
[14:28] <rsalveti> will see with x86
[14:32] <furibondox> ogra: same error: http://pastebin.ca/1898986 :-(
[14:32] <rsalveti> furibondox: how are you calling rootstock?
[14:33] <furibondox> sudo rootstock -f NGP --seed openssh-server,ubuntu-minimal -i 1G --serial ttyS2 --doswap --swapsize 256 --restore-package-cache
[14:33] <furibondox> from ubuntu lucid
[14:33] <furibondox> all packages (qemu, rootstock, etc...) came from the lucid repository
[14:34] <rsalveti> furibondox: are you running on x86 or amd64?
[14:34] <furibondox> x86
[14:34] <rsalveti> furibondox: ok, can try to reproduce it here, but many people did run rootstock without this issue on lucid
[14:35] <furibondox> the only unusual component is that my lucid x86 runs under vmware
[14:35] <ogra> heh
[14:36] <rsalveti> :-)
[14:36] <ogra> thats probably something you should have told in the beginning :)
[14:36] <ogra> not sure if qemu can run inside vmware
[14:36] <rsalveti> yeah, could be the problem
[14:36] <furibondox> some times ago I tested qemu inside vmware w/o problems
[14:37] <ogra> i know qemu cant run inside a kvm instance
[14:37] <ogra> or insice vbox
[14:37] <ogra> *inside
[14:37] <lool> ogra: uh?
[14:37] <lool> I thought qemu could work just fine in kvm
[14:37] <ogra> lool, can it now ?
[14:37] <ogra> soren told me it cant
[14:37] <lool> First time I heard it can't
[14:38] <lool> You cant use qemu acceleration though
[14:38] <ogra> so i never bothered to try to stack qemu instances
[14:38] <ogra> hey asac
[14:38] <lool> You can't run kvm in QEMU though
[14:38] <asac> omg
[14:38] <asac> the heat is on
[14:38] <ogra> warm here, eh ?
[14:38]  * ogra grins
[14:39] <furibondox> ok... so your suggestion is to try within physical ubuntu installation, right?
[14:39] <rsalveti> furibondox: yep, I'm trying it here on x86 with your command line
[14:39] <ogra> if you have one around, i would suggest that
[14:40] <furibondox> tnx rsalveti
[14:46] <sebjan> lag: pong
[14:46]  * ogra goes to find some icecream
[14:46] <lag> sebjan: HI
[14:46] <lag> Hi*
[14:46] <lag> What's the latest with the Syslink driver?
[14:46] <lag> Is it going to make our build?
[14:47] <sebjan> I have tested with your last patch update, and could see that the modules where automatically loaded, as expected
[14:48] <sebjan> we have no solution yet for the issues when it is built as modules. We may have to re-test with syslink v2 and debug on this version rather than on the current one
[15:02] <furibondox> rsalveti: can you tell me if the building is finished without errors?
[15:02] <rsalveti> furibondox: still going
[15:03] <rsalveti> going to run the full vm now
[15:03] <furibondox> ok
[15:05] <lag> sebjan: Thanks for the update
[15:06] <lag> sebjan: Do any of your chips have parallel ports?
[15:17] <vstehle> lag: I don't think we have parallel ports in the OMAP per se, but it can be "emulated" with GPIO if needed.
[15:25] <furibondox> rsalveti: is finished now?
[15:26] <rsalveti> furibondox: not yet, but it's just finishing the full emulation part, no crash until now
[15:26] <furibondox> good
[15:31] <lool> ogra: Hey
[15:32] <ogra> lool, yup
[15:32] <lool> ogra: Do you folks intend to include x-loader + u-boot in omap pre-installer images?
[15:32] <lool> *pre-installed
[15:32] <ogra> yep
[15:32] <lool> ogra: Ok; is this tracked in a bug/blueprint somewhere?
[15:33] <ogra> err, sorry, was distracted
[15:33] <ogra> we *do* already include both
[15:34] <lag> vstehle: Thanks, but there's no need. The parport_pc driver is crashing your devices.
[15:34] <ogra> lool, https://blueprints.edge.launchpad.net/ubuntu/+spec/preinstalled-sd-card-images-for-omap
[15:34] <ogra> lool, "Change armel+omap debian-cd scripts to create a two partition image with first partition being vfat with proper bootloader setup"
[15:36] <lool> ogra: Hmm
[15:36] <ogra> lool, dailies are here: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ (still lacking web indicies, manifest and proper md5sum stuff, but its on teh list)
[15:36] <lool> ogra: Yes, this didn't boot with qemu for me
[15:37]  * ogra never tried it with qemu
[15:37] <ogra> did you dd it to an SD card and ran qemu with it as hdd1 ?
[15:37] <lool> ogra: My ports-dev PPA has an updated package
[15:38] <ogra> you will definately need a real disk for it
[15:38] <ogra> since it tries to expand to the full disk size, it wont work if it cant expand to have free diskspace
[15:39] <ogra> we only leave 10M in the root partition that are eaten up ny the ext3fs journal
[15:39] <ogra> s/ny/by/
[15:39] <ogra> so even if you would get it to boot, it would need to be dd'ed to a bigger sized (i'd recommend 4G) image
[15:40] <ogra> lool, your qemu is omap3 i guess, we only include the actual beagleboard MLO in the image atm
[15:40] <lool> ogra: I did a bunzip2
[15:40] <lool> and ran it with qemu -sd
[15:40] <ogra> so if you dont strictly emulate a beagle that might be the prob
[15:41] <lool> ogra: My QEMU boots the Angstrom beagleboard image somewhat
[15:41] <lool> Well into kernel boot messages for instance
[15:41] <ogra> and ours ? where does it stop ?
[15:41]  * ogra is in the process of updating to x-loader 1.4.4 from 1.4.3 ... probably that helps
[15:42] <ogra> i didnt touch the omap3 stuff since pre-A2 but it definately works on real HW
[15:42]  * ogra focuses on omap4 atm
[15:43] <ogra> lool, angstrom images are not partitioned, they are tarballs, no ?
[15:44] <hrw> ogra: they are
[15:44] <ogra> unless something changed significantly recently
[15:44] <hrw> ogra: you mean 'narcissus' ones I assume
[15:45] <ogra> hrw, no idea what lool used above for qemu tests
[15:45] <hrw> neither do I
[15:46] <ogra> i know for sure our images work on actual HW and i would have never gotten the idea to try one of them in qemu :)
[15:46] <ogra> especially since its quite some hassle you have to do with the image sizing
[15:46] <ogra> if you dont actually dd to an SD card
[15:47] <lool> ogra: No, it's a partitioned SD card image
[15:47] <lool> Angstrom-Beagleboard-demo-image-glibc-ipk-2010.3-beagleboard.sd-image-2GiB.img1  *           1           9       72261    c  W95 FAT32 (LBA)
[15:47] <lool> Angstrom-Beagleboard-demo-image-glibc-ipk-2010.3-beagleboard.sd-image-2GiB.img2             10         240     1855507+  83  Linux
[15:47] <ogra> where did you get that ?
[15:47] <ogra> i only know the tarballs
[15:47] <hrw> I know that OE can generate any type of image
[15:47] <ogra> the partitioning seems to be identical to ours though
[15:48] <ogra> and since we use the same code i bet it actually is :)
[15:48] <ogra> so the only difference can be xloader or uboot if you dont get any serial output
[15:49] <ogra> our omap3 x-loader package is still at 1.4.3 with the XM patches on top ... in 1.4.4 the XM patches are included, i'll update it this week
[15:49] <ogra> lool, so try an image from the end of this week
[15:50] <ogra> so we can exclude MLO here
[15:50] <ogra> its my only explanation
[15:50] <ogra> lool, you can also try to replace the binaries in the vfat and see
[15:51] <rsalveti> furibondox: yep, no problem
[15:51] <rsalveti> furibondox: same arguments
[15:51] <rsalveti> furibondox: vmware can be your problem
[15:51] <furibondox> thank you very much rsalveti
[15:51] <rsalveti> np
[15:52] <furibondox> I will try with a native ubuntu installation
[15:52] <lool> ogra: I tried the image from yesterday evening
[15:52] <ogra> lool, cant be, the livefs builder was broken since thu :)
[15:53] <furibondox> rsalveti: I've a question... do you have tested with a lucid?
[15:53] <lool> ogra: I grabbed the "current" image from yesterday
[15:53] <lool> it might be a stale one
[15:53] <ogra> lool, as i said above, i'll update x-loader-omap3 this week
[15:53] <lool> ogra: Ok, thanks
[15:53] <ogra> until then try to replace the binaries in our image witrh the angstrom ones
[15:53] <ogra> and see if it boots then
[15:54] <rsalveti> furibondox: yep
[15:54] <ogra> our vfat is exactly 9 clinders and "W95 FAT32 (LBA)" so there shouldnt be a difference apart from MLO and uboot
[15:55] <furibondox> rsalveti: can you also send me the output of a dpkg -l of your pc?
[15:55] <rsalveti> furibondox: 10.04.1
[15:55] <rsalveti> furibondox: sure, 1 sec
[15:55] <furibondox> I leave my email in pm
[15:55]  * ogra takes a break and hunts for more icecream
[15:57] <rsalveti> furibondox: http://paste.ubuntu.com/462558/
[15:58] <furibondox> tnx
[16:40] <hrw> lag: did you got working screen finally on panda?
[16:41] <lag> Nope
[16:41] <lag> TI are working on it
[16:41] <lag> I've been working on something else
[16:41] <hrw> lag: maybe http://gitorious.org/pandaboard/kernel-omap4/blobs/L24.6_panda/drivers/video/omap2/dss/hdmi.c  will help you to find working hdmicode value
[16:42] <ogra> or http://omappedia.org/wiki/Bootargs_for_enabling_display
[16:42] <ogra> we had all that in the dicussing last week :)
[16:43] <ogra> *discussion
[16:43] <hrw> ;)
[16:43] <lag> Finding a working hdmicode is not the issue
[16:43] <ogra> right
[16:44] <lag> When I use sysfs almost all of them work for me and my monitor
[16:44] <lag> When I use the cmdline arguments, the best I can hope for is a fuzzy screen and an "out of range" message from my monitor
[16:45]  * ogra just thinks its a matter of the right glasses
[16:45] <ogra> they should just ship them with the boards ;)
[16:55] <fjrivash> Hello, I am following these instructions to get a rootfs for ARM https://wiki.ubuntu.com/ARM/RootfsFromScratch, I compiled a kernel and generated a zImage, when I try to run qemu (as specified in the tutorial) I got a black screen, I tried adding -d options file.log at the end of the command to get the output but I got nothing, am I missing something?
[16:55] <fjrivash> I changed the -cpu option for amr11mpcore,
[16:55] <fjrivash> thanks in advanced :D
[16:58] <ogra> fjrivash, for which release are you building your rootfs ?
[16:58] <fjrivash> lucid
[16:58] <ogra> wont run with arm11mpcore
[16:58] <ogra> lucid is built for armv7
[16:59] <ogra> arm11mpcore is an extended armv6 as i understand it
[16:59] <fjrivash> ohhh I see.
[17:00] <fjrivash> Yes it is compatible with armv6kz
[17:00] <ogra> use the binary kernel from the tutorial
[17:01] <fjrivash> well see : I did the first step of this section "Building a root filesystem image instead of a tarball" and after that compiled my own kernel and tried booting : it did not work. After that I got that image and is the same, that is why I am asking.
[17:03] <fjrivash> is there a way to build a rootfs of a release wich support armv6 (or compatible) using rootstock?
[17:04] <GrueMaster> fjrivash: Try using Karmic or Jaunty.
[17:04] <GrueMaster> Otherwise you are kind of stuck with debian.
[17:04] <ogra> karmic supports v6
[17:05] <fjrivash> Ok. i will try with them :D great!. Thank you (both) very much :D
[17:16] <fjrivash> I have been reading different documents about this topic and some of them says that you need to specify initrd in qemu command line, is it necessary?, I am not pretty sure about that, thanks in advanced again
[17:19] <Apaisal> hello all
[17:26] <rsalveti> ogra: hm, same seg fault on x86 =\
[17:26] <rsalveti> will try to debug it now
[17:27] <suihkulokki> lool: committed and pushed to gitorious
[17:27] <htc>  I wana to do  same her   http://nexusonehacks.net/nexus-one-hacks/how-to-install-ubuntu-on-your-nexus-oneandroid/  whit another version of ubuntu but I don't know how  bullied an arm img of it it there any doc can help
[17:30] <hrw|gone> htc: try karmic
[17:31] <htc>  <hrw|gone> how
[17:32] <hrw> htc: no idea, never played with chroot on mobile devices
[17:32] <hrw> and I do not like idea of 'run ubuntu/debian/fedora/anyotherdistro in chroot and tell everyone that you run it'
[17:33] <hrw> chroot is chroot... if people boot that distro then I will say that they managed to do something worthy
 no , what I want is the way to builded from scratch there is any doc can help
[17:35] <hrw> htc: you rather want to get rootfs for ARM rather then start from scratch
[17:35] <htc>  yep  like this exmple http://nexusonehacks.net/nexus-one-hacks/how-to-install-ubuntu-on-your-nexus-oneandroid/ in order to run it on an android device
[17:36] <hrw> so use rootstock
[17:36] <htc> like her https://wiki.ubuntu.com/ARM/RootfsFromScratch
[17:37] <hrw> yes
[17:38] <htc> I will need any thing else after I build the ARM img
[17:39] <hrw> htc: ask nexusonehacks.net guy?
[17:39] <hrw> hi prpplague
[17:40] <prpplague> hrw: greetings earthling
[17:41] <htc> ok  men I will
[17:41] <htc> & tnx
[17:54] <lool> ogra: is LP #589624 still an issue for you?
[17:54] <ubot2> Launchpad bug 589624 in linux (Ubuntu) "[Maverick] omap flavour does not work on beagle XM board (affects: 1) (heat: 97)" [High,Triaged] https://launchpad.net/bugs/589624
[17:54] <lool> suihkulokki: Thanks
[19:31] <ogra_cmpc> lool, yes, thats the main reason why i update the x-loader package
[19:31] <ogra_cmpc> lool, apparently it works on *some* XMs
[19:32] <ogra_cmpc> i'm hoping updating x-loader makes it work on all
[19:32] <ogra_cmpc> (recommendation from #beagle)
[21:18] <ukleinek> npitre: thanks for your mails, great to have your support
[21:25] <zumbi> yeah! mv sh*t /dev/null
[21:27] <armin76> zumbi: what happened?
[21:27] <zumbi> armin76: nothing! spain won, we are champions! congrats! :)
[21:29] <zumbi> armin76: linus wants to remove defconfigs from arm and ppc, but ukleinek did a proposal (he did not like it, but it removes 200k lines of sh*t)
[21:34] <ukleinek> zumbi: :-)
[21:35] <ukleinek> user@host:/usr/bin$ ls sh*t
[21:35] <ukleinek> showcfont  showfont
[21:36] <zumbi> ukleinek: this is best than TV series anyway (also we have the hardfloat arm stuff) :)
[21:37] <ukleinek> zumbi: your sentence doesn't make it through my natural language parser :-(
[21:42] <zumbi> ukleinek: i meant that your thread at linux-arm@ is going to take long discussion (better to follow this thread than TV series - I have no TV at the moment -). We, as distro, also have long thread on having an arm hardfloat port, which it is involving upstream and it seems that lot of people is interested, but they need to workout mechanisms (on the upstream side)
[21:42] <ukleinek> ah
[21:42] <zumbi> ukleinek: It seems that it is time to put some order in the ARM trees (linux+rootfs)
[21:43] <ukleinek> zumbi: there is definitly potential for more order, yes
[21:44] <ukleinek> still, I leave for bed now and will recheck tomorrow for the outcome of the discussion
[21:44] <zumbi> Sure, it'll take a while to put all bits in place
[21:44] <zumbi> g'night! and congrats for the good job :)
[21:44] <ukleinek> There is even potential for more code sharing across archs
[21:45] <ukleinek> zumbi: It was easy and I don't consider it "good", it's just nice and the best thing that currently works.  My main concern is to be able to continue build testing until a better solution is implemented
[21:46] <zumbi> ukleinek: sure, s,good,fast & effective, but you are the one that came up with the short term idea, for others to think on the long term one. :)
[21:47] <ukleinek> zumbi: if you check the changes I did to the ns9xxx_defconfig you see it's actually an old idea
[21:48] <ukleinek> This file was first reduced and then I added some symbols that I expected to be mainlined next
[21:48] <zumbi> uhm.. haven't check the changes.. but i worked with ns9215
[21:49]  * ukleinek is now really away
[21:49] <zumbi> bye
[21:49] <zumbi> i'll have a look
[22:13] <npitre> ukleinek: no problem
[23:30] <npitre> ukleinek: ... and it is in now ;-)
[23:32] <zumbi> linus is fast! I like it :)
[23:33] <zumbi> npitre: and rmk warns linus about adopting DT?
[23:33] <zumbi> or did I misunderstood?
[23:34] <npitre> zumbi: no, what RMK is refering to is not DT
[23:34] <zumbi> ah! I was thrilled about it
[23:34] <npitre> zumbi: we're working on various patches to eventually allow a single kernel binary to support multiple SOC families, and that is orthogonal to DT
[23:35] <zumbi> but I guess both approaches target the same problem
[23:35] <npitre> zumbi: not exactly
[23:36] <npitre> zumbi:  DT is about how to provide info to the kernel so it can configure itself even for yet-to-exist boards
[23:37] <npitre> zumbi: so DT will allow to reduce the per machine static configuration code
[23:37] <npitre> zumbi: but DT cannot solve the much bigger issue of being able to compile together support for more than one SOC
[23:39] <zumbi> which it is probably what RMK was talking about