ESP8266 Community Forum

- Sat Jun 13, 2015 3:12 am #20322 Moin,

It's a cool project of yours and a very interesting read.
I read that you reduced ram usage of the boot loader.
Is that memory still in use when boot finished work? If yes why?
The boot loader won't execute anymore and so it does not need it?

So I assume I miss or missunderstood something,
Cal

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG

- Sat Jun 13, 2015 3:23 am #20326 gcc allocates stack space to the boot loader, to minimise this i've used a stub function that delegates all the work (that that actually uses stack space) to a second function which is marked noinline. This keeps the amount of stack space reserved to the minimum possible. Same thing happens with the sdk bootloader, but they haven't made the same efforts to keep it to a minimum. I didn't know if this might get reset or anything once the sdk does its initialisation, but if you print out the stack address when you enter user_init, started from both rBoot and sdk bootloader, you should see the difference between them. This could be avoided if the boot loader was coded in assembler, but that would exclude most people from being able to play with it.

- Sat Jun 13, 2015 3:44 am #20327 I understand.
But since that stack frame is never been returned to it should be possible to reset a1 using only a minimum of inline asm and builtin unreachable. You don't care for the allocated stack frame of the current function anymore and just
set a1 to a fixed value or align it as needed.
And then jump to whatever place you want.
Yes thats gcc specific then for the source code but so what.

Cal

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG

- Sat Jun 13, 2015 3:51 am #20330 To start putting in inline assembler to modify the stack you have to make assumptions about what gcc is going to do with the stack. Making assumptions is dangerous and so you would want to verify the output assembler, which again is probably beyond most users. I've thought quite a bit about how to do this "properly" already, and couldn't come up with an acceptable, guaranteed solution. Pity, because I would have liked to eliminate this waste, but I'd rather produce something solid, even if it uses a few bytes of ram. It still uses a lot less than the sdk bootloader.