Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable capability to use >1 sector per cluster in ghostfat #89

Closed
henrygab opened this issue Mar 13, 2021 · 9 comments
Closed

Enable capability to use >1 sector per cluster in ghostfat #89

henrygab opened this issue Mar 13, 2021 · 9 comments

Comments

@henrygab
Copy link
Collaborator

henrygab commented Mar 13, 2021

@kaetemi ... maybe I'm missing something, but I think there needs to be a way to enable the use of the new >1 sector per cluster support.

For example, shouldn't the following:

tinyuf2/src/uf2.h

Lines 45 to 47 in 15fa707

#define CFG_UF2_FLASH_SIZE (4*1024*1024) // TODO absolute max flash size
#define CFG_UF2_NUM_BLOCKS (0x10109) // just under 32MB
#define CFG_UF2_SECTORS_PER_CLUSTER (1)

Be changed to:

#ifndef CFG_UF2_FLASH_SIZE
    #define CFG_UF2_FLASH_SIZE          (4*1024*1024)    // TODO absolute max flash size
#endif
#ifndef CFG_UF2_NUM_BLOCKS
    #define CFG_UF2_NUM_BLOCKS          (0x10109)        // just under 32MB
#endif
#ifndef CFG_UF2_SECTORS_PER_CLUSTER
    #define CFG_UF2_SECTORS_PER_CLUSTER (1)
#endif

If so, I'll mark PR #90 as ready....

@kaetemi
Copy link
Contributor

kaetemi commented Mar 13, 2021

Yeah, that would be more practical. :)

@kaetemi
Copy link
Contributor

kaetemi commented Mar 13, 2021

Can we include the tested large value combination in the comments?

@hathach
Copy link
Member

hathach commented Mar 13, 2021

Yeha, there is still lots of TODO, we will move it to per ports/boards later on. But this look good

@hathach
Copy link
Member

hathach commented Mar 15, 2021

Can we include the tested large value combination in the comments?

Yeah, I think having a working/tested value combination would be great. It is removed recently (probably mistaken as obsolete value). Would you mind added it, maybe along with a bit of detail on your setup e.g like this combination appear as 1.5 GBs disk and tested on abc hardware would be helpful as well.

@kaetemi
Copy link
Contributor

kaetemi commented Mar 15, 2021

#define CFG_UF2_FLASH_SIZE          (256*1024*1024)
#define CFG_UF2_NUM_BLOCKS          (0x300000)       // 1.5 GB
#define CFG_UF2_SECTORS_PER_CLUSTER (64)

That's for 256MB flash, so 2x a 512MB UF2 file, and plenty for space remaining for the two text files (or for the remainder of a UF2 file with non-flash content).

Tested on RP2040, for flashing BT815-series graphics chip. (Maybe add a note on the memory required for the buffer that keeps the written block flags... CFG_UF2_FLASH_SIZE / 256 / 8 iirc? That's the bottleneck, it seems.)

@hathach
Copy link
Member

hathach commented Mar 16, 2021

#define CFG_UF2_FLASH_SIZE          (256*1024*1024)
#define CFG_UF2_NUM_BLOCKS          (0x300000)       // 1.5 GB
#define CFG_UF2_SECTORS_PER_CLUSTER (64)

That's for 256MB flash, so 2x a 512MB UF2 file, and plenty for space remaining for the two text files (or for the remainder of a UF2 file with non-flash content).

Tested on RP2040, for flashing BT815-series graphics chip. (Maybe add a note on the memory required for the buffer that keeps the written block flags... CFG_UF2_FLASH_SIZE / 256 / 8 iirc? That's the bottleneck, it seems.)

Great, would you make an PR to add these comment along with the note. CFG_UF2_FLASH_SIZE is from original uf2 bootloader for nrf52, there is still work to generalize this project. It is still in early stage, so yeah, we will revise it and update/remove it when needed.

@henrygab
Copy link
Collaborator Author

@kaetemi - It was my PR that removed the large commented-out values. Sorry!

@hathach - Having the CFG_* values is important ... I am close to having self-validation code working, at least to the point I must hand it to you for proper integration. I will open a separate issue/PR for that. :)

@hathach
Copy link
Member

hathach commented Mar 17, 2021

@henrygab ah ok, actually, I have no plan/time to remove it anytime soon. But rather will evolve slowly when needed :) I am looking forward to your PR.

@henrygab
Copy link
Collaborator Author

Mostly done, except for a couple build/CI steps I need help with. See PR #94.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants