Re: network-console on armhf
On Wed, Jan 20, 2016 at 10:05:54AM +0000, Ian Campbell wrote:
> On Sun, 2016-01-03 at 14:41 -0800, Martin Michlmayr wrote:
> > Do you have any preferences? And is anyone using network-console on
> > armhf yet? (Just wondering if I can make changes without breaking
> > things)
>
> Hector added it along with all the other armhf images way back. I suspect
> this was just because armel had them rather than a specific need, but maybe
> he can comment.
>
> I've also added Karsten because I have a vague feeling he was interested in
> network-console for sunxi at some point (or maybe I saw a thread between
> him and someone who was interested, or maybe I'm making things up).
Hello,
I guess the thread you have in mind was the one about finding a way
to have d-i usable both on serial console and on framebuffer console,
without the user having to manually set the u-boot console variable
to select the primary console device. Somebody in that thread had
proposed to take a look at how the network-console setup works as an
inspiration.
I haven't actively used the d-i network-console image for installing
systems as all my boards have easily accessible serial console ports.
> > 2) Kernel/ramdisk and uImages
> >
> > At the moment, armhf requires users to append the DTB and generate an
> > uImage.
>
> I don't think all platforms require this. Many more modern ones (i.e. all
> sunxi ones, I think) support separate DTB and booting direct from the
> zImage without a uImage wrapper.
>
> > Obviously, the same approach would work for these NAS devices
> > but I'd like to make it as easy for users as possible. So I was
> > thinking of generating uImage/uInitrd files as part of the d-i
> > process. But if I do it for these NAS devices, you could argue we
> > should do it for all devices and that would be a lot of images. So,
> > again, I wanted to hear what people think.
>
> Karsten made the SD-card images[0] consist of a base + platform specific
> thing which the user cats together to avoid the enormous amount of space
> duplication here. I think network-console should probably follow suite.
The uInitrd wouldn't contain any platform-specific content and AFAIK
the header of a uInitrd also doesn't contain a system-specific load
address, so it could be shared between all systems that require
uImages.
Regarding the kernel uImages on those platforms that don't support
the bootz command: I suppose most of those also lack support for
loading a separate DTB, so there is probably not much potential for
sharing on the kernel side. Even on those platforms that require
uImages but can load separate DTBs, sharing the kernel uImage might
not be possible because the kernel uImage contains a load address
header that differs between various platforms.
IMHO sharing the uInitrd with the installer is the major point. The
kernel uImages only require about 3.5MB per platform and there are
only very few platforms for which we would have to provide them at
all, so the additional space and bandwidth requirements for them
shouldn't pose a problem.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: