Re: Organizing Config Fragments
On 1 August 2013 14:11, Viresh Kumar wrote: > Hi Andrey, > > linaro/configs/* is getting bigger and bigger, probably its the right time to > organize it better for the future. There can be multiple things that we can > do to avoid confusions of names but for now probably we can create > separate directories for boards, rootfs & kernel fragments? Or some > other idea that you might have? Just a thought these seem to me like they are covering up for missing "select xxx" in the related Kconfig option (eg, CONFIG_ANDROID), or stuff that should be in the defconfig (eg, omap4, vexpress). There's also an issue the fragments are all =y when for ARCH_MULTIPLATFORM, it implies all things not needed for rootfs mount need to be =m. -Andy > -- > viresh > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Organizing Config Fragments
On 1 August 2013 07:57, Andy Green wrote: > On 1 August 2013 14:11, Viresh Kumar wrote: >> Hi Andrey, >> >> linaro/configs/* is getting bigger and bigger, probably its the right time to >> organize it better for the future. There can be multiple things that we can >> do to avoid confusions of names but for now probably we can create >> separate directories for boards, rootfs & kernel fragments? Or some >> other idea that you might have? > > Just a thought these seem to me like they are covering up for missing > "select xxx" in the related Kconfig option (eg, CONFIG_ANDROID), or > stuff that should be in the defconfig (eg, omap4, vexpress). Is the platform specific defconfig still relevant in a multiarch kernel? I guess the fragments should adding items missing from the default multiarch config. Excuse my ignorance, 'cause I don't know how multiarch works... Historically, the main reason for us creating the frags was because of the platforms (eg, Ubuntu) adding lots of config options that weren't in the defconfig. The vexpress defconfig has always been broken. But over-riding the defconfig with Ubuntu/Android/whatever options was a bigger bodge than creating fragments. So I think they are still important for Linaro's builds. Escpecially as we aren't building multiarch kernels for all our platforms yet. > > There's also an issue the fragments are all =y when for > ARCH_MULTIPLATFORM, it implies all things not needed for rootfs mount > need to be =m. That's a good point and something we should look into. We should really be using multiarch kernels sooner rather than later, right? > > -Andy > >> -- >> viresh >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Release Critical Test Result Summary of Calendar Week 31,2013 for Linaro Android Jellybean
Here is release critical test result summary of Calendar week 31,2013 for Linaro android jellybean images on following boards: 1) TI-Panda 4460; 2) TI-Panda 4430; 3) ARM Versatile Express A9; 4) Samsung Arndale; 1. TI-Panda 4460 + Linaro Android Jellybean 4.2.2 (Column: AU) https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadGVWd3pZazdaRUU0MnRnWmgwbVhTR0E#gid=18 2. TI-Panda 4430 + Linaro Android Jellybean 4.2.2 (Column: AU) https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadGVWd3pZazdaRUU0MnRnWmgwbVhTR0E#gid=17 3. ARM Versatile Express A9 + Linaro Android Jellybean 4.2.2 (Column: AT) https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadExQdHNxTnR5SFZCQzJnN1ZtQ2ZhWkE#gid=5 4. Samsung Arndale + Linaro Android Jellybean 4.2.2 (Column: E) https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AuNOCeo15fRHdDFaRmJkWHdNVURtemZObnBWb0tleEE#gid=0 Please see the result spreadsheet for details results and bug reports. Thanks & Regards Soumya Basak. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Organizing Config Fragments
On 1 August 2013 16:30, Ryan Harkin wrote: > On 1 August 2013 07:57, Andy Green wrote: >> On 1 August 2013 14:11, Viresh Kumar wrote: >>> Hi Andrey, >>> >>> linaro/configs/* is getting bigger and bigger, probably its the right time >>> to >>> organize it better for the future. There can be multiple things that we can >>> do to avoid confusions of names but for now probably we can create >>> separate directories for boards, rootfs & kernel fragments? Or some >>> other idea that you might have? >> >> Just a thought these seem to me like they are covering up for missing >> "select xxx" in the related Kconfig option (eg, CONFIG_ANDROID), or >> stuff that should be in the defconfig (eg, omap4, vexpress). > > Is the platform specific defconfig still relevant in a multiarch > kernel? I guess the fragments should adding items missing from the > default multiarch config. Excuse my ignorance, 'cause I don't know > how multiarch works... It lets you have more than one CONFIG_ARCH_blah at once enabled in the config and working in the one kernel binary . You give it one of the valid dtbs to tell it what it is at runtime. We use it to have the CONFIG_ARCH_(dual aa9 SoC) and CONFIG_ARCH_(big.LITTLE SoC) in the same kernel binary so the same kernel can start up on both platforms. Once it's started though, it's just bloat to have peripheral drivers present on only one of the platforms built-in to the monolithic kernel. For example those two SoCs have different video IPs, so we need them to be both built as modules and then use the different Device Tree definition to bind to just the right module at runtime so it all works out nicely. So you do still need to tell the kernel what drivers are relevant to your combined set of arches, your defconfig needs to reflect that (and builds everything selected as modules where possible). > Historically, the main reason for us creating the frags was because of > the platforms (eg, Ubuntu) adding lots of config options that weren't > in the defconfig. The vexpress defconfig has always been broken. But > over-riding the defconfig with Ubuntu/Android/whatever options was a > bigger bodge than creating fragments. Right I think eg, adding selects to CONFIG_ANDROID in its Kconfig, or adding CONFIG_ANDROID_TYPICAL to do that and select CONFIG_ANDROID would soak up some of them anyway. General Ubuntuesque options I don't know, maybe that's more legit. > So I think they are still important for Linaro's builds. Escpecially > as we aren't building multiarch kernels for all our platforms yet. > >> >> There's also an issue the fragments are all =y when for >> ARCH_MULTIPLATFORM, it implies all things not needed for rootfs mount >> need to be =m. > > That's a good point and something we should look into. We should > really be using multiarch kernels sooner rather than later, right? I think it makes a lot of sense for each vendor to have their own stuff building as a single multiarch kernel if possible. Then you can just provide one image with one or two kernels (LPAE and non-LPAE don't play together) plus a lot of modules and dtbs that covers all the cases. It will be possible to enable different vendor arches all at the same time as well, but the different bootloader requirements situation will scuttle that. Some combinations will work like Fujitsu AA9 has bootloader in internal NOR, it can share an SD with OMAP4 using MLO inside VFAT okay. At any rate to get the SoC support upstream now you have to meet the checklist for ARCH_MULTIPLATFORM so it's certainly the way of the future. -Andy >> >> -Andy >> >>> -- >>> viresh >>> >>> ___ >>> linaro-dev mailing list >>> linaro-dev@lists.linaro.org >>> http://lists.linaro.org/mailman/listinfo/linaro-dev >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Organizing Config Fragments
On 08/01/2013 01:30 AM, Ryan Harkin wrote: Historically, the main reason for us creating the frags was because of the platforms (eg, Ubuntu) adding lots of config options that weren't in the defconfig. The vexpress defconfig has always been broken. But over-riding the defconfig with Ubuntu/Android/whatever options was a bigger bodge than creating fragments. Yes. Config fragments just allow for a distribution to have a consistent config policy for non-hardware specific configs (ie: cgroups, debug options, filesystem support, etc) on an array of different architectures and hardware platforms. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Organizing Config Fragments
On 1 August 2013 09:30, Ryan Harkin wrote: > The vexpress defconfig has always been broken. ...maybe we could fix it? -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Organizing Config Fragments
On Thu, 2013-08-01 at 17:40 +0100, Peter Maydell wrote: > On 1 August 2013 09:30, Ryan Harkin wrote: > > The vexpress defconfig has always been broken. > > ...maybe we could fix it? It has been suggested that should be deleted as people can use the multiplatform defconfig (though I believe that is missing the regulator config for mmc as well). People have different ideas where various configs should live, boards specific defconfig, multiplatform defconfig or in Kconfig; and any particular change probably would have people arguing against it. And with vexpress we have the added complication thrown into the mix that people use it a lot with QEMU ;-) -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Organizing Config Fragments
On 1 August 2013 18:46, Jon Medhurst (Tixy) wrote: > On Thu, 2013-08-01 at 17:40 +0100, Peter Maydell wrote: >> On 1 August 2013 09:30, Ryan Harkin wrote: >> > The vexpress defconfig has always been broken. >> >> ...maybe we could fix it? Not that we've had this conversation many times before, but, if you care about it, you are welcome to fix it... ;-) We (ARMLT) neither own it nor care about it, so we aren't going to fix it. > > It has been suggested that should be deleted as people can use the > multiplatform defconfig (though I believe that is missing the regulator > config for mmc as well). > > People have different ideas where various configs should live, boards > specific defconfig, multiplatform defconfig or in Kconfig; and any > particular change probably would have people arguing against it. And > with vexpress we have the added complication thrown into the mix that > people use it a lot with QEMU ;-) > > -- > Tixy > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Organizing Config Fragments
On 2 August 2013 01:46, Jon Medhurst (Tixy) wrote: > On Thu, 2013-08-01 at 17:40 +0100, Peter Maydell wrote: >> On 1 August 2013 09:30, Ryan Harkin wrote: >> > The vexpress defconfig has always been broken. >> >> ...maybe we could fix it? > > It has been suggested that should be deleted as people can use the > multiplatform defconfig (though I believe that is missing the regulator > config for mmc as well). > > People have different ideas where various configs should live, boards > specific defconfig, multiplatform defconfig or in Kconfig; and any > particular change probably would have people arguing against it. And That's probably a correct prediction... but it doesn't mean all of the solutions are equally good. I guess nobody outside Linaro with these kernels uses and most don't even know about the config fragments scripts. We inherit them from llct but nobody uses them in Fujitsu. - For things fixing a defconfig, or making it appropriate for other patches added in that kernel, shouldn't we patch the defconfig directly (via make savedefconfig)? Then people will use the fix and you have a fix to suggest upstream. - For optional things that follow from enabling a single Kconfig selection (eg, CONFIG_ANDROID) why not have it enforced at the selection of that config? - For Ubuntize or --> > with vexpress we have the added complication thrown into the mix that > people use it a lot with QEMU ;-) ...if there's something special needed for QEMU, maybe the fragments are the right answer. Or if it's just lack of models for IP maybe building the drivers modular anyway and knocking them out in dts (status="not okay") is the right answer. However currently they all have a "let's make a fat kernel" =y approach when our defconfig is more like allmodules, so for us we can't use any of the fragments meaningfully, so eliminating them doesn't sound like a bad idea. -Andy > -- > Tixy > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Organizing Config Fragments
On 2 August 2013 00:26, Andy Green wrote: > On 2 August 2013 01:46, Jon Medhurst (Tixy) wrote: >> with vexpress we have the added complication thrown into the mix that >> people use it a lot with QEMU ;-) > > ...if there's something special needed for QEMU, maybe the fragments > are the right answer. My general aim is that the kernel that works on h/w should also work on the QEMU model. In general it does, though we rely a bit on various driver probe routines gracefully coping with the device not actually being present. "Somebody put something new into the kernel and exposed a missing bit of QEMU emulation support" is also a periodic event, but those are just bugs that need fixing. The biggest roadblock I'm seeing at the moment actually is that there's a big class of problems (which generally boil down to "wrong kernel config" or sometimes "wrong QEMU command line arguments") which manifest as "kernel produces no output". 'common and easy user error' + 'zero diagnostics' = 'lots of annoying support email' :-) x86 manages to do much better here because the "everything looks like a PC" effect means it's much easier for the kernel to produce output to serial or video very early. It's much easier to configure an ARM kernel so it doesn't look for the serial port in the right place or so it falls over before it gets round to actually being able to output to serial (and earlyprintk is very hit-and-miss especially in a multiplatform kernel). I'm not sure there's really a good solution to this problem, though :-( -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Organizing Config Fragments
On 2 August 2013 07:38, Peter Maydell wrote: > On 2 August 2013 00:26, Andy Green wrote: >> On 2 August 2013 01:46, Jon Medhurst (Tixy) wrote: >>> with vexpress we have the added complication thrown into the mix that >>> people use it a lot with QEMU ;-) >> >> ...if there's something special needed for QEMU, maybe the fragments >> are the right answer. > > My general aim is that the kernel that works on h/w should > also work on the QEMU model. In general it does, though we > rely a bit on various driver probe routines gracefully coping > with the device not actually being present. "Somebody put We have a similar situation with a (non-QEMU) simulator, but it's not possible to win on that since just probing an empty address will blow a bus fault. We have to take the approach to knock out the missing device instantiations in the dtsi. > something new into the kernel and exposed a missing bit > of QEMU emulation support" is also a periodic event, but those > are just bugs that need fixing. > > The biggest roadblock I'm seeing at the moment actually is > that there's a big class of problems (which generally > boil down to "wrong kernel config" or sometimes "wrong > QEMU command line arguments") which manifest as "kernel > produces no output". 'common and easy user error' + 'zero > diagnostics' = 'lots of annoying support email' :-) Right, I can imagine. > x86 manages to do much better here because the "everything > looks like a PC" effect means it's much easier for the kernel > to produce output to serial or video very early. It's much > easier to configure an ARM kernel so it doesn't look for the > serial port in the right place or so it falls over before it > gets round to actually being able to output to serial (and > earlyprintk is very hit-and-miss especially in a multiplatform > kernel). I'm not sure there's really a good solution to this > problem, though :-( The problem is the bootloader being "flexible" and meddling with the dtb chosen line to match its private state (bootargs in U-Boot env for example). I don't know how to stop U-Boot doing that, since if it even gets wind that you loaded a dtb image it's all over it meddling. But if you could stop it, preparing a golden "chosen" commandline in the dts and telling people to disable bootloader dtb meddling would be a nice debugging aid. We use a stub bootloader instead that always uses the chosen already in the dts. -Andy > -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
