Merging code with arch condition into head.S

Rafał Miłecki zajec5 at gmail.com
Thu Aug 18 07:19:07 PDT 2016


On 18 August 2016 at 15:47, Andrew Lunn <andrew at lunn.ch> wrote:
> On Thu, Aug 18, 2016 at 03:23:41PM +0200, Rafa?? Mi??ecki wrote:
>> On 18 August 2016 at 12:47, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> > On 18 August 2016 at 12:35, Rafa?? Mi??ecki <zajec5 at gmail.com> wrote:
>> >> I'd like to ask for help with writing my arcm/arm/boot/compressed/head-foo.S.
>> >>
>> >> There is probably a bug in bootloader on *a lot* market-available
>> >> devices that needs a very early fix executed during decompression. If
>> >> we don't implement it, Broadcom Northstar devices hang in 25% of tries
>> >> and BCM53573 devices don't boot at all.
>> >>
>> >
>> > Could you elaborate on the nature of the fix?
>>
>> I'm not ARM expert and I don't have any Broadcom datasheets, so I have
>> a very little view of the issue. It seems that to make booting
>> reliable, I have to clear 2 following bits in the SCTLR register:
>> #define CR_M (1 << 0) /* MMU enable */
>> #define CR_C (1 << 2) /* Dcache enable */
>> and then invalidate the cache.
>
> So it leaves the caches enabled?
>
> Been there, done that. This is violating the boot loader contract to
> the kernel at start time. There are a couple of Marvell Kirkwood
> systems what have this problem, and it was extensively discussed at
> the time. Basically, it is too late to fix by the time the kernel has
> started running. The kernel is already corrupt.
>
> https://lists.debian.org/debian-arm/2012/08/msg00128.html
> https://patchwork.kernel.org/patch/3427771/
>
> You need to find another solution, e.g. in intermediate boot loader,
> or do what Debian does and append a few instructions to the kernel
> when it is installed on a hardware with this issue.

Oh, that looks bad. Thanks a lot for the links, discussion on Jason's
patch was very helpful to understand the problem. I guess I'm quite
out of luck here :(

I think I'll stick to the modified (out of tree) kernel for now, maybe
in a long term this intermediate loader could be a good idea. Did you
ever see solution like this? I never wrote my own loaders, so it'd
take me quite some time to learn required things.

-- 
Rafał



More information about the linux-arm-kernel mailing list