the bpb is already bigger than that

depends on what the bootloader needs to do

Do you know what a bootloader is?

No he doesnt

Do you know what a bootloader is?

You know many arch exists?

but i like a p***y, and you?

but i like a p***y, and you?

doesnt make the task of writing a bl in 10bytes easier tbh

Don't use such words, thank you. And this coversation is going kinda ot

on avr mcu start execute code at specific address and enable a bootloader section. In her address you can call main function and exit to bootloader mode and have end ti write bootloader

'call a main function' stop doing as if it was that easy

On avr is very easy

'call a main function' stop doing as if it was that easy

doesn't it need to go through the libc __init procedure or something like that?

I'd love seeing him try, then again if i'd put my code location at the location the cpu expects, he'll call that a bootloader already, surely initialising an mcu is quite different from a bootchain where you'd need to call external storage to load a kernel

No

I have read somewhere that the main() method we write isn't the actual entry point of the application

How do you call the main function without loading akernel from disk?

disk is not necessary

I have read somewhere that the main() method we write isn't the actual entry point of the application

No?

No

How do you load the kernel then?

No?

You can load from flash, from nand, from network

He doesn't know the difference of firmware and os

You can call kernel from mcu bootloader, not in 10 byte 😂

He doesn't know the difference of firmware and os

True, its at least wrapped by a stub

uClinux what's this?

Still your start jump won't load it unless its internal, when it is internal its firmware, like romdos for example, but in that case you don't do bootstrapping

If uboot initializes linux, uboot is bootstrapping

You don't bootstrap a system sub 10 bytes, even if you'd recover a running image on atmels, it'll still need more

You are however trying to prove you can use less bytes on avrs because you don't agree c is not a macro assembler

Still, thats miles apart from an assembler nor does it verify your claims

generally all mcu bootloaders are very small

Correct, thats because they are meant to be used for specific appliances, not as generic computers

Actually running linux on them is quite stupid since you'd require far more advanced dies for doing the same easy shit

Actually running linux on them is quite stupid since you'd require far more advanced dies for doing the same easy shit

I can see your industrial failing background aproach, and given the stupid questions they ask i wouldn't say they're the brightest either, but how does any of that relate to your claim of c being a macro assembler and your disability to write bootcode in it compact enough to be used in a legacy bios bss?

so, C is only a big macro assembler because nothing happens behind the scenes. the speech of the bootloader not center

You went from there to avrs that can jump to firmware like any cpu does on startup, to ubooting uclinux on them; thats way beyond c emitting ml inefficiently enough not to be able to call it a macro assembler

If you'd just open a debugger

they had asked for a bootloader <100 bytes, not even specifying the language

the first compilers did not apply big optimizations, and the result was just 1:1 with the code written in C

Compiler is change in the years

No, they said i do an x86 bootloader in 200 bytes, go try that in C

No, they said i do an x86 bootloader in 200 bytes, go try that in C