[06:03] Anyone else nutty enough to be awake now? === Guest74361 is now known as Martyn [07:39] Is there a vfp-support currently? [08:46] lool the cdimage scripts shuldnt differ from the USB key scripts, essentially i thought: create an empty image with n MB sized redboot partition and ext2 or vfat partition ... grab the existing live .img file and copy the content into the second partition ... set up redboot with kernel, initramfs and fconfig [08:48] ogra: How do you grab redboot? [08:48] from the archive [08:49] its in since some hours [08:49] ogra: So you have full archive access and can unpack any .deb [08:49] ogra: You don't particularly need .udebs for instance [08:49] i should, shouldnt i ? [08:49] ogra: I don't know [08:49] ogra: I'm not touching cdimage stuff [08:49] i think i do :) [08:49] Meiz_n810: What do you mean? [08:49] ogra: Are you running under hardy? [08:50] udebs -> yes, for the bootloader installation in ubiquity [08:50] ogra: On x86? [08:50] shouldnt matter as long as i can access the jaunty archive and pull the redboot binary from there [08:51] (and indeed your scripts need to be able to run under hardy) [08:51] ogra: Do you think we have time to complete ubiquity support for redboot? I really fear we don't, it involves creating a partition for redboot and kernel and all, that means partman changes and it's notoriously hard [08:51] right, that brings us back to the casper bootmenu idea [08:52] ogra: So fis is a C program currently, should I also port that to perl or will you rebuild a version for hardy or...? [08:52] which i'm not actually happy about since we cant upgrade the kernel without trashing our install media [08:52] no idea, you havent shown me any code yet [08:52] ogra: I just had an idea for this, but it's not very elegant [08:52] thats fine [08:52] its our first shot and we're late [08:52] elegance is for karmic [08:53] ogra: Well the fis code isn't mine, it's the public one I mentionned a couple of weeks ago; I didn't think of the constraints of running on cdimage which I'm asserting now [08:53] I can show you code right now if you like, but the question stands on whether a C binary is enough or not [08:53] Or whether I should look at rewriting that in perl as well [08:53] i would assume so [08:53] can it build under x86 ? [08:54] ogra: So do you typically run hand-build binaries on cdimage, or does 99.9% of the tools come from hardy package or...? [08:54] (and still function) [08:54] fis.c builds and runs under amd64 which is where I've been running it [08:54] ok [08:54] we shopuld just add your stiff to NCommander's redboot-imx package i think [08:55] ogra: Well I wondered the same, but I thought that while we're likely to drop the redboot package when we get a real board, we're unlikely to drop the utilities to update data [08:55] then the script can pull it from the archive, dpkg -x it and call the binaries as well as dd'ing redboot [08:55] ogra: That is, I expect we will want to manipulate fis data and fconfig data, probably in the installer, but less so that we will ship redboot [08:56] ogra: But it's just a guess, happy to hear what you think [08:56] I'm happy if I can skip NEW [08:56] yes, thats my final target [08:56] but i'm not sure we really want it for jaunty [08:56] dpkg -x => I'm not sure, it's going to be built agianst jaunty's libc6; it should work, but it's not very clean [08:56] (i'm not sure we really can do it in time for jaunty rather) [08:57] Ok, I agree with the last comment (ENOTIME); having it in redboot is not too ugly for jaunty and saves us time [08:57] if we could loop mount the squashfs we shouldnt need to care about jaunty/hardy [08:57] I was having nightmares this night that I still needed to package redboot-utils, file a FFE, promote to main etc. [08:57] since we can run inside a jaunty chroot [08:58] oh, wait, we cant [08:58] Err armel? [08:58] cdimage is x86 [08:58] yeah [08:58] grrr [08:58] That's why I'm asking so much about cdimage environment; it's not clear what are the allowed custom behavior, and how much self-contained the archive needs to be for that [08:58] well, my main prob is that i still have no functional kernel, i need that first before actually making build scripts [08:59] we definately need to be able to pull the tools we use from the archive [08:59] ogra: Well I think we need to make progress on cdimage integration no matter what; I can provide you with a binary image of fconfig data while I complete the script hopefully today [08:59] so adding your stuff to the redboot package should be the next step [08:59] right [09:00] Ok; I can add fis today and whatever I have for fconfig as well, I think I'll move from "clean implementation" mode to "I need this tonight" [09:00] i hope the latest kernel doesnt oops and leaves me with working ttys, if that works i can start the actual final scripting tomorrow [09:01] sadly the kernel testing eats immense amounts of time atm [09:01] ogra: So who will write the image creation script? I know what needs to be done, but not where to do it, and prefer if you do it and I tell you what needs to be done at a high level [09:01] that somewhat blocks me [09:02] right, i can do it with your guidance and probably a bit of StevenK handholing, that shouldnt be a big prob [09:02] ogra: Let's leave the kernel to the kernel team, the kernel shows console message which is enough to confirm our kernels are properly loaded in the SD image; we can hand replace them with a working one [09:02] no [09:02] Why not? [09:02] i need it to work with casper [09:02] it doesnt help to just see it booting [09:03] we need to be sure we get through initramfs [09:03] and i would like to actually test the images [09:03] ogra: What I'm saying is that we have working kernels [09:03] older ones [09:04] Oh ok, I get it with initramfs [09:04] currently my only working kernel isnt one thats coming from any of our packages [09:04] Ok, nevermind [09:04] ogra: But it's good enough to develop the SD image building script itself [09:04] ogra: It's not a large work, but I'd feel better if we'd start its implementation now [09:04] sure, but then there is nobody who will weed out the tty bug [09:05] currently we have no kernel that boots into a usable system [09:05] ogra: Ok; please hand me the LP #, I'll sub to it; is it milestoned? [09:05] and i would really like to make sure that works first [09:05] there is no LP# [09:05] ogra: Perhaps we need to ring the alarm bell with the imx51 kernel that we need kernel efforts now? [09:05] amitk is doing his best [09:05] i'm confident we'll have it solved today [09:05] ogra: Well if it's a blocker, we certainly need it tracked a milestoned jaunty bug [09:06] amitk: What do you think? [09:06] ogra: Let's imagine a second it wont be fixed today, we'd be better off with a bug than without, do you agree? [09:06] (my prob is that i still dont exactly know where the sigkill of the shell comes from) [09:07] yes, for the sigkill we need a bug [09:07] ogra: Ok; would you mind filing this bug (these bugs)? after we're done discussing? [09:07] sure, will do [09:08] he prob is that we have nothing in the archive yet i can actually point to [09:08] ogra: It's not affecting the current jaunty stuff? [09:08] all the work we're doing on the kernel comes from uploads amitk does to people.u.c [09:08] it is [09:09] ogra: File it against jaunty then? either getty or bash, or just ubuntu; it's just to document the existence and status of this issue [09:09] the uploaded kernel in the archive only has the inital code drop from freescale in it but no adjustments towards the actual ubuntu kernels [09:09] as soon as amitk started to build it like a common ubuntu kernel the probs showed up [09:09] ogra: If I want to ring the alarm bell, I need a bug id to point at [09:10] Even if this is "about to be merged" work [09:10] i'm confident its a linux issue ... [09:10] since it works with all non-ubutuized kernels [09:10] and it might even be caused by the cross toolchain amitk uses [09:11] ogra: Concerning udebs, do you think it makes sense to have a d-i build for imx51? [09:11] Well for babbage actually [09:11] sure, now that NCommander is free he can care for it if he likes [09:11] I think it's the obvious place to provide a SD card image with kernel + initrd with d-i, but I don't think it's required if we do live [09:11] he seemed to have some special interest in alternate images [09:11] NCommander: What are you looking into ATM? Could you take that? [09:12] (i guess an answer will take some hours :) ) [09:12] NCommander: Also, kexec-tools was finally added to P-a-s, do you think you could try it out? it built on armel [09:12] ogra: Ok; let's move to the actual SD card script [09:12] heh, kexec-tools bit me in a funny way yesterday [09:13] ogra: So first thing, we need an empty partition table which sadly encodes info about CHS; I think we want them maxed as to allow covering of most SD cards [09:13] no [09:14] we want a generic part. table and an image thats not bigger than needed [09:14] ogra: How does it differ from what I'm saying? [09:14] why do you want to have CHS ? [09:15] just dd an empty image and call a simple fdisk or sfdisk script on it to create two partitions [09:15] ogra: The partition table defines the cylinder size in bytes [09:15] hmm [09:15] ogra: Don't worry about it; it's easy [09:15] ok [09:15] hold on, I actually have a good pointer [09:17] Sorry, I don't find the URL right now; it was on the TI site explaining how to format a SD card for beagle/evm [09:17] easiest would be to pre-create a binary blob [09:17] with partition table and redboot already [09:17] ogra: I don't think that's a good idea [09:17] why ? [09:17] ogra: Where do you store that? [09:17] If it's generated data, let's generate it? [09:18] It's not hard to script fdisk [09:18] we pre create binary squashfs images for the livecd as well [09:18] Automatically [09:18] i dont say we shouldnt generate itr [09:18] Oh ok [09:19] just saying dd -> build image, dd -> binary blob to that image -> mcopy livefs ... or somethng like that [09:19] lool: I am ok with ringing the alarm bell. A 3rd person looking at it certainly can't do any harm [09:19] ogra: So back to creating SD images: 10) create a large file which is going to be the SD card image; size is size of squashfs rounded up to a number of cylinders + size of FIS partition rounded up to a number of cylinders + size of partition table [09:20] i would say we're fine with 800M [09:20] though our current livefs doesnt include oo.o [09:21] but its about 510M big [09:21] ogra: 20) format that with fdisk, using the same values as for beagleboard images (I think it's 63/63/63 or 255/255/255); craete partition 1 just as large as FIS size rounded up and partition 2 of size rounded up to to hold squashds [09:21] Type of first partition should be non-FS data, type of second partition should be linux [09:22] right [09:22] preferably formatted as vfat since we can skip loop mounting with that [09:22] 30) run ./fis init with proper arguments on first partition to create an empty FIS part table [09:23] 40) create a file of the size of the redboot config fis partition (4096) and fconfig -i it with proper arguments (this I hope to provide tonight) [09:23] right [09:24] 50) ./fis create with proper arguments the 5 FIS partitions: RedBoot, FIS directory, RedBoot config, kernel [09:24] You need to pass the file contents for that step, so for instance for the kernel fis partition you need to pass the kernel image to ./fis so that it can checksum it [09:24] indeed, so we need to dpkg -x it [09:25] oh, wait [09:25] *perhaps* -- but I'm not sure -- you need to prepare a null-padded file with the kernel + zeroes or kernel + 0xff's and pass that to ./fis instead [09:25] we should be able to pull it out of the livecd image [09:25] it has initramfs and kernel now that we added imx51 to it [09:25] ogra: That's an option [09:25] the only one :) [09:25] we need a casper initramfs [09:25] Concerning that optional padding, I think only initramfs is sensible to that [09:26] built on armel [09:26] Are the optional padding step and step 50 clear to you? [09:26] ogra: the toolchain is a good point. Now if lool or someone can point me to a ubuntu toolchain I can use, I would try it [09:27] relatively, gimme the tool ... :) [09:27] 60) You actually need to dd the data files your passed to ./fis in the relevant places, that is in the FIS partition offset in the first DOS partition: ./fis create does *not* copy the file's contents, it only write the FIS directory entry [09:28] 70) write the squashfs data to the second DOS partition [09:28] done [09:28] ogra: Sure [09:28] ogra: http://svn.nslu2-linux.org/svnroot/fis/trunk/ [09:28] Just make [09:28] well for 70 i would just mcopy the whole content 1:1 from the livecd image [09:28] Doesn't require anything fancy, should work with hardy [09:29] amitk, shell still dies, still no input via USB kbd [09:29] ogra: Concerning fconfig, I recommend you dd the contents from an existing SD image for now, but I can provide fconfig.pl which can not write the data yet to you if you like [09:30] amitk: You could try building natively, push to the canonical-arm-dev ppa [09:30] no, finish it first [09:30] amitk, #32 Tue Mar 17 20:18:30 EET 2009 is the right timestamp ? [09:30] (just to make sure) [09:31] ogra: I couldn't find the exact page I found in the past, I think it moved, but this page has comparable instructions: http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat [09:32] ogra: Basically, it's fdisk 'o' command to create an empty partition, then 'x' for expert mode, and '255/63/' [09:32] People who want to use the SD card for other stuff will have to fix that last number to match their card's size in bytes [09:32] (well in cylinders) [09:32] ogra: that timestamp looks right [09:32] easy to put into a here document with fdisk ... [09:33] amitk, ogra: Would be nice to push the kernel to the ppa to let it build natively and exclude the toolchain and that one of you would file the bug documenting the issue(s) so that we can ask for more people to reproduce and look into it [09:34] I prefer focusing on my own stuff than acting as a relay here as I have much to do still [09:34] toolchain is a close indicatior given that klogd also dies [09:35] lool: what is the url to the ppa, I can't seem to find it [09:35] amitk: It's a private PPA [09:42] ogra: Do you think you have enough that you can start working on the script while trying out new kernels from amitk? [09:43] yep [09:44] lool, its not clear to me yet how redboot will find the partition, but thats a prob for later, let me get started first [09:44] * ogra is afk for a moment [09:45] ogra: RedBoot expects it at a given offset [09:45] ogra: This is hardcoded: [09:45] RedBoot 0x00000000 0x00000000 0x00040000 0x00000000 [09:45] FIS directory 0x00040000 0x00000000 0x0001F000 0x00000000 [09:46] We could *perhaps* change some stuff such as sizes, but I wouldn't count on that [09:46] We don't need to anyway [09:46] This is probably not hardcoded but I wouldn't want to deviate on it either: [09:46] RedBoot config 0x0005F000 0x0005F000 0x00000000 0x00000000 [09:46] The rest is ours to define [09:48] For my 16M SD card, I picked kernel size == 0x00400000 and initrd size == 0x00940000 [09:49] It's quite arbitrary, and we should probably make it larger to target >= 32M for boot data, we target large cards anyway [09:49] http://paste.ubuntu.com/132944/ was my final layout [09:50] ogra: For my installed system, I did this: http://paste.ubuntu.com/132945/ note that I created a swap partition which might make sense here as well [10:17] well, i dont want to trash peoples SD cards by using swap ... and the 512M of the babbage really suffice [10:18] Ok [10:20] (and we have compcache for people really wanting swap) [10:56] amitk, i get the following now: "usbhid: disagrees about version of symbol struct_module" [10:56] amitk, and an actual "invalid module format" message [10:57] grr.. [10:57] I have just uploaded to the ppa [10:57] 49C0BED7.5080205@visionsystems.de [10:57] ok [10:58] i'll wait until it built [10:58] NCommander: you might be interested in the above message to linux-arm-kernel [10:58] ogra: for some reason I think you have a module mismatch during creation of initramfs [10:58] i wouldnt know why [10:59] it is the initramfs created by the linux-image postinst, nothing fancy about it [10:59] and i also get it if i boot without initramfs [11:00] i.e. if the modules come from disk [11:00] well, not exactly the same message though [11:00] [42949400.560000] sg: disagrees about version of symbol struct_module [11:00] [42949401.040000] sg: disagrees about version of symbol struct_module [11:00] [42949401.530000] usbhid: disagrees about version of symbol struct_module [11:00] [42949401.680000] usbhid: disagrees about version of symbol struct_module [11:01] lool: Rejected: [11:01] PPA exceeded its size limit (1284.00 of 1024.00 MiB). Ask a question in https://answers.launchpad.net/soyuz/ if you need more space. [11:01] uhoh [11:01] gah [11:02] lool: can you kill the old kernel? [11:02] isnt there some older image we can drop [11:02] # 152 binary packages (1.1 GiB) [11:05] https://answers.launchpad.net/soyuz/+question/64519 [11:10] NCommander: I removed your kernel from the PPA, please reupload it when we get more space (see above question) [11:10] amitk: I think you can reupload [11:10] # 51 binary packages (1.1 GiB) [11:10] I fear it's openjdk spoiling it [11:12] hmm, all files in /lib/modules have 1970-01-01 as timestamp ... [11:12] i wonder if that confuses anything [11:13] interesting [11:14] well, when i installed the package i had to use a very old kernel that didnt have hwclock working [11:16] root@babbage:~# modprobe usbhid [11:16] FATAL: Error inserting usbhid (/lib/modules/2.6.28-10-imx51/kernel/drivers/hid/usbhid/usbhid.ko): Invalid module format [11:16] root@babbage:~# uname -a [11:16] Linux babbage 2.6.28-10-imx51 #32 Tue Mar 17 17:28:59 EET 2009 armv7l GNU/Linux [11:17] * ogra rm -f's /lib/modules/2.6.28-10-imx51 and reinstalls the package [11:18] root@babbage:~# modprobe usbhid [11:18] FATAL: Error inserting usbhid (/lib/modules/2.6.28-10-imx51/kernel/drivers/hid/usbhid/usbhid.ko): Invalid module format [11:18] same ... [11:20] amitk, the timestamps on the module binaries definately match the timestamp of the vmlinuz binary [11:21] -rw-r--r-- 1 root root 2158304 2009-03-17 19:30 vmlinuz-2.6.28-10-imx51 [11:21] -rw-r--r-- 1 root root 49056 2009-03-17 19:30 /lib/modules/2.6.28-10-imx51/kernel/ubuntu/squashfs/squashfs.ko [11:21] so it really has to do something with the build [11:32] has anybody tried installing ubuntu on http://uniconsys.com/index.php/platforms/products-pegasus [15:44] Good morning :) [15:55] Martyn: Hi - this is Dave Martin btw. [15:57] hey there dave :) [15:57] good talking to you :) [16:03] :) [16:33] So, I tried to get a telnet-enabled Redboot working using fsl-redboot. So far, no luck. [17:34] Martyn: What's the actual problem? [18:56] re ogra [18:56] lool : No response at all. [18:56] lool : Not an electronic sausage [19:15] for mx51, should I be grabbing packages from ports.ubuntu? [19:15] yep [19:15] feel free to use the rootfs-from-scratch script in the topic [19:16] it will roll you a ready to use tarball [19:18] done :) [19:18] Have you had success using the telnet features of the fsl redboot ogra? [19:19] I try to get the adapter up and running, but cannot make a connection [19:19] no, i'm only focusing on serial and direct write access [19:19] *nod* [19:19] we'll get the latter the next days [19:20] which might solve your probs as well [19:20] Okay :) someone's already on it. [19:20] I got the serial/JTAG dongle today from the Austin ARM office. [19:20] i'm starting on the image build script tomorrow [19:20] should be ready on or probably before the weekend [19:20] so I was able to stop the boot, and append text to the kernel cmdline [19:20] awesome [19:20] cool [19:21] yeah, it's nice to have a full kit now [19:43] Martyn: On my side I can tell you that http is broken in redboot, I suspect the network driver is shaky [19:47] lool : "shaky" is right === plars_ is now known as plars [22:14] I just found a sllliiiight drawback to using the livecd/sd image for testing [22:14] no usb network modules :) [22:15] * Martyn patiently waits for ogra's next drop :)