nallino:kernel: Change loadaddr to 0x80800000, speeds up relocation

Somehow the relocation is done with before switching on the caches which is very slow when the load address is too close to the final kernel location.

So ganz 100% verstanden hab ich den Code in „boot/compressed/head.S“ zwar nicht, aber es sieht so aus, als erwartet der Code am Anfang des phys. RAMs Platz, um eine MMU-Tabelle anlegen zu können (16KB) – die ist notwendig um MMU und Caches einschalten zu können – und überprüft dabei, in welchem Adressbereich der Code selbst gerade läuft. · Kommt er zu dem Schluss, dass da genug Platz ist, o schaltet er zuerst MMU und Caches ein, o verschiebt sich selbst, den komprimierten Kernel und den DTB mit allerlei Pointer-Anpassungen irgendwohin, wo er beim Auspacken nicht überschrieben werden kann o und erledigt dann das Entpacken. · Sind zwischen phys. Start des RAMs und laufendem Code weniger als 16KB + eine kleine Reserve von 1 MB (für schlechte Zeiten oder so…) Platz o Verschiebt sich der Code selbst, den komprimierten Kernel und den DTB mit allerlei Pointer-Anpassungen zuerst irgendwohin, wo er beim Auspacken nicht überschrieben werden kann o Startet sich selbst dann neu o Schaltet dann erst MMU und Caches ein o Und erledigt dann das Entpacken

Sprich: wird der gepackte Kernel irgendwo in die ersten gut 1MB des phys. RAM-Bereichs geladen und von da gestartet, läuft die ganze Relokation mit ausgeschalteten Caches, was auf dem 6ULL offenbar so langsam ist, dass es nur noch tröpfelt… (Da der 6ULL nur ein 16-Bit RAM Interface hat und mit abgeschalteter MMU keinerlei Caching, Buffering o.ä. stattfindet, müssten schon nur für einen einzigen 32-Bit RAM-Zugriff zwei vollständige DDR3-Lese-Bursts ausgelöst werden, die jeweils 8x16-Bit liefern (DDR3 RAM macht immer 8-fach Burst), wovon aber jeweils nur die ersten 16 Bit tatsächlich verwendet werden. Da kann man die Daten wohl genauso gut auch per Rauchzeichen übertragen…)

BCS 746-000387