Bug#612376: flash-kernel: please include efikamx support
Hello,
2011/4/4 Loïc Minier <lool@dooz.org>:
> It would be nice if you could file a bug against linux to get the new
> flavor; I personally would recommend -mx5.
That's fine with me. I'll wait for the bug report until we had proper
patches for kernel.
> Technically, mx5 would only support mx51 right now, but would soon
> allow supporting mx53 as well, notably for mx53loco / quickstart boards
> which I bet a bunch of Debian ARM users will get.
I guess if we aim to unify, makes sense to use "mx5" subarchitecture.
I'll walk around debian-installer base code to fix subarches. I hope
it does not break previous ubuntu contributions.
> I reviewed your commits, some notes:
> - fa8fdbc9607ebd892eba1e1c3b4ad12f710c901f Add support for Efika devices:
> please sort machine names alphabetically in the case statement
> - 7e6bd315830ad89c11aadebbe45f1636dd686055 README: Add Efika support:
> kernel uses "nettop" in cpuinfo, but vendors uses "Smarttop"; also,
> vendor uses "Efika MX" not just "Efika". I would prefer just the
> vendor name in the README but you could have both with "Efika MX
> Smarttop (nettop)"; the kernel name is "set in stone" now, but it's
> not too nice
> - 4f873843d590b6d5475dcef7d863919c89609b4f
> flash-kernel-installer.isinstallable: Add mx51 as subarchitecture:
> I realize this comes from other parts of d-i, but would it make sense
> to use arm*/mx5? My preference would be to avoid subarches as long
> as possible but use upstream names when required; arch/arm/mach-mx5
> is the current name, so that's what I'd use.
> - 5deea668506d7a26a8b79fea218101c7900b9752 changelog: add Efika support
> (Closes: #612376):
> please amend the currently UNRELEASED changelog entry
>
> Othewise looked good; thanks!
Please recheck changes:
http://git.debian.org/?p=d-i/flash-kernel.git;a=commitdiff;h=108de0c2f52301151dd866fe5a0bb7c5f34e5f57
> I'm also in favor of a boot.scr.
Yes, I agree that flash-kernel needs to know about boot.scr, could we
steal ubuntu code/approach (you explained on IRC) or should I write a
patch for support it?
16:37 < lool> zumbi: well flash-kernel can do whatever is needed
16:38 < lool> zumbi: The main reason I'd use one would be to pass
cmdline args such as root=UUID=xyz to the kernel
but it's an useful facility for later changes as well
16:38 < lool> zumbi: Up to you
16:39 < lool> zumbi: It's also the only way to persist your cmdline
flags when booting from SD, since you can't
saveenv to SD
16:39 < lool> zumbi: There are two ways this could be supported:
generated at Debian install time, generated every
time flash-kernel is run
16:48 < zumbi> lool: ok, let's say, we enable boot.scr support on
flash-kernel-installer, so it is just used at
Debian install time, if later we find out we need it at
kernel upgrade time, we can always add the code
16:50 < lool> zumbi: If we add it later, it might break expectations
that the file is not overwritten on upgrade, and
so it might overwrite user data
16:50 < lool> zumbi: In Linaro, we write a boot.txt near the boot.scr
with the contents before calling mkimage; I
think Ubuntu's flash-kernel will generate boot.scr from
boot.txt if present
16:53 < zumbi> lool: I do not see why not follow Ubuntu approach
17:06 < lool-> zumbi: I'm not suggesting not to follow it either
> Outside of Martin's remarks, we need to agree on whether this is meant
> for installation of Debian to PATA, to SD card, or both and whether
> this is meant to work with vendor's u-boot, upstream u-boot, or both.
I would say we want to install on which ever is mounted under /boot,
so if /boot/boot.txt is present, then boot.scr is regenerated
everytime kernel is installed.
Best regards,
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
Reply to: