Malban
Posts: 16
Joined: Thu Aug 01, 2019 6:16 pm

Need another pair of eyes - booting a kernel.img

Mon Jan 13, 2020 7:58 pm

Hi,

like many others before - amongst other things I programmed a bootloader.

The "boot" kernel of mine is a "normal" 0x8000 kernel, which again loads a secondary program (which I call loader) which is located way up in the memory range, so it is not overwritten by next "loads" (0xb00000).

The "loader" again displays a set of (now) 10 different kernels - which I can select and boot - and everything works fine.

In between I set up MMU, caches, fix the Mhz to 1000 (I am only talking about a Pi Zero....), and the UART port.

Still everything is fine - ...

Now! I want to boot the "original" linux kernel - which I renamed to "linux.img".
To be able to do that I remembered the "orginal" start parameters given by "start.elf" (register r0, r1 and r2).
R2 pointing to the parameter list, which strangely lies at address "0x1BFE9C00", but doing memory dump, that seems to be ok (was sort of expecting 0x100).

I load the kernel, and clear all caches, prefetches etc..., switch off MMU, disable caching, switch the MHZ back to 700, and finaly ensure the register contents of r0-r2 is correct.

Than I jump to 0x8000 (where I loaded the kernel to) - and nothing happens.
Well probably something -but no booting... and no reaction whatsoever.

I looked at several other boot loaders, e.g. "raspbootin", there it is especially straight forward:

Code: Select all

   
     entry_fn fn = (entry_fn)0x8000;
     fn(r0, r1, atags);
I do exactly same + all the "resetting" before.

A second pair of eyes may tell me where I am wrong, here the code (further down below):

(I take it for granted - due to memory dump - that at 0x8000 the kernel defenitly resides!)
(Also memory location 0x80, 0x84, 0x88 contain the correct contents of r0,r1,r2 - they were loaded upon start directly after start.elf.
Also I printed them out and they make sense: This dump was done directly at the start of the kernelStart() function (code removed) to
ensure the values are still in order.
The library function seen do work, tested on many other occasions (mhz setting) )

Code: Select all

R0: 0
R1: C42
R2: 1BFE9C00

1BFE9C00: ED 00 00 63 18 00 00 00 48 00 00 59 6C 00 00 00 ...c....H..Yl...
1BFE9C10: 28 00 00 00 11 00 00 00 10 00 00 00 00 00 00 09 (...............
1BFE9C20: AC 00 00 59 24 00 00 00 00 00 00 00 00 00 00 00 ...Y$...........
1BFE9C30: 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 ................
1BFE9C40: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
1BFE9C50: 03 00 00 00 08 00 00 09 7A 1C 00 00 00 04 00 00 ........z.......
1BFE9C60: 00 00 00 00 03 00 00 00 11 00 00 09 6C 30 30 30 ............l000
1BFE9C70: 30 30 30 30 30 39 39 39 35 39 62 33 33 00 2D 7A 0000099959b33.-z
1BFE9C80: 65 00 00 00 03 00 00 00 26 00 00 00 00 72 61 73 e.......&....ras
1BFE9C90: 70 62 65 72 72 79 70 69 2C 6D 6F 64 65 6C 2D 7A pberrypi,model-z
1BFE9CA0: 65 72 6F 2D 77 00 62 72 63 6D 2C 62 63 6D 32 38 ero-w.brcm,bcm28
1BFE9CB0: 33 35 00 00 00 00 00 00 03 00 00 00 1C 00 00 00 35..............
1BFE9CC0: 0B 52 61 73 70 62 65 72 72 79 20 50 69 20 5A 65 .Raspberry Pi Ze
1BFE9CD0: 72 6F 20 57 20 52 65 76 20 31 2E 31 00 00 00 00 ro W Rev 1.1....
1BFE9CE0: 03 00 00 00 04 00 00 00 11 00 00 00 01 00 00 00 ................
1BFE9CF0: 03 00 00 00 04 00 00 00 22 00 00 00 01 00 00 00 ........".......
1BFE9D00: 03 00 00 00 04 00 00 00 31 00 00 00 01 00 00 00 ........1.......
1BFE9D10: 01 73 79 73 74 65 6D 00 00 00 00 00 03 00 00 00 .system.........
1BFE9D20: 08 00 00 09 94 00 00 00 00 99 95 9B 33 00 00 00 ............3...
1BFE9D30: 03 00 00 00 04 00 00 09 85 00 90 00 C1 00 00 00 ................
1BFE9D40: 02 00 00 00 01 61 78 69 00 00 00 00 01 76 63 5F .....axi.....vc_
1BFE9D50: 6D 65 6D 00 00 00 00 00 03 00 00 00 0C 00 00 01 mem.............
1BFE9D60: 4A 1E C0 00 00 20 00 00 00 40 00 00 00 00 00 00 J.... [email protected]
1BFE9D70: 02 00 00 00 02 00 00 00 01 61 6C 69 61 73 65 73 .........aliases
1BFE9D80: 00 00 00 00 03 00 00 00 12 00 00 09 46 2F 73 6F ............F/so
1BFE9D90: 63 2F 69 32 63 40 37 65 38 30 34 30 30 30 00 34 c/[email protected]
1BFE9DA0: 30 00 00 00 03 00 00 00 12 00 00 09 42 2F 73 6F 0...........B/so
1BFE9DB0: 63 2F 69 32 63 40 37 65 38 30 34 30 30 30 00 34 c/[email protected]
1BFE9DC0: 30 00 00 00 03 00 00 00 12 00 00 09 2B 2F 73 6F 0...........+/so
1BFE9DD0: 63 2F 69 32 63 40 37 65 32 30 35 30 30 30 00 34 c/[email protected]
1BFE9DE0: 30 00 00 00 03 00 00 00 15 00 00 00 3D 2F 73 6F 0...........=/so
1BFE9DF0: 63 2F 73 65 72 69 61 6C 40 37 65 32 31 35 30 34 c/[email protected]
1BFE9E00: 30 00 00 00 00 00 00 00 03 00 00 00 15 00 00 00 0...............

Code: Select all


#define isb() asm volatile ("mcr p15, #0, %[zero], c7, c5,  #4" : : [zero] "r" (0) )
#define dsb() asm volatile ("mcr p15, #0, %[zero], c7, c10, #4" : : [zero] "r" (0) )
#define dmb() asm volatile ("mcr p15, #0, %[zero], c7, c10, #5" : : [zero] "r" (0) )

#define invalidate_instruction_cache()	asm volatile ("mcr p15, #0, %[zero], c7, c5,  #0" : : [zero] "r" (0) )
#define flush_prefetch_buffer()		asm volatile ("mcr p15, #0, %[zero], c7, c5,  #4" : : [zero] "r" (0) )
#define flush_branch_target_cache()	asm volatile ("mcr p15, #0, %[zero], c7, c5,  #6" : : [zero] "r" (0) )

#define invalidate_data_cache()		asm volatile ("mcr p15, 0, %0, c7, c6,  0\n" \
						      "mcr p15, 0, %0, c7, c10, 4\n" : : "r" (0) : "memory")
#define clean_data_cache()		asm volatile ("mcr p15, 0, %0, c7, c10, 0\n" \
  						      "mcr p15, 0, %0, c7, c10, 4\n" : : "r" (0) : "memory")	
	
	
#define ARM_CONTROL_MMU				(1 << 0) // MMU
#define ARM_CONTROL_STRICT_ALIGNMENT		(1 << 1) // Alignment
#define ARM_CONTROL_L1_CACHE			(1 << 2) // D Cache
#define ARM_CONTROL_BRANCH_PREDICTION		(1 << 11)
#define ARM_CONTROL_L1_INSTRUCTION_CACHE 	(1 << 12)

#define MMU_MODE	(  ARM_CONTROL_MMU			\
			 | ARM_CONTROL_L1_CACHE			\
			 | ARM_CONTROL_L1_INSTRUCTION_CACHE	\
			 | ARM_CONTROL_BRANCH_PREDICTION)

			 
void mmu_disable(void) 
{
  dsb();
  invalidate_instruction_cache();
  flush_prefetch_buffer();
  flush_branch_target_cache();
  invalidate_data_cache();
  clean_data_cache();

  // disable MMU
    uint32_t control;
    asm volatile ("mrc p15, 0, %0, c1, c0,  0" : "=r" (control));
    control = control & (~MMU_MODE);
    asm volatile ("mcr p15, 0, %0, c1, c0,  0" : : "r" (control) : "memory");
    asm volatile ("nop " );
    asm volatile ("nop " );
}


static inline void kernelStart()
{
  // clock
  lib_bcm2835_vc_set_clock_rate(BCM2835_VC_CLOCK_ID_ARM, 700000000);

  // MMU and caches
  mmu_disable();
  
  // correct start registers and jump to 8000
  __asm__ __volatile__(
      "mov r5, #0x0080   \n\t"
      "str r0, [r5]      \n\t"
      "mov r5, #0x0084   \n\t"
      "str r1, [r5]      \n\t"
      "mov r5, #0x0088   \n\t"
      "str r2, [r5]      \n\t"
      "ldr pc, = 0x8000   \n\t"
	 );
}
Can anyone see where I went wrong?

Thx for the time....

Regards

Malban

LdB
Posts: 1365
Joined: Wed Dec 07, 2016 2:29 pm

Re: Need another pair of eyes - booting a kernel.img

Mon Jan 13, 2020 10:39 pm

Have you released the framebuffer?

See my discussion about trying to do a splash screen in a baremetal bootloader prior to linux kick
https://www.raspberrypi.org/forums/view ... 6&t=259681

The load probe for the screen driver counts the framebuffers and hangs if they aren't all there
https://github.com/raspberrypi/linux/bl ... m2708_fb.c
It basically writes a log entry and then deadloops if you still have an active framebuffer

So if you were displaying stuff before you try to kick the kernel you have to release the framebuffer before you attempt to kick the linux loader. Unfortunately for what I was trying to do that promptly clears the screen to black :-)

User avatar
rahealy
Posts: 17
Joined: Thu Dec 19, 2019 5:30 pm

Re: Need another pair of eyes - booting a kernel.img

Tue Jan 14, 2020 1:31 am

Greetings,

Does the linux kernel you're trying to load and boot match the architecture that your bootloader was compiled for? I was thinking that maybe things wouldn't work well if your bootloader was compiled as ARM6 (kernel.img) and the kernel was compiled as ARM7 (kernel7.img) or similar.

Regards,

-Richard

Malban
Posts: 16
Joined: Thu Aug 01, 2019 6:16 pm

Re: Need another pair of eyes - booting a kernel.img

Tue Jan 14, 2020 8:17 am

Hi,

thx for your answers:

@LdB:
I never use a framebuffer. Output "before" is done via GPIO ports (and UART) on a Terminal or a vectrex.

(For info on our project look at:
http://computernerdkev.heliohost.org/pi ... /index.php

and a video of last week:
https://www.youtube.com/watch?v=ALQ7toy ... 2bk0h00410
)
So I don't think that might be "it".

@raheaky:
Yes, the linux.img works fine. If I just rename it to kernel.img - it boots up like it should.

Malban

Malban
Posts: 16
Joined: Thu Aug 01, 2019 6:16 pm

Re: Need another pair of eyes - booting a kernel.img

Tue Jan 14, 2020 9:01 am

While looking at my original post, I can't help to wonder about the "atag" pointer (R2).

It points to a little "obscure" memory location 0x1BFE9C00.
The dump you see seems to contain amongst other some command line text.

But - looking at an atag example (http://www.simtec.co.uk/products/SWLINU ... te_example)...

Shouldn't the dump than contain some sort of ATAG "values"?

Code: Select all

/* list of possible tags */
#define ATAG_NONE       0x00000000
#define ATAG_CORE       0x54410001
#define ATAG_MEM        0x54410002
#define ATAG_VIDEOTEXT  0x54410003
#define ATAG_RAMDISK    0x54410004
#define ATAG_INITRD2    0x54420005
#define ATAG_SERIAL     0x54410006
#define ATAG_REVISION   0x54410007
#define ATAG_VIDEOLFB   0x54410008
#define ATAG_CMDLINE    0x54410009

Code: Select all

1BFE9C00: ED 00 00 63 18 00 00 00 48 00 00 59 6C 00 00 00 ...c....H..Yl...
1BFE9C10: 28 00 00 00 11 00 00 00 10 00 00 00 00 00 00 09 (...............
...
Even if I do not swirl my head around some "endian" conversion - I can see that there is no ATAG....

Clues?

Malban

Malban
Posts: 16
Joined: Thu Aug 01, 2019 6:16 pm

Re: Need another pair of eyes - booting a kernel.img

Tue Jan 14, 2020 9:16 am

Actually staring further at the dump...
This looks sort of a device tree to me.

Can a device tree passed to the kernel instead of a ATAG list?

Malban
Posts: 16
Joined: Thu Aug 01, 2019 6:16 pm

Re: Need another pair of eyes - booting a kernel.img

Tue Jan 14, 2020 9:26 am

yes - seems this is "normal"...

see:
https://www.raspberrypi.org/documentati ... ce-tree.md
...

Gee still everything seems to be alright :-( - it just does not work...

User avatar
Ultibo
Posts: 160
Joined: Wed Sep 30, 2015 10:29 am
Location: Australia
Contact: Website

Re: Need another pair of eyes - booting a kernel.img

Tue Jan 14, 2020 9:28 am

Malban wrote:
Tue Jan 14, 2020 9:16 am
Can a device tree passed to the kernel instead of a ATAG list?
Since recent firmware versions, Raspberry Pi always passes device tree information to the kernel unless you take explicit steps to ensure ATAGs.

Current versions of Raspbian only work with device tree and will fail if passed ATAGs.
Ultibo.org | Make something amazing
https://ultibo.org

Threads, multi-core, OpenGL, Camera, FAT, NTFS, TCP/IP, USB and more in 3MB with 2 second boot!

LdB
Posts: 1365
Joined: Wed Dec 07, 2016 2:29 pm

Re: Need another pair of eyes - booting a kernel.img

Tue Jan 14, 2020 1:26 pm

I went thru all this nightmare to get the linux kernel to bootstrap on the PiZeroW and I am home now so one sec let me look at what I had to do

r0 contained 0 (not sure it is absolutely needed)
r1 must contain 3138 (they call it machine id decimal not hex)
r2 must contain the device tree pointer which you already found

There is also a special uint32_t at 0xf0 which must contain 0x5afe570b.
No idea what is does but when I debugged the loader it checks for that and did a weird branch and did something funny if it doesn't find it. It worried me so I put it in.

That was it from there the PiZeroW loaded once I released the framebuffer :-)

Malban
Posts: 16
Joined: Thu Aug 01, 2019 6:16 pm

Re: Need another pair of eyes - booting a kernel.img

Tue Jan 14, 2020 2:40 pm

I'll try tonight, when I am at home.

When you speak of "loader", do you men the "decompression" header as in:
https://github.com/raspberrypi/linux/bl ... sed/head.S

or the actual kernel startup as in:
https://github.com/raspberrypi/linux/bl ... nel/head.S

In neither "official" sources I see that test - but I did not disassemble my actual kernel.img.

How did you do your debugging - qemu?
Haven't tried that yet - since I fear booting the multiple "loaders" of mine will be a hassle to setup.

Cheers
Malban

LdB
Posts: 1365
Joined: Wed Dec 07, 2016 2:29 pm

Re: Need another pair of eyes - booting a kernel.img

Tue Jan 14, 2020 2:50 pm

Debugged kernel.img first in QEMU and then once I got a little way in I added my own debugger code to the back of the file and jumped there by hex editing kernel.img. None easy or clean but it was all paid for because it was a commercial job. I haven't done much with linux before but it was fun and worked really well as like a kiosk app, the USB touchscreen was the worst to code.

User avatar
rahealy
Posts: 17
Joined: Thu Dec 19, 2019 5:30 pm

Re: Need another pair of eyes - booting a kernel.img

Tue Jan 14, 2020 4:25 pm

Malban wrote:
Tue Jan 14, 2020 8:17 am
Hi,

thx for your answers:

@raheaky:
Yes, the linux.img works fine. If I just rename it to kernel.img - it boots up like it should.

Malban
Is your bootloader also named kernel.img? If not what is it named?

[Edit - Additional Question:]
When you say you rename the file and the kernel works does that mean the RPi software boots the kernel or your bootloader boots the kernel?

Thank you,

-Richard
Last edited by rahealy on Tue Jan 14, 2020 6:40 pm, edited 1 time in total.

gtoal
Posts: 113
Joined: Sun Nov 18, 2012 12:02 am

Re: Need another pair of eyes - booting a kernel.img

Tue Jan 14, 2020 6:39 pm

LdB wrote:
Tue Jan 14, 2020 1:26 pm
I went thru all this nightmare to get the linux kernel to bootstrap on the PiZeroW and I am home now so one sec let me look at what I had to do

r0 contained 0 (not sure it is absolutely needed)
r1 must contain 3138 (they call it machine id decimal not hex)
r2 must contain the device tree pointer which you already found

There is also a special uint32_t at 0xf0 which must contain 0x5afe570b.
No idea what is does but when I debugged the loader it checks for that and did a weird branch and did something funny if it doesn't find it. It worried me so I put it in.
using that magic number (.word 0x5afe570b @ magic value to indicate firmware should overwrite atags and kernel) as a hint for searching, I found this post: https://leiradel.github.io/2019/01/20/R ... Stubs.html (and a previous post, https://leiradel.github.io/2019/01/06/SmartStart.html ) - are these helpful for this problem? refers to the code in https://github.com/raspberrypi/tools/tr ... r/armstubs

LdB
Posts: 1365
Joined: Wed Dec 07, 2016 2:29 pm

Re: Need another pair of eyes - booting a kernel.img

Wed Jan 15, 2020 12:51 am

You have to copy the kernel.img to exactly 0x8000 when you want to boot it can't have a different address :-)

Even in your code you have absolute addresses look at this line of code

Code: Select all

 ldr r3, =_kernelLoad 
r3 has a absolute address that wont work if you move the code

I did pretty much what you did put my code in first and then incbin'ed the kernel.img file behind and made my own bigger kernel.img file which the VC lifts into place.

On entry I save the registers like you did to that area between 0x0 and 0x80000, set my heap end at the device table entry address so that didn't get overrun and then copied a memory shuffler code to 0x5000

So this is my C macro to incbin the file into a special section its just inline assembles the incbin call and places tag at top and bottom of section

Code: Select all

#if !defined(__STRINGIFY2)
#define __STRINGIFY2(__p) #__p
#define __STRINGIFY(__p) __STRINGIFY2(__p)
#endif

#define INCLUDE_BINARY_FILE(__variable, __fileName, __section)					 \
__asm__ (                                                                        \
    ".pushsection " __section                                          "\n\t"    \
    ".globl " __STRINGIFY(__variable) "_start;"                        "\n\t"    \
    ".balign 4"                                                        "\n\t"    \
    __STRINGIFY(__variable) "_start: .incbin \"" __fileName "\""       "\n\t"    \
    ".globl " __STRINGIFY(__variable) "_end;"		                   "\n\t"    \
    __STRINGIFY(__variable) "_end: .4byte 0;"                          "\n\t"    \
    ".balign 4"                                                        "\n\t"    \
    ".popsection"                                                      "\n\t"    \
);\
extern const uint8_t __variable ## _start;\
extern const  uint8_t __variable ## _end;
The normal linx kernel.img I copied as linux_kernel.img and I use the macro anywhere in Main to incbin that file into a rodata section which the linker places after all my code but before the heap. You could just use .rodata but I wanted to see it in map file.
I get its size by subtracting tag start from end to check it worked ... that size should match the exact kernel.img file size.

Code: Select all

INCLUDE_BINARY_FILE(linux, "linux_kernel.img", ".rodata.linux");
uint32_t kernelsize = (uint32_t)&linux_end - (uint32_t)&linux_start; 
Then I copy code that essentially does this in C to 0x5000. So in assembler r0 is source address, r1 is copy size.

Code: Select all

void BootLoad(uint32_t src, uint32_t size)
{
        volatile uint32_t* p = (uint32_t*)0x8000;
	volatile uint32_t* q = src;
	while (size > 0)
	{
		*p++ = *q++;
		size --;
	}
	/* code that restores your registers */
	__asm volatile("mov pc, #0x8000");
}
Then I type define a function and set a function pointer using that type to 0x5000

Code: Select all

typedef (*BootLoadFn)(uint32_t src, uint32_t size);
BootLoadFn BootLoad = (BootLoadFn)0x5000;
So I run off do whatever I want in my normal C code and then when I want to kick the linux kernel

Code: Select all

BootLoad((uint32_t)&linux_start, linux_size);
You should get what happens it moves the linux kernel back to 0x8000 and then sets the PC to 0x8000 and off it goes.

Malban
Posts: 16
Joined: Thu Aug 01, 2019 6:16 pm

Re: Need another pair of eyes - booting a kernel.img

Wed Jan 15, 2020 1:32 am

SUCCESS!

It works now - but it is 2:30 o'clock in the night.

I will write more explanation tomorrow!

Thx!

Malban

LdB
Posts: 1365
Joined: Wed Dec 07, 2016 2:29 pm

Re: Need another pair of eyes - booting a kernel.img

Wed Jan 15, 2020 5:34 am

Why do I have the feeling you did it the hack way and replaced a few bytes at the front and jumped to your code at the back which puts the original bytes back :-)

Malban
Posts: 16
Joined: Thu Aug 01, 2019 6:16 pm

Re: Need another pair of eyes - booting a kernel.img

Wed Jan 15, 2020 9:32 am

Nope... no hacky way :-).

Tonight - when I have more time - I will write everything down, and probably do a blog post or something.

Following is true for the linux kernel image I use, which I downloaded as a full raspberry Pi installation from the official site (non NOOBS) on January 10th. 2020.
I have not altered the cmndline.txt or config.txt in my setup.

a) in response to your last messages (@LdB)
The file: kernel.img (Linux) is position independend - you can load it to any address you like.
The only restriction is not to overwrite the Device Tree blob, and if you have the MMU active, do not overwrite the page table.

The kernel.img consists of a decompression header, which is written position independend and which unpacks the "final" linux kernel to a place where it deems it save. You have to pass the mentioned r0,r1,r2 registers to the decompressor - so that in turn that one can later pass the information on to the kernel itself.

I have found many references on the net, that when starting the kernel you have to do so with a "clean" setup (no MMU, caches flushed, default 700Mhz etc.)
In my "final" version I leave all that enabled, when I start the "decompressor" and it works like a charm. It might be, that the kernel itself needs these default settings, if it is so - than the decompressor takes care of that.

Why didn't my previous version run?

The answer is twofold:

a)

The version of sources I posted in my first posting had a "bug":

Code: Select all

  __asm__ __volatile__(
      "mov r5, #0x0080   \n\t"
      "str r0, [r5]      \n\t"
      "mov r5, #0x0084   \n\t"
      "str r1, [r5]      \n\t"
      "mov r5, #0x0088   \n\t"
      "str r2, [r5]      \n\t"
      "ldr pc, = 0x8000   \n\t"
	 );
This - of course does not set the correct values to the registers r0 - r2, this STORES the entry of the registers, it should read:

Code: Select all

  __asm__ __volatile__(
      "mov r5, #0x0080   \n\t"
      "ldr r0, [r5]      \n\t"
      "mov r5, #0x0084   \n\t"
      "ldr r1, [r5]      \n\t"
      "mov r5, #0x0088   \n\t"
      "ldr r2, [r5]      \n\t"
      "ldr pc, = 0x8000   \n\t"
	 );
This was a simple copy/paste error.

If I had not done that stupid copy/paste error (late night work...) - everything I had done would have worked out of the box.

b)
Now... during my debugging I had the kernel.img as a binary include with my startup files.
And with that debugging code I HAD the above code correct! Nonetheless after jumping to my main program - the loader did again not work...
But this was an alltogether different bug:

The second "bug" I had was... (which was quite difficult to find)
I use parts of the https://github.com/vanvught/rpidmx512 library.

And one of the first things I do, is to print out the current speed settings of the ARM. For that I use the library function:

Code: Select all

    
    int32_t arm_clock = lib_bcm2835_vc_get_clock_rate(BCM2835_VC_CLOCK_ID_ARM); 
Within that function the mailbox is called, and the mailbox is passed a structure, which it fills.
That structure is at a memory address defined somewhere in some header... which turned out to be:

Code: Select all

#define MEM_COHERENT_REGION		0x400000	///< 
And that given address is actually right WITHIN the region the binary included kernel lies - so the decompression resulted in an error.

So finaly:

I did a stupid copy/paste mistake in my first code. During my search - I added another buggy code (well - "buggy" is a hard word hear, I only use the library... and do not know it by heart. So the fixed "MEM_COHERENT_REGION" memory region was not really in front of my eyes...)...

But now it works and I can load the original kernel and it boots up.

Malban

User avatar
rahealy
Posts: 17
Joined: Thu Dec 19, 2019 5:30 pm

Re: Need another pair of eyes - booting a kernel.img

Wed Jan 15, 2020 8:39 pm

Malban wrote:
Wed Jan 15, 2020 9:32 am
Nope... no hacky way :-).
...
But now it works and I can load the original kernel and it boots up.

Malban
I'm glad you got it working! Thank you for posting the solution. I learned a lot from this thread.

Best Wishes,

-Richard

Return to “Bare metal, Assembly language”