Hello Wookey,
Am 2008-08-15 16:41:10, schrieb Wookey:
> The problem with generic D-I has been for years that there is no
> support for flash partitioning as opposed to disk partitioning. So far
> as I know that is still true. This is because it depends on partman
> for this and partman doesn't do flash. Has that changed in the last
> couple of years?
The problem is, HOW the Flash is attached...
1) as Memory Device
2) As native Flash-Disk
This depends on the Hardware implementation. For my own development I
prefer 2) since it is like ha harddisk... Unfortunately I can not test
this with a AT91SAM7SE, not AT91SAM9G20 or the new i.MX31.
This are the three CPU's I will use in my further develoments (or maybe
the i.MX35 and i.MX37 if available)
Currently I have not enough money but I think, in Oktober I let a PCB
service here in the near let make my AT91SAM9G20 with my own ideas and
CF-Card as storage... Hey, the prototype for this 100x160mm Board cost
arround 180€ including soldering...
> I have never really got my head round exactly whether it was better to
> simply replace partman with something else for flash installs or to
> add support to partman. Part of the problem is that the multitude of
> bootloaders use different partitioning schemes. In practice it may be
Right... Inthe original configuration of my Eval-Boards I was able to
boot, but then changeing to RedBoot it was not more working... hate!
Since I have currently no real experience, I do not know about standards
for ARM like under i386 compatibles.
> that this is not too big a job, but I think everyone so far has
> decided it was too much effort.
>
> The other thing is that D-I does exactly what most embedded people
> don't want - installs on the target (slowly!). They want to do the
> install on the build system and just copy an image over to the target
> device. We currently copy a debootstrapped/emsandboxed image over to
> the device, do the 2nd-stage install there, then pack up the result
> and save it as an installable image. The problem with this is that it
> is difficult to fully automate and some things which should be
> different on every box end up the same (generated keys, for example).
I was thinking, that all we need is a D-I which build the WHOLE system
on the fly (architectur independant) and bootstrap/dd the WHOLE
prepared installation into the device... like a Disk-Image.
I have gotten a ARM hardware tutorial which describe this method by
using an attached CF-Card of Flash-Chip (it does not mather) and use a
bootloader which catch simply the Disk-Image from the UART (any serial
devices), write it to the FLASH device and then execute it...
It seems, my Netger 602 and 834 use the same method... the WHOLE OS
will be uploaded as Disk-Image.
So I do not see any real problems, if D-I build a Disk-Image on the fly,
install ths stuff there and then send it over the UART. This would
require only an additional udeb which create the Disk-Image and upload
it.
> What we really want is support for local cross-installs a-la stag or
> stage and splitting of install scripts into native/non-native parts.
> This is a really big, scary, job within debian. Discussion on this
> subject in extremadura would be productive, I think, as to what the
> best short and long-term approaches are.
Unfortunately I can not realy help since I have no fixed internet where
I live and currently looking for a new appartement in germany or a
credit which allow me to complete my two mobilhomes (each 3m x 7,45m).
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Attachment:
signature.pgp
Description: Digital signature