dldi/nds/dsgba merge? (was: Re: Nano-X speedup)
stsp at stsp.name
Fri Oct 5 18:03:03 CEST 2007
On Fri, Oct 05, 2007 at 04:33:05PM +0200, Troy Davis wrote:
> What about adding dldi support to the .nds and/or ds.gba builds, it
> mounts it if dldi patched otherwise it uses current setup, instead of
> create a new vendor branch?
There is no vendor branch involved in creating new builds,
it's just another set of config files in vendors/Nintendo/<build>
I guess adding dldi support to NDS and DSGBA does not make as much
sense as trying to squeeze ṄDS and DSGBA into DLDI, does it? :)
We could try to make DLDI behave properly if no disk storage
- Move everything except the bare essentials out of romfs.
This might involve building two seperate busybox binaries.
one that lives in /bin (i.e. in romfs) and contains only really
essential tools, another one that lives in /usr/bin (i.e. in the
linux folder) containing non-essential tools.
- Add sram support for those who need it.
- If mounting proper storage fails, mount a ram disk or sram
if present on /media and populate it so the symlinks pointing
there from romfs still work.
The rc scripts and busybox build procedure would need some
hacking but I guess we could get this to work.
This would also mean zero errors if users forget to patch
dslinux.nds with a dldi driver, and we could even tweak the
system to still work if they forget to extract the linux folder!
This would get rid of a major FAQ :)
Then, with only the DLDI build left, we could create two seperate
builds renamed to something like "CLI" and "GUI". The "GUI" build
would also contain nano-X in romfs for speed and boot into pixil.
Or does that not make sense for some reason?
http://stsp.name PGP Key: 0xF59D25F0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.dslinux.in-berlin.de/pipermail/dslinux-devel-dslinux.in-berlin.de/attachments/20071005/01bead5f/attachment.pgp
More information about the dslinux-devel