Git push access

[SquidMan]

I would like to obtain push permissions to the MINI Git repository. I
have a nice little patch to submit. It enables NAND FS reading, and
provides the framework for writing (all the spare data updating still
needs to be done, but otherwise it should be fine). It also adds a few
more commands to the raw NAND access, such as decrypted reads/writes,
and reading/writing in different size chunks (Blocks and sectors)
It does not interfere with any already existing code (at the moment,
Ceiling Cat is the only such code >_>)

Thanks.

[bushing]

Still working on getting some real sample code out there... in the
mean time, just use git format-patch so we can get some peer code-
review going here.
-b

[SquidMan]

thanks bushing.

The patch file is here: http://pastie.org/489429

[Sven]

nandfs support should not be implemented in MINI imho. Code like this
belongs to the powerpc side.
It's also not very nice to claim that you wrote the nandfs code
because it clearly contains code from wii-fsck (see nandfs.c there).
I'm for example pretty sure that i wrote nandfs_get_fs_entry.
It also contains pretty ugly things like "current_dir->first_child =
current_dir->first_child" (hint: this used to be current_dir-
>first_child = be32(current_dir->first_child) in wii-fsck.....)
You should also create two different patches for aes encryption
support and nandfs support.

Sorry, but i would reject this patch.

[Thomas D]

Indeed, when talking to squidman on IRC I raised this same issue...
Possibly what mini needs is modules for this... it is nice to offload some processing from powerpc, but what that is largely depends on the application.

By the way, is PowerPC supposed to have complete control over mini, or is it supposed to be the other way around? Should PowerPC be allowed to load random chunks of ARM code into mini?
Or should mini be some sort of mini-OS with basic permissions? By the name, I would guess not.

Also, IIRC Starlet only has a small amount of dedicated RAM (much like the DS), so anything beyond this RAM limit would go into main memory and block PowerPC, making it completely worthless to offload more than that amount of code to Starlet as PowerPC can do the same thing faster.

- TD-Linux

[dhewg]

On Wed, Jun 3, 2009 at 11:09 PM, Thomas D <bztd...@gmail.com> wrote:
> By the way, is PowerPC supposed to have complete control over mini, or is it
> supposed to be the other way around? Should PowerPC be allowed to load
> random chunks of ARM code into mini?
> Or should mini be some sort of mini-OS with basic permissions? By the name,
> I would guess not.

Starlet has full control over the PPC, but not the other way around.
Mini can halt and restart the PPC at any time.

The common procedure for starlet is:
- halt PPC
- put PPC code somewhere in memory
- upload a PPC boot stub over the EXI bus. That stub contains an
instruction to branch to the prior uploaded PPC code
- restart the PPC

But since its useful to reload code on starlet too, mini has an IPC
call to reload ARM code too. Its like IOS_Reload, except you can load
anything you want.

Both, PPC and ARM code can be uploaded via our bootmii console client
(using an USBGecko). The only requisite for that is mini running on
starlet. PPC code might even be stuck in an exception handler, you
could still bootstrap it :)

> Also, IIRC Starlet only has a small amount of dedicated RAM (much like the
> DS), so anything beyond this RAM limit would go into main memory and block
> PowerPC, making it completely worthless to offload more than that amount of
> code to Starlet as PowerPC can do the same thing faster.

Exactly, everything that could be done on PPC side should be done on
PPC side. Mini is supposed to be minimalistic (duh). For more info
about its memory layout and usage, check mini's linker script and the
output of readelf.

Regards,
dhewg