bootloader | USB Bootloader for Spark Firmware | Change Data Capture library

You are leaving loop1 when ah is not less than 0xff anymore.
The term less/greater is used in x86 assembly when signed numbers are compared. Number 0xff treated as signed 8bit integer has the value -1 and ah as signed byte (-128..+127), starts at 0x0f + 0x10 = 0x1f. And 31 < -1 is false on the first iteration, so loop1 is abandoned after the first call procedure1.

When comparing unsigned numbers we use term below/above. Instead of jl loop1 use jb loop1. Similary in procedure1: replace jl procedure1 with jb procedure1. (https://www.felixcloutier.com/x86/jcc)

When I do this, the microcontroller ejects from my computer. Is that meant to happen? It just reboots then doesn't reboot in bootloader?

Yep.

but the light on the board isn't blinking.

Maybe your LED is busted, cause your code is right.

My end goal is to write arbitrary text data to flash storage

That's a terrible idea, unless you just like burning up boards for no good reason. Get an SD Card reader or concoct one out of a solution like this one, and use this sdcard library that will even mount your card, and add it to the syspath. Then you can essentially write all the arbitrary text data you like without burning up your RP2040.

Some problems:

a) The BIOS "read disk sector/s" function requires a segment (in ES) and an offset (in BX). You aren't providing an offset (not setting BX to anything) so there's no sane way to guess where the BIOS might load the sector (it could be anywhere within the 64 KiB segment requested by ES).

b) Regardless of how sector is created, it can't be a segment (for the mov ax, sector, mov es, ax) and also be an "offset in the current code segment" (for jmp sector), so one of them must be wrong. For "sector = 0x1000" it looks like it was supposed to be an "offset in current code segment" (and that the code to read the sector should set ES to 0x07C0 to match the assumed current code segment and do mov bx,sector to treat sector as an offset in the requested segment).

c) I'd strongly recommend setting segments to zero wherever possible. This helps to avoid confusion and mistakes (especially for beginners) and makes it much easier to switch to/from protected mode (or long mode) later. To do this you would need to use org 0x7C00 (rather than "implied org 0 because it wasn't explicitly set") in addition to changing segment register loads (e.g. mov ax, 07C0h, mov es,ax would become mov ax, 0, mov es,ax). This would include the stack (where I'd recommend using "SS:SP = 0:0x7C00"). Don't forget that the stack segment limit often doesn't actually limit anything - e.g. a push or call when the stack is "full" just causes SP to overflow and wrap around from 0x0000 to 0xFFFE.

d) Resetting the disk system shouldn't be necessary before trying to read sector/s the first time (as you know the BIOS successfully read your boot loader and the disk system is working fine). It should only be used as an attempt to recover from disk errors. Note that (for floppy disks) resetting the disk system typically means recalibrating the drive which involves sending the heads back to "track 0".

e) When there's errors reading from disk, sometimes they're temporary (e.g. due to floppy drive motor speed variations) and sometimes they aren't (e.g. "bad parameters", "floppy disk ejected", etc). Retrying several times (and resetting the disk system occasionally between attempts) is recommended for working around temporary problems (especially for floppy disks). Slamming the disk heads back and forth forever (with "reset/recalibrate, seek/read, reset/recalibrate, seek/read, ...) is an extremely bad way to deal with persistent problems. You need a counter to track how many times you've retried so that you can stop after a limited amount of attempts and display an error message. Don't forget that BIOS returns an error code, and using that error code to determine which error message to display can help you find bugs and also help normal users figure out what to do when there's a problem (e.g. if it's faulty hardware/dodgy floppy disk or a software bug).

f) You have control flow problems. Specifically, you call reset but that code has no ret and falls through into the read_sector code; so call reset won't return unless the BIOS successfully reads the sector, and there's no point doing the call read_sector after the sector was already successfully read.

g) If the read_sector code succeeds it will fall through to the code to print a string. Your code to print a string (the printf routine) will get characters from the memory at the address contained in DS:SI, but SI is never set to anything in the 1st sector (before its executed) so it will probably only ever print a random/undefined mess (most likely case is that the byte at the unknown address happens to be zero and nothing is printed). Also; after reading a byte with lodsb SI will either be incremented or decremented depending on how the "direction flag" was set. Your code doesn't set the direction flag to anything (e.g. no cld instruction anywhere); which means that there's an extremely small chance that your code might print a random string backwards ("!dlroW olleH"). I don't know if you intended to have a ret after the code to read a sector, or if you intended to set DS:SI to the address of a "2nd sector loaded!" string (I assume the former because there's no string in the 1st sector).

h) The contents of the second sector starts with a string ("now there is a different message!"). If there were no other bugs, call sector (in 1st sector) would have caused this string to be executed and not valid code (likely causing a spectacular crash of some sort). You want to either move the string somewhere else (after the code in the second sector) or jump to the code directly (e.g. a jmp sector2_code in the 1st sector and a sector2_code: label before the mov si, message instruction).

i) The BIOS function you're using to read sectors mostly doesn't work for hard disks (modern hard disks are simply too big - there's an "extended disk read" function you'd want to use instead). For floppy disks you can't use the "extended disk read" function (and have to use the BIOS function that you are using). For other cases (booting from USB flash, booting from a CD configured to emulate something) you will need either a "BIOS Parameter Block" (see https://en.wikipedia.org/wiki/BIOS_parameter_block ) for floppy and floppy emulation, or a partition table (for hard disk or hard disk emulation). For actual real floppy disks, the "BIOS Parameter Block" is technically optional (originally part of the FAT file system and nothing to do with the BIOS at all), but it's common for other operating systems (Windows) to complain about the disk not being valid/formatted if there is none (which really confuses normal users).

j) Windows is malware that can/will corrupt 4 bytes in the first sector of a disk (in the middle of your boot sector's code), even though Windows has no right to tamper with competing operating system's disks or boot loaders. Specifically, Microsoft decided that Windows should use a unique disk signature to identify disks, so when Windows first sees a disk it will try to fetch this unique signature and if the value isn't unique it will write a new "unique" value at offset 0x01B8 in the first sector. Note that this behaviour was "retro-actively" included in the UEFI specs in the section relating to (the "protective MBR" part of) the GPT partitioning scheme (where it doesn't apply to unpartitioned disks, MBR partitioned disks or people using BIOS instead of UEFI); and in the UEFI specs it's considered optional (the literal words are "This may be used by the OS...") and there's no clear guidance of which OS (yours or Microsoft's ) gets to decide if the signature is present or not (or how the signature should be generated to allow operating systems to agree on a "unique" value and prevent it from being modified every time a different OS sees the disk). In any case; you want to avoid using the 4 bytes at offset 0x01B8 in your boot sector to defend yourself from Windows.

like @jester commented your question. You seem to compile your bootloader as .code32. Your CPU(qemu or any other VM) won't boot it, cause CPU originally runs in 16bit mode. Please take a look here - JOS bootloader . This is minimalistic bootloader you might learn from.

Ok it's seems that it is impossible to write two time in a row at the same adress, i've read somewhere that we are only allow to switch a bit from 1 to 0 if we want to write multiple time without erasing. I moved my "shared area" in a specific sector that I have to erase each time I want to write on it.

My problem is solved.

If you have the following code:

nasm -fbin print.asm reveals the actual line number, 11.

int bx isn't an instruction. Typo for inc.

I think NASM's line number after a %include is probably overall line since the start of the main file, which is a bug in NASM 2.15.05 (at least). In this case your file can assemble separately to see what's wrong, but other cases would be less easy. The bug has already been fixed in NASM 2.16rc0, and may get backported to 2.15.xx. https://bugzilla.nasm.us/show_bug.cgi?id=3392731

Apparently this also affects debug info line-numbering. e.g. for setting breakpoints in GDB by source line number. It of course always works to b *0x1234 with a copy-pasted address from disas output, that doesn't care about debug info.

yasm -fbin bootloader.asm gets the line numbering correct: print.asm:11: ... with the same invalid combo message as NASM. That's from yasm 1.3.0. Unfortunately YASM isn't being developed anymore (?), and hasn't kept up with new instructions like AVX-512, but it's usable for stuff like bootloaders.

The bug is also not present in some older versions of NASM, for example 2.11.05 from 2014 reports print.asm:11. I don't have versions between that kicking around to bisect when this bug was introduced.

I finally got it working by inverting the MSI-X table structure found on osdev.org. I decided to completely reinitialize the xHC after leaving the UEFI environment as it could leave it in an unknown state. Here's the xHCI code for anyone wondering the same thing as me:

Your load_idt function is written as a 32-bit function where the first parameter is passed on the stack. In the 64-bit System V ABI the first parameter is passed in register RDI. Use this instead: