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?
-- viresh
On 1 August 2013 14:11, Viresh Kumar viresh.kumar@linaro.org 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
On 1 August 2013 07:57, Andy Green andy.green@linaro.org wrote:
On 1 August 2013 14:11, Viresh Kumar viresh.kumar@linaro.org 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
On 1 August 2013 16:30, Ryan Harkin ryan.harkin@linaro.org wrote:
On 1 August 2013 07:57, Andy Green andy.green@linaro.org wrote:
On 1 August 2013 14:11, Viresh Kumar viresh.kumar@linaro.org 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
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
On 1 August 2013 09:30, Ryan Harkin ryan.harkin@linaro.org wrote:
The vexpress defconfig has always been broken.
...maybe we could fix it?
-- PMM
On Thu, 2013-08-01 at 17:40 +0100, Peter Maydell wrote:
On 1 August 2013 09:30, Ryan Harkin ryan.harkin@linaro.org 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 ;-)
On 1 August 2013 18:46, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Thu, 2013-08-01 at 17:40 +0100, Peter Maydell wrote:
On 1 August 2013 09:30, Ryan Harkin ryan.harkin@linaro.org 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
On 2 August 2013 01:46, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Thu, 2013-08-01 at 17:40 +0100, Peter Maydell wrote:
On 1 August 2013 09:30, Ryan Harkin ryan.harkin@linaro.org 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
On 2 August 2013 00:26, Andy Green andy.green@linaro.org wrote:
On 2 August 2013 01:46, Jon Medhurst (Tixy) tixy@linaro.org 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
On 2 August 2013 07:38, Peter Maydell peter.maydell@linaro.org wrote:
On 2 August 2013 00:26, Andy Green andy.green@linaro.org wrote:
On 2 August 2013 01:46, Jon Medhurst (Tixy) tixy@linaro.org 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
On 2 August 2013 01:14, Andy Green andy.green@linaro.org wrote:
On 2 August 2013 07:38, Peter Maydell peter.maydell@linaro.org wrote:
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.
That's generally not the problem in my experience (and the kernel's 'chosen' nodes in its device trees don't have any contents anyway, so that would definitely result in a failure-to-boot).
Random recent examples: * user passed us a versatilepb kernel but we're emulating vexpress * user passed us 'earlyprintk' but the kernel's selected earlyprintk isn't the right one for the board we're running * user forgot to tell QEMU to emulate enough memory so the kernel stops before it's initialised the serial output * kernel has CONFIG_DEBUG_SEMIHOSTING and user passes 'earlyprintk' on kernel command line but QEMU not run with -semihosting argument * kernel configured to use the "guess which vexpress board this is based on the exact revision-and-patchlevel-of-the-CPU" earlyprintk, and guesses wrongly about where the serial port is because QEMU's CPU isn't the exact revision a h/w TC1 has
Actually what would fix this would be if the bootloader had a simple way to say "here is where you will find a serial port" [eg physaddr for output plus physaddr for status register and mask to indicate how to wait for the port to be ready to tx]. Then the kernel would have a reliable way of getting output to the user right from the offset that didn't rely on the kernel being correctly configured, the device tree being the right one for the kernel, etc. And it could just enable earlyprintk by default in that situation.
-- PMM
-
Andy Green -
John Stultz -
Jon Medhurst (Tixy) -
Peter Maydell -
Ryan Harkin -
Viresh Kumar