[10:58] NCommander: I uploaded a partman-uboot using -I 128 instead of -b 4096; no idea where you got that from [12:50] lool, banshee still doesnt work for me, though it comes up completely now and doesnt kill the UI anymore ... stays unresponsive though [12:51] * ogra is just dist upgrading ... probably that fixes something [13:01] ogra: Could you confirm the bug I filed? [13:02] https://bugs.launchpad.net/ubuntu/+source/boo/+bug/452066 [13:02] Launchpad bug 452066 in boo "libboo2.0-cil fails to install on armel" [Undecided,New] [13:02] you filed a new one ? [13:02] will do once the upgrade is through [13:02] oh, it didnt hang for me [13:05] hal start/running, process 1871 [13:05] Richte libboo2.0-cil ein (0.8.2.2960+dfsg-1) ... [13:05] * Installing 7 assemblies from libboo2.0-cil into Mono [13:05] Richte libmono-zeroconf1.0-cil ein (0.9.0-1) ... [13:05] * Installing 5 assemblies from libmono-zeroconf1.0-cil into Mono [13:05] lool, ^^^ [13:06] I suspect some cache is preventing the issue; it didn't hang for me on second try [13:12] lool, so what do i do with the new redboot, it completely drops B1 (while our current package has still the B1 binary available) [13:12] * ogra isnt sure we want to completely drop it [13:53] ogra: I dont strongly care [13:53] ogra: there are some B1 out there, but then mine has been collecting dusts in the last months [13:53] It's not running anymore since it was only running from SD [13:54] ogra: So if you feel like readding B1 support or forking the package/tree, you could; I suspect post karmic we really dont care anymore [13:54] We only cared because we copy them in our install media, and we dont have any for B1 [13:54] ogra: Unless you want to add SD card images for B1 in d-i? [14:01] Hi there is there a way to "put " the capacity of my USB1.1 device to 10 mb/s instead of 1.2mb/s by using other or different parameters for ehci_hcd andor ohci_hcd module? [14:02] any help and or suggestions is appriciated [14:25] lool, well, redboot-install can still use it [14:25] though there is no kernel in karmic anyway [14:27] ogra: redboot-install can use any binary, right? [14:27] ogra: so it could use a binary from jaunty, or from an older karmic .deb or from FSL or locally built [14:27] yep [14:27] indeed [14:28] just needs to be unpadded [14:28] I dont think we need to bother providing B1 support if it's at the expense of a lot of time spent on that job or lesser B2.x support [14:28] But I can't really say how long it would be [14:28] If it's easy to keep B1 support, keep it [14:31] well, i just wouldnt upgrade [14:31] there are three fixes th the new redboot though [14:32] + Update the DDR setup for MX51 TO 3.0 on 3-stack platform [14:32] + Drop support for MX51 Babbage 1.0 & MX51 Rocky [14:32] + Fix the I2C driver [14:32] + Update the DDR setup for MX51 Babbage Platform [14:32] it gets us 3.0 support IOW [14:32] So between B1 and B3 support I'd personally pick 3,0 [14:32] we have 3.0 support already [14:33] especially since 3.0 works with out kernels already!! [14:33] Yeah [14:33] it just improves DDR and I2C handling [14:34] babbage 3.0? [14:34] yup [14:35] * armin76 volunteers to get used 2.0 and 1.0 babbage :P [14:37] hmm, i wonder why xplash seems to init the audio device [14:37] i hear a clear power-on cracking in the headphones when xsplash comes up [14:38] to hear the jeopardy music while booting? [14:38] s/music/melody/ [14:40] heh [14:40] no, it needs to be either knight rider ot the galactica theme :) [14:41] lool, so even after upgrade banshee shows the same behavior ... but at least the vorbis errors are gone in the debug output [14:43] on a sidenote i'm playing radio in RB and pulse doesnt seem to go above 5-9% CPU usage ... that contradicts what i always hear from FSL (pulse eats all CPU) [14:45] ogra: I changed the code to overclock the CPU. It'll burn out as soon as support ends. :-p [14:45] haha [14:45] well, until then it makes a fine radio :) [14:46] * amitk wants to see ogra carry that board around in his pocket [14:47] just needs a long power cable [14:47] hmm, and ethernet ... [14:49] big, esd-protected pocket? [14:49] well, i think i'll stay with my n900 rather [14:55] amitk, so i just tried to test your kernel from the I/O bug [14:55] and get an oops right after unpacking [14:56] ogra: pastebin? [14:57] just attaching serial [14:58] amitk, http://paste.ubuntu.com/293984/ [14:59] lool, I think I wrote -I 128 on te wiki page by accident over -b 4096 when I went through all my IRC logs. I'll re-ask maen on this today to confirm [14:59] bbiab [15:00] NCommander: You mean the other way around [15:00] NCommander: maen confirmed in a recent bug [15:03] ogra: nice, it didn't seem to like FSL's recommendation of turning off OTG [15:05] infact, even their defconfig keeps it on (which is what I used for our configs) [15:32] lool, hmm, doesnt look like slangasek likes the idea of a redboot upload [15:33] (see -release) [15:36] maen, ping [15:47] lool, do you have any news from Jamie about cdrdao ? [15:47] its still FTBFS [15:48] No [15:48] ogra: I think he has limited connectivity [15:49] yeah, he said something about CELF [15:49] i'm just worried we dont get it fixced in time [16:50] Hey, does anybody want to write a little bit of ARM assembly for me? I want an optimized implementation of http://cubehash.cr.yp.to/ . Pretty please? [16:53] maen: Hola [16:53] bjf: Pole [16:54] *poke [16:54] lool, here [16:54] maen: So checkout https://launchpad.net/ubuntu/+source/linux-mvl-dove [16:54] maen: In the last upload, bjf rebased the dove tree on the latest stable updates from upstream [16:54] (kernel.org) [16:54] maen: He did not change anything dove specific [16:54] But that regressed on Y0 with DDR2 [16:55] Y1 and Y0 with DDR3 (what he had) still work [16:55] https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/450940 [16:55] Launchpad bug 450940 in linux-mvl-dove "Regression in linux-mvl-dove 207 and later causes Y0 boards to hang seconds after booting" [High,In progress] [16:55] Thats the regression [16:56] lool, as far as I know we only have one Y0 with DDR3 and even our Y1s only have DDR2 [16:56] Yes, correct [16:56] bjf: "Y1, and Y0 with DDR3" is what I meant [16:56] lool, gotcha [16:56] I mean I dont want to speak for the memory config of Y1 we use, but they work :) [17:02] Hey lool [17:02] regarding Dove Y0 hang [17:03] Yeah [17:03] We only updated the kernel [17:03] in latest patches we have pushed to git, we have enabled cpuIdle by default [17:03] Which is why I dont understand why it would be related to hw setup [17:03] maen: I dont think we merged these though [17:03] bjf: ^ [17:04] I will explain , please be patient [17:04] NCommander: You had the issue too, plesae follow discussion here [17:04] maen: Don't worry, just getting the attention of the relevant people [17:04] (*I* dont see the bug) [17:04] Dove Y0 original BOOTROM has a bug with deepIdle PM mode [17:05] maen, when were these changes pushed to git? [17:05] 18:04 < NCommander> lool, rtg, bjf successful start and login with 208 kernel to the desktop [17:05] 18:04 < NCommander> The problem completely goes away if you flash a new bootrom [17:05] * NCommander guess lool said it for me [17:05] lool, wow! [17:05] NCommander: So we need to update the install process to cover this [17:06] maen: Thanks [17:06] maen, thanks [17:06] lool, if future kernels though are tied to newer BootROM updates, then we need a mechanism to update the ROM on the fly [17:06] NCommander: please comment in the bug [17:06] so for Dove Y1 all boards are released with a new BOOTROM already so you will not have this issue [17:06] for Dove Y0 you should update the bootrom [17:06] NCommander: and point the bug at instructions to upgrade the BOOTROM when you have them on the wiki [17:06] latest comment, please read release notes [17:07] NCommander: I dont think it's a reasonnable seem to update the bootrom automatically [17:07] I prefer a documentation fix here [17:07] btw, for the new U-Boot that we will release for you next week I hope with Hush Parser script, we also will release a new BOOTROM [17:07] this BOOTROM will support boot from UART with DDR3 support [17:07] maen: Is it required to update to this new bootrom? [17:08] NCommander will need it for UART boot with boards that have DDR3 [17:08] It also will fix some issues with NAND boot [17:08] so I recommend you use it [17:08] bjf, care to test the upgrade BootROM fix before I rewrite all our docs? (I'll also be moving to standardize us to SPI booting again) [17:09] NCommander, you want to give me the steps that you want to put into the docs and i can run through them and verify? [17:09] NCommander, sounds good to me [17:09] bjf, change SW7 on your board to boot from SPI versus NAND [17:10] NCommander, ok, you already have that documented, just a sec [17:10] bjf, then powercycle the board into marvell's u-boot [17:10] maen: Ok [17:11] NCommander, ok, i'm there [17:12] bjf, http://people.canonical.com/~mcasadevall/dove/experimental/dove_bootrom_2_01_spi_0x1.img - dump this into your TFTP folder [17:13] NCommander, done [17:14] bjf, tftp 2000000 dove_bootrom_2_01_spi_0x1.img [17:14] protect off f87f0000 f8800000 [17:14] erase f87f0000 f8800000 [17:14] cp.b 2000000 f87f0000 10000 [17:14] protect on f87f0000 f8800000 [17:15] NCommander, will take just a sec, tftp not config'd correctly on dove [17:16] bjf, In case your wondering, the magic numbers here describe where the BootROM on SPI is loaded from; specifically the very tail end of the chip which is normally write protected. The reset strap controls if the SoC uses the SPI bootrom or not [17:16] NCommander, reset strap? [17:17] bjf, thats what the Marvell calls SW:1-5, which controls where the SoC tries to load the IPL [17:17] &SW7:1-5 [17:17] NCommander, ok [17:18] NCommander, all done, what's next [17:18] bjf, reset and pray [17:19] bjf, if you were successful, there should be a new boot message in u-boot [17:19] NCommander, I change SW7 back to NAND right? [17:19] bjf, no [17:19] bjf, right, ok, we need to install the new bootloader to SPI [17:19] bjf, basically, BootROMs need to match where your booting from. So a BootROM for SPI, BootROM for NAND [17:19] etc. [17:19] NCommander: https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/435151 updated [17:19] Launchpad bug 435151 in linux-mvl-dove "dove kernel requires mem=512M to use all available memory" [Low,Triaged] [17:20] NCommander: please test with latest uboot and without mem=512m [17:20] bjf, since we need to use SPI u-boot for Y1, I want to move to that on Y0, and save us all a lot of confusion [17:20] NCommander: should wokr on all Y0s and Y1s [17:20] lool, k [17:20] bjf, let me just upload a new u-boot binary for you to flash [17:20] NCommander, where should I see a new boot message? [17:20] bjf, BootROM version (on chip)= 1.07 [17:20] BootROM version (upgrade on SPI)= 2.01 [17:20] bjf, just before the countdown to run the bootcmd [17:21] plars: I'd also love you testing dropping the mem=512m thing if you have latest uboot [17:21] (I dont but should) [17:21] plars: https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/435151 [17:21] Launchpad bug 435151 in linux-mvl-dove "dove kernel requires mem=512M to use all available memory" [Low,Triaged] [17:22] lool: yes, I had planned to, I just got the latest from NCommander yesterday [17:23] NCommander, I'm just not seeing it (the BootROM version) [17:23] NCommander, I see a BootROM Status: [17:23] bjf, what is SW7 set at [17:23] if SW1 is off, it will disregard the BootROM in SPI [17:23] NCommander, SPI [17:24] bjf, might just need a new u-boot binary in SPI. That's probably the stock one [17:24] bjf, grab this: http://people.canonical.com/~mcasadevall/dove/experimental/y0/uboot-SPI-Y0-512M-10152009.bin [17:24] bjf, and then bubt uboot-SPI-Y0-512M-10152009.bin [17:24] Press Y to reset the environment when prompted [17:25] NCommander, ok, that helped: [17:25] * armin76 wants dove [17:26] BootROM version (on chip)= 1.07 [17:26] BootROM version (upgrade on SPI)= 2.01 [17:26] bjf, try booting now [17:26] NCommander, switching SW7 back to NAND and then booting right? [17:26] bjf, no, leave it on SPI [17:27] bjf, the SW7 just says where u-boot is loaded from, and I want to standardize Y0 and Y1's bootloaders [17:27] NCommander, gotcha [17:27] NCommander, looks like it's trying [17:27] bjf, \o/ [17:28] NCommander, have desktop, however this is still an old kernel, so I'm going to dist-upgrade and see how that goes [17:29] bjf, at least its not a brick ;-) [18:04] bjf, did it manage to boot a 208 kernel from the desktop? [18:05] Ncommander/lool , start of next week we will release a new U-Boot that will support Ubuntu boot script, and ext2 patch from the mainline, and will include a new BOOTROM binaries, I need that you test it asap and let us know if it is good for you, that should be Sunday or Monday [18:05] NCommander, I'm just going to boot 207 first... [18:05] maen, are BootROM binaries going to be a usual upgrade thing from here on out? [18:06] this should be the latest upgrade before next dove revision. [18:06] maen, is that X0? [18:06] but if we will find any issue we will upgrade the boorom again [18:06] Yes that is X0 [18:07] maen, is there a sane way to upgrade the BootROM on SPI from userland? [18:08] NCommander, 207.15 booted up just fine [18:08] bjf, \o/ [18:09] Ncommander, with some effort that is possible, but it is not on our list of todo [18:09] maen, thats what I thought [18:10] maen, do you know if a Y[0-1] kernel will work on a X0 or too early to tell? [18:11] maen: We dont work on sunday though [18:11] maen: but we might be around nevertheless [18:11] haha [18:12] * NCommander notes that ones Sunday availability is directly proportional to ones life [18:12] AKA, I'll be here :/ [18:13] Ncommander, I am not sure if Y0/1 kernel will work on X0 [18:15] ^- lool [18:15] maen: So machine id will change? [18:15] NCommander: Anyway, not a big deal for us anyway [18:15] NCommander: Did you ever try kexec on dove? [18:15] * NCommander coughs [18:15] NCommander: Did you ever try kexec on dove? [18:16] lool, don't remember if I did or didn't [18:16] NCommander, 208.16 boots, just need to figure out what the usb issue is [18:16] bjf, might be pendrive related. [18:17] lool, well, it could be an issue if we want to support Y series and X series at the same time since we then need a new method of telling them apart [18:19] NCommander: We only care about differing /proc.cpuinfo Hardware info [18:20] lool, which is if the kernel will change I hope the /proc/cpuinfo (aka ARM mach_id) changes [18:21] * NCommander is only partially sure that the Hardware field comes fromt he SoC though [18:27] lool, machine id will depend if we will have a new board for X0 or not, and if we have the same board then if we can support both revisions in runtime or compilation time [18:27] lool, lets wait and see [18:28] maen, w.r.t. to getting memory info from u-boot, without mem=512M, only about 381M is used [18:28] maen, on a 1CS board. a 2CS board uses ~850M [18:29] yes because of memory allocated for Graphics and Video [18:29] if you are not supporting graphics in your release you can disable this [18:31] maen, ??? but setting mem=512M allows full use of RAM with graphics, without issue. [18:32] yes thats right, but then graphics will use kernel memory and you graphics will not work [18:34] so if you are not using graphics, it is better to disable graphics and Video [18:34] diff --git a/arch/arm/configs/dove_defconfig b/.config [18:34] old mode 100755 [18:34] new mode 100644 [18:34] index 2d0fa70..3859fed [18:34] --- a/arch/arm/configs/dove_defconfig [18:34] +++ b/.config [18:34] @@ -1,7 +1,7 @@ [18:34] # [18:34] # Automatically generated make config: don't edit [18:34] # Linux kernel version: 2.6.30.4-dove-3.2.0 [18:34] -# Sun Oct 11 14:53:15 2009 [18:34] +# Thu Oct 15 19:16:33 2009 [18:34] # [18:34] CONFIG_ARM=y [18:34] CONFIG_SYS_SUPPORTS_APM_EMULATION=y [18:34] @@ -1571,8 +1571,7 @@ CONFIG_USB_S2255=m [18:34] # CONFIG_DRM is not set [18:34] # CONFIG_VGASTATE is not set [18:34] # CONFIG_VIDEO_OUTPUT_CONTROL is not set [18:34] -CONFIG_DOVE_GPU=y [18:34] -CONFIG_DOVE_GPU_MEM_SIZE=128 [18:34] +# CONFIG_DOVE_GPU is not set [18:34] CONFIG_FB=y [18:34] # CONFIG_FIRMWARE_EDID is not set [18:34] CONFIG_FB_DDC=y [18:34] @@ -2098,9 +2097,7 @@ CONFIG_UIO_PDRV=y [18:34] # CONFIG_UIO_SMX is not set [18:34] # CONFIG_UIO_AEC is not set [18:34] # CONFIG_UIO_SERCOS3 is not set [18:34] -CONFIG_UIO_DOVE_VMETA=y [18:34] -CONFIG_UIO_DOVE_VMETA_MEM_SIZE=96 [18:35] -CONFIG_VMETA_NEW=y [18:35] +# CONFIG_UIO_DOVE_VMETA is not set [18:35] # CONFIG_STAGING is not set [18:35] # [18:35] ^- bjf, lool. [18:37] NCommander, write up a bug, post a patch and we can consider it for SRU :-) [18:37] bjf, no, I'm saying we might want/need to drop mem=512M if we're using the GPU [18:39] maen, when you say graphics, are you referring to video output all together, or just GPU usage? [18:39] NCommander, ah! hmmm, yes reading the scrollback that sounds right (that we shouldn't be setting mem=512M) [18:39] bjf, but are we using the GPU? [18:39] I rather not loose a good chuck of RAM if we're not compiling support in [18:42] NCommander, right now we are configured to use the GPU, I though there were apps that took advantage of it [18:42] bjf, ok, so I'll make mem=512M disappear [18:43] CONFIG_DOVE_GPU=y [18:43] CONFIG_DOVE_GPU_MEM_SIZE=128 [18:44] CONFIG_UIO_DOVE_VMETA=m [18:44] CONFIG_UIO_DOVE_VMETA_MEM_SIZE=34 [18:44] CONFIG_VMETA_NEW=y [18:45] our VMETA_MEM_SIZE is different from what maen reports, don't know if that is an issue [19:29] Ncommader, graphics =GPU video= Vmeta , if you are not using them currently then disable them from the defconfig file [19:29] We have update Vemta to 96 to support 1080p videos [19:33] maen, thanks for the info === bjf is now known as bjf-afk === lbt_ is now known as lbt === bjf-afk is now known as bjf