Hello, 2011/4/4 Loïc Minier <l...@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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTimxi2KT+_g=LGf8j4F-wJHB=djr=r33qsft1...@mail.gmail.com
