Re: Multiboot Bootloaders

[john via rockbox-dev]

> We have had the commits for Bootdata and Multiboot functionality for a
> number devices up on gerrit for ~6 months now
> 
> By putting the multiboot bootloader in the mainline this will allow users
> with failing flash a way to still use their device or even to always run
> from their sd card

As I own at least one Sansa with defect flash I appreciate this very much.

cu
John

Re: Multiboot Bootloaders

[Wilgus William via rockbox-dev]

We have had the commits for Bootdata and Multiboot functionality for a
number devices up on gerrit for ~6 months now

By putting the multiboot bootloader in the mainline this will allow users
with failing flash a way to still use their device or even to always run
from their sd card

It also opens the possibility of having firmware for several different
devices on a single sd card.

If there aren't any objections I'd like to get these committed and
bootloaders made for the players we have added and tested so far.

Currently only Sansa Fuze+, Sansa Clip+, Sansa Clip Zip, and Sansa Fuzev2

Other players can be added later with a few additions to their config files

http://gerrit.rockbox.org/r/#/c/1558/
http://gerrit.rockbox.org/r/#/c/1557/
http://gerrit.rockbox.org/r/#/c/1552/

*Bootdata*
The bootdata patch adds a special region region to the firmware files
it gets marked with a magic header RBMAGIC!

The bootloader looks for this magic header when loading the firmware and
writes the volume number the firmware was loaded from

Requires: editing CRT.0 adding firmware/export/bootdata.h and defining
HAVE_BOOTDATA in device config
this is already done for arm and imx233 and the following players have it
added

Players affected:
Sansa Clipv2 Clip+ ClipZip fuze, fuzev2, fuze+, creativezen,
creativezenxfi2, creativezenxfi3,
samsungypz5, sansafuzeplus,
sonynwze360, sonynwze370

*Multiboot*
Multiboot allows you to create a file named 'rockbox_main.
within it you can define a path to load the rockbox firmware from.

On failure or if no redirect file is found load will fallback to internal
drive.

Players need to have 'HAVE_BOOTDATA' 'BOOT_REDIR' 'HAVE_MULTIVOLUME' in
order to enable HAVE_MULTIBOOT

example for clip+ -> #define BOOT_REDIR "rockbox_main.clip+"

For the players that already have multiboot enabled..

*Sansa Fuze+:*
rockbox_main.fuze+

*Sansa Clip+*
rockbox_main.clip+
* Sansa Clip Zip:*
rockbox_main.clipzip

*Sansa Fuzev2:*
rockbox_main.fuze2

Do note while the bootloader may be finished..
There is still work to do on the actual firmware to be loaded by the
multiboot loader.
There is a commit up on Gerrit with a preliminary version that works but
won't be
finished until a file system rewrite to allow any directory to be mounted
as root
which, is the whole reason for the bootdata region passed back from the
bootloader..

I thank you all for your time,

William

Re: Multiboot Bootloaders

[Wilgus William via rockbox-dev]

>> I imagine multiboot would be very useful if one, say, had a stable
>> version of Rockbox on the internal memory and a development version on
>> an SD card.
>>
>>
>I think that's a potentially very useful feature for development on targets
>with SD card.

>I am globally okay with the description of Bilgus, but the details about
>how to handle bootloaders with very small free space are tricky.

My main goal for multiboot is to allow the reduction of writes/reads to
NAND to hopefully increase the longevity of targets
But since we are already there there is the added benefit of faster testing
of dev versions and maybe even multiple firmware on a single sd card, not
to mention the ability for one to transfer whole installs between separate
( although the same model) player


The code for Multiboot and bootdata together add 732 bytes to the sansa
clip+ bootloader.

Assuming reducing the functionality of is_diacritic with (g#1560) doesn't
break anything in the bootloader which, as far as I can tell, is only used
for the string display (lcd formatting) that removes ~860 bytes. So in
theory if a bootloader fits/compiles today it should still fit with at
least 30 bytes to spare after.
(note: these values are before compression)

Re: Multiboot Bootloaders

[Michael Carr via rockbox-dev]

I imagine multiboot would be very useful if one, say, had a stable
version of Rockbox on the internal memory and a development version on
an SD card. It might also be useful for someone trying to minimize
writes to internal NAND - install once on the NAND, and install
on/boot from an SD card copy from then on.

That's all I can think of, though.

On Mon, Feb 13, 2017 at 4:43 PM, Steph yahoo via rockbox-dev
 wrote:
> From my user point of view & so I can learn something : what would be the
> reason or advantage of having such multiboot ?
>
> I own a Cowon D2 which I'd love to boot from hardware drive instead of SD
> card but multiboot ? Maybe so I would be able to copy/paste cfg files on any
> microSD or SD card and boot from them with similar settings "preloaded"…
> --
> Tshaw !!
>
> Steph
>
> Envoyé de mon aPhone
>
>
> On 13 février 2017 04:49:33 HNEC, Wilgus William via rockbox-dev
>  wrote:
>>
>> Hi all,
>>
>> I've been working on adding multiboot functionality to
>> bootloaders on players that support multiple drives/volumes.
>> currently, I have a pretty good system laid out with the addition
>> of bootdata.h from Amaury I'm able to pass back the boot volume
>> to the firmware where we can use jhMikeS' 'mount any directory as
>> root' to allow redirect.
>>
>> The current functionality is as such:
>> rockbox_main. (clip+, fuze+ etc..) is placed in the root of
>> the
>> volume you would like the firmware to be loaded from if this file is blank
>> then
>> FW is loaded from /.rockbox in the root of this volume.
>> If instead a path is specified in the file then the firmware is loaded
>> from //.rockbox, If the file is not found or doesn't contain the
>> bootdata header in the image then firmware loading falls back to standard
>> behavior.
>>
>> If anyone has suggestions / objections I look forward to your reply
>> though be aware, some of these targets have very little free space
>> in the bootloader fw images.
>>
>>
>>
>>
>>
>

Re: Multiboot Bootloaders

[Steph yahoo via rockbox-dev]

>From my user point of view & so I can learn something : what would be the 
>reason or advantage of having such multiboot ?

I own a Cowon D2 which I'd love to boot from hardware drive instead of SD card 
but multiboot ? Maybe so I would be able to copy/paste cfg files on any microSD 
or SD card and boot from them with similar settings "preloaded"…
-- 
Tshaw !!

Steph

Envoyé de mon aPhone

On 13 février 2017 04:49:33 HNEC, Wilgus William via rockbox-dev 
 wrote:
>Hi all,
>
>I've been working on adding multiboot functionality to
>bootloaders on players that support multiple drives/volumes.
>currently, I have a pretty good system laid out with the addition
>of bootdata.h from Amaury I'm able to pass back the boot volume
>to the firmware where we can use jhMikeS' 'mount any directory as
>root' to allow redirect.
>
>The current functionality is as such:
>rockbox_main. (clip+, fuze+ etc..) is placed in the root of
>the
>volume you would like the firmware to be loaded from if this file is
>blank
>then
>FW is loaded from /.rockbox in the root of this volume.
>If instead a path is specified in the file then the firmware is loaded
>from //.rockbox, If the file is not found or doesn't contain
>the
>bootdata header in the image then firmware loading falls back to
>standard
>behavior.
>
>If anyone has suggestions / objections I look forward to your reply
>though be aware, some of these targets have very little free space
>in the bootloader fw images.

Multiboot Bootloaders

[Wilgus William via rockbox-dev]

Hi all,

I've been working on adding multiboot functionality to
bootloaders on players that support multiple drives/volumes.
currently, I have a pretty good system laid out with the addition
of bootdata.h from Amaury I'm able to pass back the boot volume
to the firmware where we can use jhMikeS' 'mount any directory as
root' to allow redirect.

The current functionality is as such:
rockbox_main. (clip+, fuze+ etc..) is placed in the root of the
volume you would like the firmware to be loaded from if this file is blank
then
FW is loaded from /.rockbox in the root of this volume.
If instead a path is specified in the file then the firmware is loaded
from //.rockbox, If the file is not found or doesn't contain the
bootdata header in the image then firmware loading falls back to standard
behavior.

If anyone has suggestions / objections I look forward to your reply
though be aware, some of these targets have very little free space
in the bootloader fw images.