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