| lool | NCommander: I uploaded a partman-uboot using -I 128 instead of -b 4096; no idea where you got that from | 10:58 |
|---|---|---|
| ogra | lool, banshee still doesnt work for me, though it comes up completely now and doesnt kill the UI anymore ... stays unresponsive though | 12:50 |
| * ogra is just dist upgrading ... probably that fixes something | 12:51 | |
| lool | ogra: Could you confirm the bug I filed? | 13:01 |
| 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:02 |
| 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:05 |
| lool | I suspect some cache is preventing the issue; it didn't hang for me on second try | 13:06 |
| 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:12 | |
| 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:53 |
| 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? | 13:54 |
| 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:01 |
| xbox | any help and or suggestions is appriciated | 14:02 |
| ogra | lool, well, redboot-install can still use it | 14:25 |
| ogra | though there is no kernel in karmic anyway | 14:25 |
| 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:27 |
| 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:28 |
| ogra | well, i just wouldnt upgrade | 14:31 |
| ogra | there are three fixes th the new redboot though | 14:31 |
| 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:32 |
| 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:33 |
| armin76 | babbage 3.0? | 14:34 |
| lool | yup | 14:34 |
| * armin76 volunteers to get used 2.0 and 1.0 babbage :P | 14:35 | |
| 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:37 |
| playya_ | to hear the jeopardy music while booting? | 14:38 |
| playya_ | s/music/melody/ | 14:38 |
| ogra | heh | 14:40 |
| ogra | no, it needs to be either knight rider ot the galactica theme :) | 14:40 |
| ogra | lool, so even after upgrade banshee shows the same behavior ... but at least the vorbis errors are gone in the debug output | 14:41 |
| 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:43 |
| 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:45 |
| * amitk wants to see ogra carry that board around in his pocket | 14:46 | |
| ogra | just needs a long power cable | 14:47 |
| ogra | hmm, and ethernet ... | 14:47 |
| suihkulokki | big, esd-protected pocket? | 14:49 |
| ogra | well, i think i'll stay with my n900 rather | 14:49 |
| 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:55 |
| amitk | ogra: pastebin? | 14:56 |
| ogra | just attaching serial | 14:57 |
| ogra | amitk, http://paste.ubuntu.com/293984/ | 14:58 |
| 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 | 14:59 |
| lool | NCommander: You mean the other way around | 15:00 |
| lool | NCommander: maen confirmed in a recent bug | 15:00 |
| amitk | ogra: nice, it didn't seem to like FSL's recommendation of turning off OTG | 15:03 |
| amitk | infact, even their defconfig keeps it on (which is what I used for our configs) | 15:05 |
| ogra | lool, hmm, doesnt look like slangasek likes the idea of a redboot upload | 15:32 |
| ogra | (see -release) | 15:33 |
| bjf | maen, ping | 15:36 |
| ogra | lool, do you have any news from Jamie about cdrdao ? | 15:47 |
| ogra | its still FTBFS | 15:47 |
| lool | No | 15:48 |
| lool | ogra: I think he has limited connectivity | 15:48 |
| ogra | yeah, he said something about CELF | 15:49 |
| ogra | i'm just worried we dont get it fixced in time | 15:49 |
| 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:50 |
| lool | maen: Hola | 16:53 |
| lool | bjf: Pole | 16:53 |
| 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:54 |
| 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:55 |
| 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 :) | 16:56 |
| maen | Hey lool | 17:02 |
| maen | regarding Dove Y0 hang | 17:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| bjf | NCommander, ok, i'm there | 17:11 |
| NCommander | bjf, http://people.canonical.com/~mcasadevall/dove/experimental/dove_bootrom_2_01_spi_0x1.img - dump this into your TFTP folder | 17:12 |
| bjf | NCommander, done | 17:13 |
| 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:14 |
| bjf | NCommander, will take just a sec, tftp not config'd correctly on dove | 17:15 |
| 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:16 |
| 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:17 |
| bjf | NCommander, all done, what's next | 17:18 |
| NCommander | bjf, reset and pray | 17:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| plars | lool: yes, I had planned to, I just got the latest from NCommander yesterday | 17:22 |
| 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:23 |
| 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:24 |
| bjf | NCommander, ok, that helped: | 17:25 |
| * armin76 wants dove | 17:25 | |
| 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:26 |
| 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:27 |
| bjf | NCommander, have desktop, however this is still an old kernel, so I'm going to dist-upgrade and see how that goes | 17:28 |
| NCommander | bjf, at least its not a brick ;-) | 17:29 |
| NCommander | bjf, did it manage to boot a 208 kernel from the desktop? | 18:04 |
| 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:05 |
| 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:06 |
| NCommander | maen, is there a sane way to upgrade the BootROM on SPI from userland? | 18:07 |
| bjf | NCommander, 207.15 booted up just fine | 18:08 |
| NCommander | bjf, \o/ | 18:08 |
| 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:09 |
| NCommander | maen, do you know if a Y[0-1] kernel will work on a X0 or too early to tell? | 18:10 |
| lool | maen: We dont work on sunday though | 18:11 |
| lool | maen: but we might be around nevertheless | 18:11 |
| ogra | haha | 18:11 |
| * NCommander notes that ones Sunday availability is directly proportional to ones life | 18:12 | |
| NCommander | AKA, I'll be here :/ | 18:12 |
| maen | Ncommander, I am not sure if Y0/1 kernel will work on X0 | 18:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| lool | NCommander: We only care about differing /proc.cpuinfo Hardware info | 18:19 |
| NCommander | lool, which is if the kernel will change I hope the /proc/cpuinfo (aka ARM mach_id) changes | 18:20 |
| * NCommander is only partially sure that the Hardware field comes fromt he SoC though | 18:21 | |
| 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:27 |
| 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:28 |
| 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:29 |
| NCommander | maen, ??? but setting mem=512M allows full use of RAM with graphics, without issue. | 18:31 |
| maen | yes thats right, but then graphics will use kernel memory and you graphics will not work | 18:32 |
| 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:34 |
| 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:35 |
| 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:37 |
| 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:39 |
| 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:42 |
| bjf | CONFIG_DOVE_GPU=y | 18:43 |
| bjf | CONFIG_DOVE_GPU_MEM_SIZE=128 | 18:43 |
| bjf | CONFIG_UIO_DOVE_VMETA=m | 18:44 |
| bjf | CONFIG_UIO_DOVE_VMETA_MEM_SIZE=34 | 18:44 |
| bjf | CONFIG_VMETA_NEW=y | 18:44 |
| bjf | our VMETA_MEM_SIZE is different from what maen reports, don't know if that is an issue | 18:45 |
| 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:29 |
| bjf | maen, thanks for the info | 19:33 |
| === bjf is now known as bjf-afk | ||
| === lbt_ is now known as lbt | ||
| === bjf-afk is now known as bjf | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!