|Subject:||Re: Fwd: Re: [gentoo-doc] Arm Gentoo Handbook|
|Date:||Wed, 12 Oct 2011 15:30:14|
|In Reply to:||Fwd: Re: [gentoo-doc] Arm Gentoo Handbook by "Raúl Porcel"
On 10/12/11 09:52, Raúl Porcel wrote:> > On 10/05/2011 11:43 PM, Sven Vermeulen wrote: >> On Wed, Oct 05, 2011 at 02:46:54PM -0400, wireless wrote: >>> What currently links to the Gentoo handbook for ARM is >>> deprecated! >>> >>> http://www.gentoo.org/doc/en/handbook/handbook-arm.xml?part=1&chap=5 >>> >>> >>> > Why not link to this doc? >>> http://dev.gentoo.org/~armin76/arm/trimslice/install.xml >>> >>> Lots of new arm netbooks are here and no doubt many different >>> offerings are on the way! >> >> Raúl, >> >> Apart from owning an Eepad Transformer, I know nothing of Gentoo >> Linux/ARM installations. Any thoughts on your part on how we can >> ensure that our documentation stays of high quality here? >> >> Wkr, Sven Vermeulen >> > > Hi Sven, > > Unfortunately i do not have any suggestion of how we could enhance our > documentation in this aspect. > > ARM is very different from other, more common, architectures. If we > look at the handbook, we have some troubles at the beginning. Each SoC > has its own specific stuff regarding installation. For example, most > of the OMAP SoCs require an SD-card with specific partition layout. > Some devices have the kernel in the flash memory, some devices lack > flash memory(pandaboard f.ex), so the kernel+bootloader is in external > storage. > > Every different SoC needs its own kernel and unfortunately most of the > devices aren't supported in the mainline kernel(yet). > > If you look at the documentation i've done: > http://dev.gentoo.org/~armin76/arm/pandaboard/install.xml > http://dev.gentoo.org/~armin76/arm/sheevaplug/install.xml > http://dev.gentoo.org/~armin76/arm/tegra2/install.xml > http://dev.gentoo.org/~armin76/arm/trimslice/install.xml > > you'll see that only some small parts are common among all of them. > > And although the tegra250 dev kit and the trimslice use the same SoC > as your Transformer or the also famously known Toshiba AC100, > different procedures are required for all of them, and the kernel for > each device only supports said device. > > These big differences makes one page per device the only option, IMHO. > I'm open to alternatives. In other distros, the use of > installers(ubuntu) or device/SoC-specific images(archlinuxarm) hide > this issue. > > On our case, we do architecture-specific stage3s. armv7a is one > architecture, in the market there are different SoCs that are > compliant to such architecture: TI OMAP4, Freescale i.MX5, Nvidia > Tegra2, etc... > And those examples i just said use, for example, different serial > ports: OMAP4(ttyO2), i.MX5(ttymxc0) and Tegra2 uses the default ttyS0. > > The current ARM handbook was written in 2004 or so, and was designed > for a device that is uncommon nowadays, old, and slow. > > IMHO removing the current handbook and pointing to one page per device > handbooks would be the way to go. > > ThanksThank you Raul! OK so I agree 100% with what Raul has said. I think, as do many others, that ARM is the wave of the future, particularly for net-books, notepads and light weight portables. I think that if we develop/write up the intro for ARM in the handbook and express what Raul has said, the handbook can focus on the myriad of ways to set up the disc/ssd/flash/sdcard/CF/etc where the end result is somewhat functionally the same. Note the files systems chosen may diverge from the main stream handbook suggestions. We can then link to Raul's guide_pages (or move copies elsewhere) under doc_team management for completion of the install.(this is where the different offering will diverge (slightly) from the handbook's normal installation sequence. (another idea) Maybe for some popular Arm platforms we put up an image to burn onto the medium chosen as a way to get a baseline arm system up? This would come after some folks perform installations and somebody decides to put up an image to first test and then later link into the handbook as an installation option? A fundamental choice is to cross_compile or use native compiling. So the end result is either a system where the sources are cross-compiled on a host, or natively compiled and maintained on the target device. Many (most?) will be of the cross compile vintage, but, there is a new wave of ARM hardware coming, where native (in_situ) compiling will be a viable option. Personally, embedded Gentoo has lots of smart folks, BUT, Raul has a keen clarity on the issues and presents very well. So Let's let him think about it and suggest what makes sense and support it. Diverging from the usual norms of the handbook is something that this doc team needs to discuss, resolve or present other ideas. ARM is coming big time to Linux and if we prepare well it will distinguish our distro, heads and shoulders, above our (friendly) rivals, imho. Embedded Gentoo is very cool; a slick system to get many technoids to use gentoo on their embedded hardware, will result is a coup of technical folks joining the gentoo teams, imho. Besides, all of us commoners will get some very cool ARM based gentoo hardware to use and show off....! James
|Re: Fwd: Re: [gentoo-doc] Arm Gentoo Handbook||Sven Vermeulen <firstname.lastname@example.org>|