linux-kernel - Arm Linux boot-up

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAJL-fBY1_EME-YZGDPd8+V_NRfAP75CHF1yHkznC1Nk2FoyZ-g@mail.gmail.com>
Date:   Thu, 5 Jul 2018 11:21:10 +0100
From:   dave frost <l3tdave@...il.com>
To:     linux-kernel@...r.kernel.org
Subject: Arm Linux boot-up

Morning folks,

As the title suggest im having issues geting my kernel started, and
was hoping for some guidance.

In short i think my problems come from the MMU/Cache configuration
being bad during the transfer from my boot loader to the kernel.

Just as a quick aside i have confirmed my kernel boots using UBoot.
but i wont be able to use uboot long term.

My bootloader executes in RAM at 0x3e000000. It places the kernel at
0x2200000 and the device tree at 0x30000000

I have definitely heeded the warnings about debugging head.S and can
verify this is not easy! I have added the following to head.S just
before the decompression routines are called.

debug_reloc_start
debug_reloc_end

During a bad bootup i get:

26B6CB50:00000000:00C5187D
00000000-268B463C>00000000
00000000
00000000: E59FF018 E59FF018 E59FF018 E59FF018   E59FF018
etc...

on a good boot up i get obviously better values:

22247A60:00000000:00C5187D
00000000:2200019C>20008000

00000000
20008000: 473C5655 473C5655 473C5655 473C5655   473C5655  ...
etc...

There is a bit more kputc statements in head.S but they re before the
pc is assigned to r0 and just after r4 gets its value.

Can someone out there confirm that this looks like im not configuring
(i.e. invalidating / emptying) the cache properly before jumping to
Linux?

Are there any other considerations that would cause this sort of
behaviour on arm platforms ?

Any or help or pointers very much appreciated.

Many thanks.
Dave Frost