kernel entry for thumb2-only cpus

[Russell King - ARM Linux]

+1 on everything Nicolas has said below.  Full violent agreement there.

On Mon, Aug 06, 2012 at 08:08:57PM -0400, Nicolas Pitre wrote:
> On Mon, 6 Aug 2012, Matt Sealey wrote:
> 
> > On Mon, Aug 6, 2012 at 5:36 PM, Nicolas Pitre <nico at fluxnic.net> wrote:
> > > On Mon, 6 Aug 2012, Matt Sealey wrote:
> > >
> > >> Right now there's already a fixed entry point - ARM kernels are fixed
> > >> entry point of relative 0 to the start of the loaded image. Okay, so
> > >> we can't format a totally valid ELF header, but in the event that we
> > >> want to encode all this information yet again, why reinvent the wheel?
> > >
> > > That's the point.  We do _not_ want to encode anything.
> > >
> > > By convention, if your CPU is ARM mode capable, then it must call the
> > > kernel in ARM mode, period.  Can't be simpler than that, right?  The
> > > bootloader shouldn't care if the kernel is itself ARM or Thumb, and the
> > > kernel shouldn't care if the bootloader is ARM or Thumb.
> > >
> > > If you have a real problem with this then let's hear it so it can be
> > > addressed.
> > 
> > I don't have a real *problem* with it, I just think since the kernel
> > can be compiled in both modes, but you may have some kind of remit to
> > not run ARM code (even if it's just a couple instructions at the
> > start) or some toolchain requirement or.. something.. it would be
> > entirely the bootloader's job to determine what mode it is in when it
> > jumps into the kernel. If you boot a Thumb bootloader and load an ARM
> > kernel, you'll get a crash. If you boot an ARM bootloader and a Thumb
> > kernel (with the current ARM instructions in head.S), you'll get a
> > crash. This is well defined, perfectly obvious, and I realise that..
> 
> And isn't it also rather silly?
> 
> History has told that the more "entirely the bootloader's job" we rely 
> on, the less reliable and interoperable we become.  Because you now have 
> to compile two kernels to fully validate your bootloader instead of only 
> one, and some people won't bother if the second kernel doesn't match 
> their own use case.
> 
> > But if you would need to micromanage the system such that they both
> > matched, or were perverse enough to build a Thumb bootloader and a
> > Thumb kernel, you might be counfounded that you actually created a
> > 99.99% Thumb bootloader which switched to ARM mode before going into
> > the kernel, and a 99.99% Thumb kernel but needed to jump into Thumb
> > mode after the first part of the kernel code?
> 
> I'm pragmatic enough to fully accept this impurity.
> 
> The x86 kernel does boot in 16-bit mode even if nobody compiles 16-bit 
> applications anymore.
> 
> > It should be possible (with that kernel config switch it would be) if 
> > you're into that kind of configurability to build your Thumb 
> > bootloader, build your Thumb kernel and have it never exit Thumb mode 
> > for any reason, even if it is just for some few bytes of very minor 
> > bootstrapping.
> 
> And what does this buy you?
> 
> > The same perfectly obvious caveats apply, but it's possible. The
> > question is, if you could do it, how would you make sure bootloaders
> > booted the right way? I would hazard a guess that given your opinion
> > on it, it would be just as good if they all just crashed.
> 
> Whereas right now it just works because the kernel is always entered in 
> ARM mode.
> 
> > So let's just patch out the ARM parts if you're building a Thumb
> > kernel on a Thumb-only device, and assume it was in Thumb mode all
> > along if another subordinate option was selected.. that way the kernel
> > can automatically fulfill one side of the contract in that you
> > configured "build thumb2 kernel" and it would contain 0% normal arm
> > code for ARMv7-M (or -R) and be able to be prompted to do so if you
> > were building for ARMv6k/ARMv7-A. Ordinary people would not turn it
> > on.. whacky weirdos like you and me might do it for proof of concept
> > ;)
> 
> No.  People will play with it as well and complain because their kernel 
> doesn't boot anymore.  We have enough real bug reports not to add to 
> them with futile ones.  And there are already way too many kernel config 
> options.
> 
> Some other people will hardcode Thumb mode entry in their bootloaders.  
> And if you wanted to compile your kernel in ARM mode for such a device 
> then you'd have the perverse need for a shim in Thumb mode at the 
> beginning of the kernel image to switch to ARM mode.
> 
> Whacky Weirdos can hack their kernel all they want.  That doesn't have 
> to be sanctioned in mainline.
> 
> > All it needs is a bootloader able to fulfill it's side of the contract
> > (build a thumb2 bootloader..) and jump while in Thumb mode, which I am
> > 100% certain exists. It'd be a 20 line patch maximum to make U-Boot do
> > this (it already can build as Thumb2 I think.. if not, there are
> > patches around) through an environment variable and distros that knew
> > they built in Thumb mode could simply modify the variable in boot.scr
> > or so, and the jump would end up being done in Thumb. That way you
> > have to kick it, but no changes are required in the kernel format
> > (just in the packaging of the kernel and configuration of the
> > bootloader). Guessing would be a bad idea...
> 
> The fewer contracts we have with bootloaders the better we are.  
> Unfortunately those contracts are increasing in scope.  Let's avoid the 
> really trivial cases if we can help it.
> 
> By mandating ARM mode, there is absolutely no guessing and no place for 
> misinterpretation, buggy implementation, or other silliness of which 
> bootloaders are full of.
> 
> The only good case for using Thumb mode in kernel entry is with those 
> CPUs with no support for ARM mode.
> 
> 
> Nicolas