[02:25] <DanaG> http://www.slashgear.com/pandaboard-offers-ti-cortex-a9-omap4-to-imaginative-devs-04105681/
[02:25] <DanaG> Spiffy.
[02:25] <DanaG> So the Pandaboard is really close.
[02:28] <DanaG> Though, it looks like form-factor may be just different enough to make it incompatible with Beagle expansion boards.
[02:28] <persia> http://pandaboard.org/ is already taking developer applications...
[02:29] <DanaG> Is the "retail availability" date still NDA?
[02:30] <persia> No idea :)
[02:30] <persia> As a result, I believe the answer is probably "Yes", because otherwise I would expect to have heard something.
[02:37] <DanaG> That's a good answer.
[08:30] <hrw> moin
[10:22] <ndec> ogra: hey!
[10:22] <ndec> so release is up, finally!
[10:28] <lag> :D
[10:29] <lag> Are you please with it ndec?
[10:29] <armin76> celebreate!
[10:29] <ndec> lag: well extremely!
[10:29] <lag> ndec: I'm pleased you're pleased :)
[10:29] <ndec> lag: it's been a really cool project to work with!
[10:29] <lag> ndec: So what's next?
[10:29] <lag> For sure
[10:29] <ndec> lag: natty ;-)
[10:29] <lag> I've enjoyed it
[10:29] <lag> Whoooooooo :)
[10:29] <ndec> lag: well, next step is to release our public PPA
[10:30] <lag> For sure
[10:31] <lag> Are we going to be supporting any more boards?
[10:32] <ndec> not that I know of
[10:32] <armin76> zumbi_: celebrate!
[10:32] <armin76> then you can support another distro :D
[10:33] <lag> armin76: :-o
[10:33] <lag> There's only need for one distro :)
[10:34] <armin76> yeah, and 640k ought to be enough for anyone ;)
[10:35] <ndec> armin76: ;-)
[10:36] <lag> :)
[10:59] <ogra> :)
[11:00] <persia> Why point at cdimage rather than releases?
[11:01] <ogra> persia, because thats where our release lives ?
[11:01] <ogra> show me the url on r.u.c and i'll point to it
[11:02] <persia> You're right.
[11:02] <persia> That's a regression.
[11:03] <persia> We were on releases.ubuntu.com for karmic and lucid
[11:04]  * ogra doesnt see it as a regression, butu yeah
[11:04] <persia> Well, it indicates we weren't considered part of the release.  Maybe just a social thing.
[11:05]  * hrw agrees with persia
[11:05] <hrw> armel looks like 3rdparty in ubunt
[11:05] <hrw> u
[11:05] <persia> Anyway, something to target to be fixed in Natty.
[11:05] <persia> hrw, It's most certainly nothing like 3rd party.
[11:05] <hrw> but totally outside of official archive
[11:06] <persia> No.  Just not blessed with release.
[11:06] <hrw> persia: but also ports.ubuntu.com for last few years instead of merging to archive.ubuntu.com
[11:07]  * hrw hugs apt-cacher-ng
[11:07] <persia> That's mostly blocked by some technical limitations of our mirror software, sadly.
[11:07] <ogra> hmm, https://wiki.ubuntu.com/MaverickMeerkat/ReleaseManifest agrees with you
[11:07] <ogra> i dont think there is code in place to put them on releases.u.c :(
[11:07] <persia> Yep.  Go complain to skaet.
[11:08] <persia> There is code to move from ports/daily{,-live} but maybe not daily-preinstalled.
[11:08] <ogra> right
[11:09] <ogra> though i really wouldnt mind keeping them on cdimage
[11:10] <ogra> simply because it's super confusing having them in the same page with all the other images
[11:10] <ogra> (and their install instructions)
[11:12] <persia> ogra, See, the way to solve that is to make them have the *same* installation instructions :)
[11:12] <ogra> thats not possible
[11:12]  * persia grumbles at git for being painfully slow and bloated (why download 1GB of stuff for 80MB of data?)
[11:12] <persia> Yes it is.  Just requires more work, and more time.
[11:12] <ogra> then the install isntructions get confusing
[11:13] <ogra> you just move the problem around
[11:13] <persia> I believe the only remaining obstacles are 1) getting everyone to accept a common first-stage bootloader (e.g. UEFI), 2) porting grub2, and 3) ensuring there is *some* flash on every board to hold a vendor-installed first-stage bootloader.
[11:14] <persia> This is much better than we were two years ago.  I predict we'll be done in only 5 or 6 more.
[11:14] <ogra> you are making weird assumptions about HW manufacturers
[11:14] <persia> Why?  For x86/powerpc the vendors all meet those requirements already.  It's kinda expected for consumer-level general-purpose devices.
[11:15] <ogra> there is no flash on any of the publically available boards we support except the beagle C4 which is underpowered for these images
[11:15] <persia> So?
[11:15] <persia> That's deficient HW.
[11:15] <ogra> there is neither grub but a properly usable u-boot
[11:15] <persia> Right, hence point 2) above.
[11:15] <ogra> which i disagree with
[11:15] <persia> why?
[11:16] <ogra> as well as with the other points
[11:16] <ogra> we have a properly unified bootloader with u-boot
[11:16] <ogra> its just missing framebuffer support
[11:16] <persia> Do you not think it makes sense to have first-stage bootloaders managed by folks to do boards (for board-bring-up), and second-stage bootloaders managed by folks that do OSs (for OS bring up)?
[11:16] <persia> Everyone else is doing it.
[11:17] <ogra> i do ... but thats what we have effectively with x-loader and u-boot
[11:17] <persia> Why be different ?  Multiple code paths are harder to maintain.
[11:17] <ogra> we dont have to maintain them
[11:17] <persia> If you like x-loader, fine, but x-loader/grub2 is more cleanly aligned.
[11:17] <ogra> no, its not
[11:18] <persia> Plus, I think it's easier to use the existing ARM port of UEFI than to port x-loader to everything else.
[11:18] <ogra> simply because everyone working with these boards has u-boot experience
[11:18] <ogra> the only missing bit is framebuffer support so the general enduser could get a menu
[11:18] <persia> So?  Training is easy.
[11:18]  * suihkulokki thinks u-boot has way more momentum than uefi
[11:19] <ogra> ++
[11:19] <ogra> or grub porting (which hasnt even started)
[11:19] <ogra> and making the boards more expensive by adding NAND doesnt look like a good solution either
[11:20] <persia> suihkulokki, Could be: I've seen ports to about the same number of architectures for u-boot and UEFI.  I don't really care which is selected, but would prefer there to be one-true-first-stage-bootloader
[11:20] <hrw> I think that arm boards should go for one simple setup: vendorbootloader + osbootloader. thats done on x86(-64) and works on arm so far with targets which we support
[11:20] <hrw> forget about grub/arm
[11:20] <persia> hrw, Precisely.
[11:20] <persia> Huh?  Which osbootloader then?  Why not use the same as everyone else?
[11:20] <hrw> persia: we do have it with omap34 - xloader + uboot
[11:21] <hrw> u8500/linaro also goes that way: something-from-stericsson + uboot
[11:21] <hrw> atmel at91 (armv5): at91bootstrap + uboot
[11:22] <hrw> at9200rm: simple-in-cpu-flash-bootloader + uboot
[11:23] <persia> bleh!  Standardising on uboot would be fine.  Standardising on it as a *second-stage* bootloader just seems like madness, when it can do first-stage just fine, and it can't do useful device-selection.
[11:23] <hrw> persia: *if* uboot can be 1st stage then let it be. on *rest* let it be 2nd
[11:24] <hrw> persia: atmel at91bootstrap fits inside of cpu flash. you cant get uboot there
[11:24] <persia> uboot needs a fair bit of work from what I've seen to allow user selection of boot devices, etc.
[11:24] <persia> hrw, That's a HW bug :)
[11:25] <ogra> u-boot is to big for fitting in the ram you have available at that stage of boot
[11:25] <ogra> you *need* a smaller first stage
[11:25] <ogra> indeed it could be derived from the u-boot code
[11:26] <ogra> (as x-loader already is)
[11:26] <persia> And has been in several cases.
[11:26] <persia> So sure, maybe I don't actually care that much about standardisation for hwbootloader.
[11:26] <ogra> i agree that this should be fixed
[11:26] <ogra> and i know linaro is working on that at least for omap
[11:26] <persia> I still want the *same* osbootloader for every architecture, and think having a single shared hwbootloader would lead to economies of scale.
[11:27] <hrw> persia: so port uboot for basic x86
[11:27] <ogra> you wont get that without the vendors agreeing
[11:27] <hrw> persia: most of PC are fine with legacy bios + grub. you cant get grub outside of x86 anyway
[11:27] <persia> hrw, It's been done for a while.
[11:27] <hrw> and you cant get PC users with uboot
[11:28] <persia> Hrm?  grub2/powerpc is reputed to work.
[11:28] <hrw> o.. did not know
[11:28] <persia> And u-boot claims to support PPC, ARM, AVR32, x86, M68k, ...
[11:28]  * hrw moved to coreboot on one machine at home
[11:28] <hrw> persia: sure. very few x86 chipsets probably
[11:29] <persia> Oh, I'm sure.  probably mostly VIA ones, for that matter.
[11:29] <hrw> and they do not boot windows anymore?
[11:29] <persia> I still maintain there is scope for economies of scale to have one true hwbootloader, and one true osbootloader.
[11:29] <persia> I wouldn't expect it for the lower-end VIA embedded x86 cores.
[11:30] <hrw> persia: 5 years and EFI will be x86 desktop standard maybe
[11:30] <persia> Most of them can't run current Ubuntu (insufficient instruction support)
[11:30]  * hrw hugs alix.1c with its 2.098s to get init booted from power on
[11:35] <ogra> persia, oh, btw, i fail to see how that bootloader discussion solves the initial problem of having different methods to write differnt install media
[11:35] <persia> ogra, Identical OSbootloader means one can use identical procedures cross-arch.
[11:35] <ogra> i still need to write to different media with different tools
[11:35] <persia> As a result the means by which I make bootable SD for armel is the *same* as for bootable SD for i386.
[11:36] <persia> Which means the same instructions, etc.
[11:36] <ogra> so you run brasero to create an SD card ?
[11:36] <persia> No.  I use usb-creator.
[11:36] <persia> (or at least I did last time I tried that for amd64)
[11:36] <hrw> persia: does any of your pc boots stright from SD?
[11:37] <ogra> right, on armel you cant even start it :P
[11:37] <persia> hrw, At least two of them can.  I thikn a third, but haven't tested it.
[11:37] <ogra> its not installable due to its dep on syslinux
[11:37] <hrw> persia: and by default you need to press some key during reboot to invoke boot menu and select "this SD please" in it
[11:37] <persia> ogra, Right.  See, that's a bug in usb-creator: should use grub2: see discussion with superm1 and Bugabundo in -devel whilst you were sleeping.
[11:38] <ogra> i wasnt sleeping :)
[11:38] <ogra> and i followed it roughly while my ac100 kernels were building
[11:38] <persia> hrw, Actually, no, on one of them it tries SD by default (as I discovered when forgetting to remove the SD when trying to reboot, and being confused why it failed)
[11:41] <persia> ogra, Ah, excellent!  Still, like I said, we're years away.  Even if everyone in the world attempted to start achieving it right now, I don't think it's *possible* to have clean alignment in less than 3 years because of chip layout planning timeframes.
[11:42] <ogra> yup
[11:43] <ogra> and given that work on devicetree is already going on in kernel and u-boot i expect that to arrive earlier as a unified arm solution
[11:43] <hrw> persia: my desktop can boot from sata/pata/usb/cf/sd/sm/ms/xd but for non-sata I need to go to bootmenu, for pata even to bios
[11:43] <hrw> ogra: 11.10 not earlier
[11:43] <persia> hrw, That's just a side-effect of your hwbootloader.  If there was the alignment and consensus on a single hwbootloader like I'm advocating, we'd be having a comparable experience.
[11:44] <hrw> ogra: for Linaro 11.05 DeviceTree will not be ready yet
[11:44] <ogra> hrw, i dont exepct d-t in less than a year
[11:45] <ogra> buut thats still quicker than persias estimated 3 years for grub
[11:46] <persia> 3 years isn't for grub.  It's to fix on-chip ROM codes to not be braindead about what to use to boot hwbootloaders.
[11:46] <persia> And 3 years is a lower-bound estimate, really.
[11:47] <persia> (as in, if someone decided to start fixing this today, it would take 3 years for the *first* SoC that wasn't broken to be released)
[11:59] <persia> Assuming I don't have kernel issues, are there issues expected with do-release-upgrade from jaunty->karmic->lucid->maverick for armel?
[12:05] <dmart> win go #linaro
[12:05] <dmart> win go #linaro
[12:13] <lag> I can feel a new Bootloader coming ... Supports all architectures, all bios', all OS': persia-boot
[12:18] <persia> lag, That is a frightening concept.  The moreso since I tend to write most stuff in make, which is probably not an ideal language for bootloader development.
[12:19] <lag> persia: :)
[12:19] <lag> persia: I can teach you C - it's a small language
[12:23] <persia> thanks, but I've been taught C a few times: I just haven't used it professionally in something like 15 years, amd my hobby C has all been small patches.
[12:33]  * ogra sighs ...
[12:34] <ogra> 3800 mails done, 1400 mails to go
[12:35] <persia> releases are fun :)
[12:36] <lag> ogra: Are you back home?
[12:36] <ogra> lag, yes
[12:36] <ogra> wading through my mail since two days
[12:37] <lag> I spoke with ndec this morning - he sounded happy with the release :)
[12:37] <ogra> on the road i only read what was directly affecting the current work
[12:37] <ogra> lag, yes, he told me already
[12:37] <ogra> lag, we still need to solve the sound issue and i need to get the tablet going
[12:37] <ogra> thats the twoi last bits on my TODO for maverick
[12:38] <lag> Sounds == userspace (last I heard)
[12:38] <ogra> oh, and bug 657732 is an intresting one ... i could reproduce it on the tegra
[12:38] <ubot2> Launchpad bug 657732 in xaos (Ubuntu) "xaos has artefacts on first frame with -threads (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/657732
[12:38] <lag> sound*
[12:38] <ogra> lag, not clear yet
[12:39] <ogra> lag, there seem to be initialization bits missing but its not clear where
[12:39] <ogra> to me it looks like the driver needs the init after the mixers were set
[12:39] <ogra> which would be a clear driver issue
[12:39] <lag> Quite
[12:40] <ogra> but it could as well be a race in alsa userspace
[12:40] <ogra> thats why its so hard to pin down
[12:40] <lag> I believe Mathieu has been liaising with various kernel and TI people to have this issue solved
[12:41] <ogra> rama from TI (the omap4 ASoC driver dev) was working directly with lrg on the issue but there was no outcome yet
[12:41] <lag> Well if they can't fix it, then we have an issue
[12:42] <ogra> they still try i belive
[12:42] <lag> lrg wrote most of ASoC
[12:42] <ogra> i know
[12:42] <lag> He would be 'the one' AFAIC
[12:42] <ogra> and rama most of the omap4 driver ... and he worked on the HW too
[12:42] <lag> Then we have the best people 'on it'
[12:43] <ogra> no
[12:43] <lag> ?
[12:43] <ogra> because nobody seems to have deep insight in the ubuntu specifics of alsa
[12:43] <lag> What if we lent diwic to them?
[12:43] <ogra> as i understand it alsactl restore is supposed to do the same as alsactl init for example
[12:44] <ogra> but that either doesnt happen or happens in the wrong order for the device
[12:44] <ogra> lag, how much does he know about the userspace ?
[12:44] <lag> He is Ubuntu's Audio guy
[12:44] <ogra> the prob with alsa is that the line between kernel and userspace is really blurry in ubuntu
[12:45] <lag> I think that is the case with ALSA generally
[12:45] <ogra> there are many bits expected by the driver that imho should be in userspace
[12:45] <ogra> but alsa generally doesnt depend on i.e. pulse to set all mixers :)
[12:45] <ogra> at least in the rest of the world
[12:45] <lag> diwic is afk, but I'll hassle him later
[12:45] <dcordes> hi
[12:46] <ogra> lag, ok, i'll try to get rama on IRC (dont know his nick, i need to find out if TX gets up)
[12:46] <lag> Where is lrg?
[12:47] <lag> TX?
[12:47] <lrg> lag: UK
[12:47] <lag> BANG!
[12:47] <ogra> no idea, i know he uses to live in the UK
[12:47] <lag> Hello Liam
[12:47] <lrg> ogra: my panda is very ill
[12:47] <ogra> heh
[12:47] <lrg> hey
[12:47] <ogra> lrg, still ? :(
[12:47] <ogra> sh*t
[12:47] <lrg> ogra: hw issue :(
[12:47] <lrg> so I'm using SDP now
[12:47] <lrg> Hey Lag
[12:47] <ogra> should be fine as well
[12:48] <lag> Where in the UK are you?
[12:48] <ogra> lrg, any idea about the issue ?
[12:48] <lrg> lag: just north of Edinburgh
[12:48] <lag> Just over the bridge?
[12:48] <lrg> ogra: afaict the USB hub is a bit broken
[12:48] <lag> :)
[12:48] <lrg> lag: yes
[12:48] <ogra> lrg, i meant the sound issue with the SDP4430.conf :)
[12:50] <lag> That's a nice area
[12:50] <lrg> ogra: ah, I'm just starting to look now that I have 10.10 running on the SDP, although ubiquity kept crashing for me so I had to do some manual hacks to setup a user account etc
[12:50] <lag> Do you know Queen's Ferry?
[12:50] <lag> Do you know Queensferry?
[12:50] <XorA|gone> lag: that would either North or South, there is no such town named on its own
[12:50] <ogra> lrg, kept crashing ? how ?
[12:50] <lrg> lag: Yes, very close :)
[12:51] <lag> That's a scary little place if you're not a 'local' :)
[12:51] <XorA> lag: Im going to assume from your IP your in Bristol or South Gloucestershire :-)
[12:52] <lag> Bristol
[12:52] <lrg> ogra: it would crash after 30secs in the help pages
[12:52] <ogra> hrm
[12:52] <ogra> with the final release ?
[12:52] <lag> Where are you XorA?
[12:52] <lrg> no, a few days ago
[12:52] <ogra> i know it works for TI Nice who have tested it
[12:52] <ogra> ah
[12:52] <XorA> lag: Edinburgh, but I used to work in Aztech West many years ago
[12:52] <lag> @ST?
[12:52] <XorA> lag: yes
[12:53] <lag> I have a few friends there
[12:53] <XorA> 1999-2000
[12:53] <lag> They didn't work there then :)
[12:53] <lrg> ogra, lag: going for lunch now - will be back shortly
[12:53] <ogra> k
[12:53] <XorA> worked on the disastrous project for ST GFX card
[12:53] <lag> Sure
[12:54] <lag> I believe they've had a couple
[13:12] <lag> ogra: It looks like diwic specialises in userspace :)
[13:13] <ogra> awesome
[13:13] <lag> I will speak to the chain and see if we can free him up
[13:16] <lag> Hi diwic
[13:16] <lag> Thanks for joining
[13:16] <diwic> np
[13:16] <lag> ogra: ping
[13:16] <ogra> yes, i'm here :)
[13:17] <lag> diwic: We have some rather taxing issues with regards to audio on the Panda
[13:17] <lag> We have two kernel audio experts on the case
[13:17] <lag> But we are lacking in userspace knowledge
[13:18] <diwic> okay
[13:18] <lag> Can we set up some kind of brain storming session when lrg is back and rama is available
[13:19] <lag> ogra: diwic: ?
[13:19] <lag> Would you be up for that?
[13:19] <diwic> sure, at what time approx?
[13:20] <lag> That would depend
[13:20] <lag> ogra: Where in the world is rama?
[13:20] <ogra> TX
[13:20] <lag> So it would be afternoon
[13:20] <ogra> yeah
[13:20] <lag> lrg is at lunch currently
[13:20] <diwic> My work day is up in ~ 3 hours
[13:20] <ogra> and i need to get him to IRC first :)
[13:20] <lag> Sure
[13:21] <lag> If we can't do it today, I'll set a meeting up and we'll do it later in the week (perhaps tomorrow)
[13:22] <lag> ogra: Do you have his contact details?
[13:22] <ogra> no
[13:22] <lag> Okay, we'll hunt those down
[13:22] <lag> Then speak to lrg
[13:22] <ogra> right
[13:22] <lag> diwic: I'll let you know more as soon as I do
[13:22] <lag> diwic: Thanks for your time
[13:22] <ogra> he knows them for sure
[13:22] <lag> We'll get them one way or other
[13:23] <lag> robclark will probably know them too
[13:23] <diwic> lag, okay. For today I can't be online when my work day is up, but tuesday or wednesday might work better, if time zones are a problem
[13:23] <lag> diwic: No problem - we'll work something out
[13:26] <cjjnjust> hello, when porting linux to arm, I add printascii("bara bara\n"); in start_kernel. It print other string, and then trap into abort. What wrong?
[13:33] <lag> cjjnjust: When you say it prints another string, what do you mean?
[13:35] <cjjnjust> i mean it print the other strings. the string is define in other place.
[13:35] <lag> You mean it prints out other strings successfully?
[13:35] <lag> It's just yours that it does not?
[13:36] <cjjnjust> lag, the string is in other function, it seems like address error
[13:36] <lag> That's probably what it is then
[13:37] <lag> Check in: arch/arm/kernel/head.S
[13:37] <cjjnjust> yes, I have check it again and again...
[13:38] <cjjnjust> once  call a function with args, it will trap into abort mode.
[13:39] <cjjnjust> but it can run to start_kernel, when printk("%s",linux_banner); it go to  abort mode.
[13:43] <lag> cjjnjust: Which kernel are you using? And which Arm chip are you trying to use?
[13:44] <cjjnjust> lag,2.6.35 s3c2410
[13:46] <lag> The s3c2410 is already supported
[13:48] <lag> arch/arm/configs/s3c2410_defconfig
[13:48] <cjjnjust> I know that .
[13:48] <lag> Then why port it?
[13:49] <berco> lag: ogra: can you please invite me to your audio brainstorming too?
[13:49] <lag> berco: Of course
[13:49] <cjjnjust> I just want to add some driver on it .
[13:50] <cjjnjust> use the default config can't work.
[13:50] <lag> You can use it as a base
[13:51] <lag> Then edit it
[13:51] <lag> All of the bring-up and debugging (including earlyprintk) code as already been implemented
[13:52] <lag> All of the addressing setup code too
[13:53] <cjjnjust> In fact, I just do what you say.
[13:54]  * ogra_ac dances ...
[13:54] <ogra_ac> got an ubuntuized kernel for the ac100
[13:54] <lag> cjjnjust: Failing that, take a look at this: http://stackoverflow.com/questions/1359919/arm-data-abort-error-exception-debugging
[13:55] <lag> Will enable you to dump the stack and see where it's going wrong
[13:55] <lag> ogra_ac: Congrats ... booting?
[13:55] <ogra_ac> lag, sure, its the toshiba source but with ubuntu config
[13:56] <ogra_ac> (still 2.6.29 indeed)
[13:56] <ogra_ac> but all the android crap is gone, i have swp and all modules i can imagine
[13:56] <lag> So long as you're enjoying yourself :)
[13:56] <ogra_ac> i|ll test later what mavericks udev thinks about it :)
[13:57] <ogra_ac> s/swp/swap
[13:57] <lag> I knew what you meant
[13:57] <ogra_ac> lag, well, i have a netbook on which i can do ubuntu arm development, what more would a human need :)
[13:57] <cjjnjust> thanks
[13:58] <ogra_ac> lag, compiling the omap4 kernel package takes just 2h here
[13:58] <ogra_ac> (on external USB disk)
[13:58] <lag> cjjnjust: No problem - best of luck
[13:59] <lag> ogra: Here being?
[13:59] <ogra_ac> on the ac100
[13:59] <lag> It only takes me 15mins :)
[13:59] <ogra_ac> thats a third of what the buildds take
[14:00] <ogra_ac> and 30min less than on the panda
[14:00] <ogra_ac> quite impressive imho
[14:04] <armin76> wow, hows that? tegra and panda should be same speed, no?
[14:05] <ogra_ac> similar
[14:05] <armin76> but 30mins is a lot
[14:17] <rsalveti> ogra_ac: you should be fine with udev: http://paste.ubuntu.com/510877/
[14:17] <rsalveti> minimum is 2.6.27
[14:17] <rsalveti> ogra_ac: with usb on omap4 it takes less than 2 hours
[14:18] <rsalveti> something around 1:50 minutes
[14:18] <ogra_ac> with the new mem speed ?
[14:18] <rsalveti> but this I got when testing with 1gb
[14:19] <robclark> ogra_ac: on panda with usb disk, I built kernel (just running 'make uImage') in ~35 min..
[14:19] <rsalveti> ogra_ac: I have the timing with new mem speed, just need to boot my board
[14:19] <ogra_ac> robclark, ubuntu package ...
[14:19] <robclark> ahh..  I didn't try that
[14:19] <rsalveti> robclark: so, how is it going with usb disk?
[14:19] <ogra_ac> robclark, i build zImage for the tegra in about the same time
[14:20] <robclark> but on MMC card it was ~1hr.. and with USB disk ~35min (for make uImage)
[14:20]  * rsalveti is setting up all the boards again
[15:00] <ogra> bug 657281
[15:00] <ubot2> Launchpad bug 657281 in ubuntu "Kubuntu Maverick on Omap3 & Omap4: screen goes black and never comes back (affects: 1) (heat: 8)" [Undecided,Incomplete] https://launchpad.net/bugs/657281
[15:11] <diwic> lag, any news on the brainstorming meeting? I'll have to go in an hour.
[15:11] <lag> No sorry
[15:11] <lag> lrg: Are you around?
[15:11] <lag> diwic: I can't see it happening today
[15:12] <lag> I'll try and sort something out for another day
[15:12] <lag> XorA: Are you in the same place as lrg?
[15:13] <diwic> lrg, isn't that Liam? I think he knows ALSA userspace better than I :-)
[15:13] <XorA> lag: he is the wrong side of the river
[15:13] <lag> Ah, do you both work from home?
[15:14] <ogra> diwic, but not the ubuntu specifics about it i guess
[15:14] <ogra> i think our setup has a lot of specialities
[15:15] <lrg> lag: I'm here, diwic lets do this tomorrow as I'm seeing some funny things with our mixers that could cause config to fail
[15:15] <ogra> \o/
[15:15] <ogra> someone with a clue
[15:15] <ogra> YAY !
[15:15] <diwic> lrg, aren't you the one designing the use case manager?
[15:15] <lrg> I need to get the mixer thing sorted out and then I should have a better idea whats going on with the config
[15:16] <lrg> diwic: yes, ucm is in perex ucm branch - he's made some changes and I need him to push to master.....
[15:17] <diwic> lrg, so then you probably know alsa userspace as well as I, but I don't mind participating in a brainstorming, if not lrg's mixer fixes is what we need.
[15:18] <lag> lrg: Do you have Rama's contact details?
[15:18] <lag> lrg: Is it worth pulling him in?
[15:20] <lrg> lag: yes, rsrimushnam@ti.com
[15:20] <lag> Okay, I'll send out an email
[15:20] <lrg> lag: Rama is in Dallas so he's probably around atm
[15:20] <lag> How does 15:00 UTC grab everyone?
[15:20] <lag> Tomorrow
[15:20] <lrg> and he does have a working pandaboard
[15:20] <lag> Or Wednesday
[15:21] <lrg> lag: most times are fine for me, Rama has more meetings though
[15:21] <lrg> best find a time suitable for Rama andI'll join
[15:21] <lag> I'll email him and try to get him on here
[15:21] <diwic> works for me, but 14:00 UTC would be even better.
[15:22] <Baybal> is this day a some kind of a holiday in North America?
[15:23] <lag> diwic: The Arm meeting is at 14:00 UTC
[15:23] <lag> Baybal: You mean today?
[15:23] <ogra> Baybal, yes
[15:23] <ogra> its the day for that guy who got lost trying to find india
[15:24] <diwic> lag, so 15:00 UTC tomorrow it is then?
[15:24] <lag> Baybal: It's Columbus day
[15:24] <lag> diwic: Provided Rama can make it, yes
[15:25] <lag> lrg: What's your email address?
[15:25] <lag> berco: Likewise
[15:25] <lrg> lag: lrg@slimlogic.co.uk
[15:27] <lag> Shall we have it in here, or in it's own channel?
[15:29] <lrg> lag: own channel may be best
[15:29] <lag> No problem
[15:31] <prpplague> lrg: greetings earthing
[15:38] <berco> lag: ok for me at 15.00 UTC
[15:39] <berco> lag: d-bercovitz@ti.com
[15:40] <armin76> i'm invited too? *g*
[15:41] <lag> armin76: If you want to be
[15:44] <armin76> j/k
[15:53] <lag> prpplague: David, what are you doing tomorrow @ 15:00 UTC?
[15:54] <diwic> see you in 24 hours then
[15:56] <ojn> armin76/marvin24: it's using a nonstandard load address. I'll see why nvidia decided to change that this week, but for now, if you change it manually in the sources you can boot it through fastboot
[15:56] <ojn> Or, you can flash it instead of fastboot as well.
[15:58] <marvin24> ojn: you mean from 0xe08000 to 0x108000?
[15:58] <marvin24> last is reported by nvflash
[15:58] <marvin24> first is TEXT_BASE in config.mk
[15:59] <ojn> yeah
[15:59] <lag> ndec: sebjan: Do you want in?
[16:01] <ogra_ac> ojn, what are you gusy doing about nvrm_daemon ?
[16:01] <ogra_ac> *guys
[16:03]  * marvin24 hope it's being killed
[16:03] <sebjan> lag: yes, please add me. I'll join if I can
[16:04] <ogra_ac> marvin24, ++
[16:04] <ogra_ac> but you wont get any power management or sound without it
[16:06] <marvin24> ogra_ac: not if you have the right documentation
[16:07] <marvin24> I wish there would be *any* public docu about tegra
[16:07] <marvin24> but even the supplemental chip docu is hidden
[16:08] <ogra_ac> yeah
[16:08] <ogra_ac> evil
[16:08] <ogra_ac> i wish TI would have a netbook like the ac100 already
[16:09] <marvin24> TI is not better, search on the TI website for TPS658600A ...
[16:09] <marvin24> controller on the ac100
[16:09] <marvin24> only features, no docu (for free)
[16:09] <ogra_ac> hmm, i thought i saw wiring docs at some vendor
[16:10] <ogra_ac> platforms like beagle or panda are surely well documented publically
[16:10] <armin76> ogra_ac: touchbook?
[16:10] <ogra_ac> armin76, shudder ?
[16:11] <ogra_ac> armin76, did you ever hold one in your hands ?
[16:11] <armin76> nope
[16:11] <ogra_ac> and did you ever hold an ac100 in your hands to compare
[16:12] <armin76> nope either
[16:14] <marvin24> armin76: care to make another try with uboot on harmony with the modified loader address?
[16:14] <armin76> marvin24: i'll try latter today
[16:14] <marvin24> that would be awesome!
[16:15] <prpplague> lag: not sure why?
[16:16] <lag> We're having a Panda Audio Brainstorming session if you want in
[16:17] <egost_> hi
[16:17] <egost_> i'm playing with pre build ubuntu  on blaze. could someone tell me the usename and passwd please!
[16:17] <hrw> ogra_ac: ac100 on photos looks like polished product. touchbook... looks like beagleboard on steroids
[16:18] <ogra_ac> egost_, i guess yuo need to ask in an internal channel about that image ... but i would suspect something like ubuntu/ubuntu
[16:19] <ogra_ac> hrw, yeah, and one is wobbly all over and falls on its face if you remove your hands from the kbd, the other weights nothing and has a super stable case
[16:19] <egost_> i tried ubuntu/ubunto  doesnt work
[16:19] <egost_> ubuntu/ubuntu  i mean
[16:19] <rsalveti> vstehle: ^
[16:19] <ogra_ac> egost_, where did you get that image ? internal server ?
[16:20] <egost_> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/maverick-preinstalled-netbook-armel+omap4.img.gz
[16:20] <rsalveti> if not you can install a new one by following https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
[16:20] <ogra_ac> i would suspect there is a readme file stored nexdt to it
[16:20] <ogra_ac> egost_, oh, that wont work out of the box
[16:20] <ogra_ac> egost_, see rsalveti's link
[16:20] <rsalveti> egost_: by getting a preinstalled image you need to change mlo, u-boot and unitrd
[16:21] <egost_> i did it
[16:21] <rsalveti> following the link should give you a working image
[16:21] <egost_> i use custom uImage and MLO
[16:21] <egost_> it booted
[16:21] <rsalveti> that's the problem
[16:21] <egost_> but i cannot login
[16:21] <ogra_ac> it didnt exec the uInitrd
[16:21] <rsalveti> at least if it doesn't work with the default uinitrd and u-boot, it's not going to open you the installer
[16:22] <rsalveti> then you don't have a user at the system
[16:22] <ogra_ac> no, you cant loig in if the uInitrd didnt trigger the user setup
[16:22] <egost_> ok i understand
[16:22] <rsalveti> egost_: try first by using these files, then after installing it you can change it the way you like it
[16:23] <egost_> ok i will try it  ths!
[16:26] <jcrigby> ogra_ac, I have a panda board with serial number 750-2151-002(b) and one red wire.  Can you tell me what version that is?
[16:26] <ogra> a red wire ?
[16:26] <ogra> hmm
[16:26] <GrueMaster> Sounds like an ES2.0
[16:26] <ogra> could be es2.0
[16:26] <jcrigby> rework
[16:26] <ndec> jcrigby: is it green or black?
[16:26] <jcrigby> ndec, black
[16:27] <ndec> jcrigby: when did you get it?
[16:27] <GrueMaster> Black:  ES2.0 8L
[16:27] <hrw> egost_: take sd card from board, plug to linux desktop, edit /etc/shadow
[16:27] <rsalveti> 6layers
[16:27] <GrueMaster> hrw: Not the issue.
[16:27] <jcrigby> ndec, got it from asac at Prague
[16:27] <rsalveti> usually the black with red wire is the es2.0 6 layers
[16:27] <rsalveti> that doesn't boot anymore with our kernel
[16:28] <ogra> yeah
[16:28] <ndec> jcrigby: black is 6-layer board
[16:28] <GrueMaster> Oops, rsalveti is right.
[16:28] <jcrigby> ok, that is what I thought
[16:28] <jcrigby> thanks for the verification
[16:29] <jcrigby> JamieBennett, ^^
[16:29] <hrw> jcrigby: another device to be bricked to the wall?
[16:29] <rsalveti> jcrigby: you can still boot it by reverting patch http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=b5485d193f8a422901fe7e401542950970121860
[16:29] <jcrigby> hrw, :)
[16:29] <rsalveti> and using the older x-loader
[16:29] <ndec> jcrigby: hrw: that can be a decent build machine, though..
[16:29] <rsalveti> that's how I'm using mine
[16:29] <ndec> ndec: I think beta image used to work on this board
[16:30] <ogra> ndec, until next security fix of the kernel indeed
[16:30] <GrueMaster> RC should work as well.
[16:30] <JamieBennett> jcrigby: that is sad news :(
[16:30] <GrueMaster> Beta was ES1.
[16:30] <ndec> ogra: so you can use it as a decent build if you disable security updates ;-)
[16:30] <ogra> right, beta only worked on es1
[16:30] <ogra> ndec, heh, yeah
[16:30] <rsalveti> rc should be the best one for es2.0 6 layers
[16:30]  * JamieBennett will be pestering ogra and GrueMaster for some Linaro testing then ;)
[16:31]  * GrueMaster thinks JamieBennett can buy his own board when they ship.  :P
[16:31] <hrw> JamieBennett: soon I will be able to do linaro testing on pandaboard too
[16:31] <hrw> GrueMaster: first they have to sale...
[16:31] <JamieBennett> GrueMaster, hrw: need it sooner than that
[16:32] <hrw> JamieBennett: refresh TI contacts?
[16:33] <rsalveti> JamieBennett: what do you need to test on it?
[16:33] <JamieBennett> rsalveti: I need to see if our Linaro images work for a start
[16:34] <ogra> JamieBennett, as long as they use the ubuntu kernel and bootloader :P
[16:34] <rsalveti> yup
[16:34] <rsalveti> and x-loader
[16:34]  * ogra meant to summarize u-boot and x-loader under bootloader :)
[16:35] <JamieBennett> rsalveti: right they do but that doesn't mean our netbook/ALIP/Plasma Handset/Headless images work, just that they have the right ingredients ;)
[16:35] <ogra> headless will, for sure
[16:36] <GrueMaster> heh
[16:36] <ogra> all the rest depends on what driver support you need i guess
[16:36] <GrueMaster> JamieBennett: Can't you test your images with qemu?  :P
[16:36]  * JamieBennett bemoans the lack of hardware
[16:36] <ogra> lol
[16:37] <JamieBennett> GrueMaster: heh
[16:38] <ojn> ogra/marvin24: nvrm is slowly getting replaced, but it's not a small project
[16:38] <ojn> power management should work fine without it
[16:39] <ogra> ojn, awesome to hear
[16:39] <ogra> well, frequency scaling surely doesnt
[16:39] <hrw> JamieBennett: there always will be lack of hardware
[16:39] <ojn> core should do. other parts of the chip is harder to deal with, as with all other socs.
[16:39] <ogra> ah
[16:40] <ogra> well, i'm kind of stuck with the toshiba kernel
[16:40] <ojn> yeah, then you're sol
[16:40] <hrw> ogra: binary or source?
[16:40] <ogra> hrw, source
[16:40] <ogra> but 2.6.29
[16:41] <hrw> eclair one?
[16:41] <ojn> nvidia legacy sources are _horrible_. wince code ported over to linux, as far as I can tell.
[16:41] <ogra> yeah, there are a lot of references to windows in the code
[16:41] <ogra> even to x86
[16:41] <ogra> hrw, 2.6.29 one
[16:42] <ogra> there are android patches but i disabled them all
[16:42] <GrueMaster> Sweet,
[16:42] <NCommander> ojn: what's nvidia legacy?
[16:42] <ojn> NCommander: their old port, not the one re-done by us and android.
[16:42] <ojn> us, them and android, I should say.
[16:42] <ogra> weho cares about android :P
[16:43] <NCommander> ojn: you mean tegra or something?
[16:43] <ojn> ogra: they're doing good work on the base platform support in this case. :-)
[16:43] <ojn> Ncommander: yeah
[16:43] <ogra> ojn, indeed :)
[16:43] <NCommander> ojn: is there a less sucky base port?
[16:43] <ogra> but i dont want their modules
[16:43] <ojn> NCommander: yes
[16:43] <ogra> NCommander, forget about it on the ac100
[16:43] <ojn> ogra: the linux-tegra- branch in their kernel/tegra.git is android-free
[16:43]  * NCommander is a cyanogenmod developer, and we've re-ported several HTC device ports
[16:44] <NCommander> ojn: trivial to re-add
[16:44] <NCommander> I have a list of the patches somewhere
[16:44] <ojn> (tne android-tegra- branch is the one with the android pieces)
[16:44] <NCommander> But its mostly openbinder, the rest is just gravy
[16:44] <ojn> NCommander: I don't know what you're talking about. I'm _not_ working on android, and I'm not interested in it.
[16:44] <Baybal> can we port upstream onto it?
[16:44] <Baybal> good morning
[16:44] <NCommander> ojn: I was just bringing up that the android stuff isn't really that crufty
[16:44] <NCommander> Baybal: onto what? AC100?
[16:44] <Baybal> yes
[16:45] <ojn> NCommander: yeah, they seem to be active on .35 at the moment
[16:45] <ogra> Baybal, which upstream ?
[16:45] <NCommander> Probably. Depends how extensive tegra's mods are, but I don't really feel like playing with Russell King when I'm not a kernel dev
[16:45] <Baybal> kernel.org
[16:45] <ogra> Baybal, if nvidia sends their surces upstream, sure
[16:45] <ojn> Baybal: kernel.org is not quite there for tegra. Stuff is queued up, but what's already merged is just very basic stuff
[16:45] <ogra> NCommander, tegra isnt so bad
[16:46] <NCommander> ogra: I haven't poked their tree. If they're using proper git, then that helps a lot
[16:46] <ogra> NCommander, toshiba adds sauce on top that needs a lot of work
[16:46] <ojn> *yawn*
[16:46] <ojn> Ok, have fun guys.
[16:46] <NCommander> ogra: hrm. If I ever bother to port AC100 to cyanogenmod (which is doubtful, Ubuntu is more interesting), I'll probably work of NVIDIA's tree and then manually add the Android kernel bits
[16:46] <NCommander> Lot less messy.
[16:46] <Baybal> but I hope, Tosh didn't remap registers?
[16:47] <ogra> NCommander, i thought david got an ac100 for you
[16:47] <NCommander> ogra: I won't get it until UDS.
[16:47] <NCommander> ogra: and I still have to track a power plug down for it, as davidm didn't bring it
[16:47] <NCommander> ogra: I haven't looked at the kernel situation yet, but I'd love ot see the kernel in archive if possible ...
[16:47] <ogra> NCommander, only the wire
[16:48] <ogra> NCommander, no way
[16:48] <ogra> NCommander, you only need the cable from the wall to the power brick
[16:48] <NCommander> ogra: I take it stock tegra kernel doesn't boot?
[16:48] <ogra> costs $2 or so
[16:48] <NCommander> ogra: ah, i got like 10 of those at home, and GrueMaster probably has a box full
[16:48] <ogra> NCommander, no, there are ODM patches
[16:49] <ogra> i have the source and have a properly ubuntuized kernel running here
[16:49] <ogra> but o wont forward port it
[16:49] <NCommander> ogra: ODM?
[16:49] <NCommander> oh
[16:49] <NCommander> d'oh
[16:49] <ojn> ogra: ah, you were able to replace the kernel after all? nice
[16:49] <ogra> and that still only gives you basic support
[16:49] <NCommander> (and yuck)
[16:49] <ogra> ojn, yeah, got the source on friday
[16:49] <Baybal> is this Toshiba oem_ec a register based interface?
[16:49] <ogra> huge ugly tarball
[16:49] <NCommander> ogra: got a link?
[16:50] <ogra> http://share.grandou.net/ac100/
[16:50]  * NCommander downloads
[16:50] <ogra> NCommander, i also have a boot.img and kernel modules for it packaged up
[16:50] <ogra> ping me once you get yours
[16:50] <ogra> even though i might have a proper maverick image ready by then
[16:50] <NCommander> ogra: thanks. I'm going to just look to see how far this tree diverges from cm-kernel tip.
[16:51] <ojn> ogra: what wifi chipset does it use?
[16:51] <NCommander> (probably very, but depending on how (in)sane it is, I might be able to convince someone to do a port)
[16:51] <ogra> ralink 3070
[16:51] <ogra> or at least something that runs with that driver
[16:51] <ojn> ok
[16:52] <ogra> rsalveti, btw, thanks for the udev tip, maverick udev runs fine now
[16:52] <rsalveti> ogra: cool
[16:52] <ogra> sadly xorg still needs an xorg.conf and the kbd driver :/
[16:52] <rsalveti> well, getting better
[16:52] <rsalveti> :-)
[16:52] <ogra> but that and disabling pulse should be the only hacks left
[16:52] <ogra> i wish i knew what nvrm_daemon does to enable the codec
[16:53] <NCommander> ogra: magic poke? :-)
[16:53] <hrw> ogra: I think that it will take some time before xorg.conf will finally die. on my desktop I still have one
[16:53] <ogra> i have proper alsa devices but nothing attached until nvrm:daemon runs
[16:53] <ogra> hrw, well, i need it for the input devices
[16:53] <hrw> ogra: I for output ;D
[16:53] <ogra> the stuff that was supposed to magically work
[16:54] <ogra> output works out of the box through framebuffer
[16:54] <ogra> and its not slow
[16:54] <GrueMaster> same here on my desktop.  Nvidia dual monitor configuration.
[16:55] <ogra> what bothers me is that we blantly dropped the kbd driver
[16:55] <hrw> GrueMaster: ati opensource + two monitors here
[16:55] <ogra> since "all keyboards work through evdev now"
[16:55] <ogra> which obviously isnt true
[16:55] <vstehle> rsalveti: Hi! I wanted to warn you: I will rename the sgx-dkms package on the PPA.
[16:55] <rsalveti> vstehle: ok, thanks :-)
[16:55] <vstehle> rsalveti: It will be called 'pvr-omap4-kernel-dkms'
[16:56] <vstehle> rsalveti: (Could not find a longer name ;)
[16:56] <rsalveti> yeah, better one
[16:56] <hrw> ogra: you meant "all 8bit keyboards" I think
[16:56] <ogra> vstehle, i culd make one up if you ran out of chars
[16:56] <vstehle> ogra: :)
[16:56] <ogra> hrw, well, i doubt mine has more than 8bit stuff ... but it isnt recognized at all
[16:57] <ogra> i need to compile the kbd driver package from debian to make it work
[16:57] <NCommander> ogra: so you need to use the tobisha tree and not the tegra tree to get a working AC100 kernel? :-/
[16:57] <ogra> and need the xorg.conf for all input devices
[16:57] <hrw> ogra: I have keyboard which has 9bit keys... works on linux console but not in x11 ;(
[16:57] <ogra> NCommander, xactly
[16:58] <ogra> NCommander, the diff between both would be intresting
[16:58] <NCommander> ogra: I suspect its got to be relatively minimal
[16:58] <ogra> NCommander, but the toshiba tarball doesnt have git references in it i think
[16:58] <NCommander> yeah
[16:58] <NCommander> I'm looking at that now
[16:58] <ogra> so diff and patch are your tools here
[16:59] <ogra> heh
[16:59]  * ogra just tried a minimally modified panda image on the ac100
[16:59] <ogra> works fine
[16:59] <GrueMaster> sweet.
[17:00] <ogra> xorg, xserver-xorg-input-kbd, diverting the pulse binary and unpacking my modules tgz on it
[17:00] <ogra> even my BT dongle works now
[17:00] <rsalveti> cool
[17:02] <NCommander> ogra: looking at nv-tegra.nvidia.com, it looks like everything Tobisha did is in the 2.6.29 branch ...
[17:02] <marvin24_DT> ogra: do you think it's worth a try to get u-boot running on ac100?
[17:02] <ogra> marvin24, sure, why not ... i would love to not need a second machine to upgrade the kernel
[17:03] <ogra> mvflash is really annoying
[17:03]  * NCommander would agree except we have no user-accessible serial port so it would be a bit tricky
[17:03] <marvin24_DT> good, I made a small patch based on harmony, but no luck up to now
[17:03] <NCommander> ^- to dothe port
[17:04] <marvin24_DT> I don't know how to setup this mux things and there is no docu
[17:04] <ogra> NCommander, there is an OTG port ... if you can wire it up in u-boot to be serial you are all set
[17:04]  * rsalveti lunch
[17:04] <ogra> but even without, having a bootloader that can read from vfat is still better than flashing
[17:04] <NCommander> ogra: that requires fun low-level code :-/
[17:04] <NCommander> and a USB stack
[17:04] <ogra> i'm sure tegra has something like that
[17:05] <ogra> there is kernel code to steal from
[17:05]  * NCommander git clone's the tegra kernel
[17:05] <NCommander> I'm *really* curious on how far Tobisha changed things
[17:07] <ogra> they added definitely LCD code
[17:08] <NCommander> right, but that's a driver
[17:08] <NCommander> As long as arm/arch/* hasn't been heavy modified, it should be pretty straightforwad to get a stock 29 kernel going on the ac100
[17:09] <ogra> look for the paz00 (or similar) dir
[17:09] <ogra> that should have the ODM specific bits
[17:11] <NCommander> ogra: Tobisha forked off NVIDIA release 9.12.10
[17:12] <ogra> right
[17:12] <NCommander> now to just generate a diff and to see how extensive they changed things
[17:13] <hrw> playing with vendor kernels... suxx always
[17:14]  * NCommander loves git clone --reference
[17:14] <NCommander> hrw: well, we'll see how high the suckage factor is
[17:15] <hrw> yes
[17:15] <marvin24_DT> NCommander: there is a patch at http://attachments.wetpaintserv.us/yl1upugLD3-jVOiRg2dsLQ1360988
[17:15] <marvin24_DT> against eclair-9.12.12
[17:15] <hrw> lot of time passed since http://marcin.juszkiewicz.com.pl/2007/06/21/extracting-diffs-from-vendor-kernels/ post... I learn new tricks, more people to ask ;D
[17:15] <hrw> anyway - time for me
[17:17] <NCommander> marvin24_DT: http://git.chromium.org/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary
[17:17] <hrw> have a nice rest of day
[17:17] <marvin24_DT> NCommander: yeah, I know
[17:18] <marvin24_DT> lp/~marvin/ac100/u-boot has some patches
[17:18] <marvin24_DT> problem is, no console ...
[17:19] <ogra> make it hardcoded look for mmcblk1p1 and fatload boot.scr
[17:19] <ogra> the you dont need a console
[17:19] <ogra> *then
[17:19] <ogra> its a bit of a blind flight, but if it works you can just edit boot.scr
[17:21] <NCommander> hrw|gone: ugh, this is a nasty pile of hacks
[17:21] <NCommander> er marvin24_DT & ogra
[17:21] <ogra> heh, news at ten
[17:22] <NCommander> its not super bad ...
[17:23] <NCommander> Bit messy, but servicable
[17:24] <NCommander> if tegra had a proper master tree, I'd probably look at porting this onto their HEAD ...
[17:24] <ogra> NCommander, ojn has a good tree i heard
[17:24] <NCommander> ogra: for Tegra or AC100?
[17:24] <ogra> for tegra
[17:25] <NCommander> hrm
[17:25] <NCommander> I'll have to look at it, but this is actually not bad at all
[17:25] <NCommander> There's some board specific code that probably needs refactoring, but the vast maority are minor driver tweaks
[18:39] <marvin24_DT> ogra: I'm a little confused how to setup an u-boot script, I guess you are more familar with that (and u-boot)
[18:45] <marvin24_DT> ogra: I added you to my launchpad (u-boot+kernel) project in case you are interested
[18:52] <armin76> marvin24_DT: -TEXT_BASE = 0x00e08000
[18:52] <armin76> +TEXT_BASE = 0x00108000
[18:53] <armin76> thats what i should do?
[18:57] <devilhorns> ogra, have a minute ?
[19:03] <marvin24_DT> armin76: yep
[19:03] <marvin24_DT> it at least changes something here (usb went way)
[19:03] <armin76> oh, damn
[19:03] <armin76> i did it wrong yesterday
[19:04] <marvin24_DT> ?
[19:04] <armin76> i put u-boot instead of u-boot.bin :D
[19:04] <armin76> it works now
[19:04] <marvin24_DT> with changed address?
[19:04] <marvin24_DT> or without?
[19:05] <armin76> with
[19:05] <marvin24_DT> great!
[19:05] <armin76> let me test with the original one
[19:07] <armin76> nope, doesn't work
[19:09] <marvin24_DT> ok, thanks for testing!
[19:10] <armin76> http://dpaste.com/256412/
[19:10] <armin76> np, thanks for telling me about the load addr :)
[19:10] <marvin24_DT> thanks should go to ojn
[19:11] <marvin24_DT> but it seems that it does not find the flash?
[19:11] <armin76> seems like it
[19:28] <armin76> marvin24_DT: but you can't kinda flash uboot, can you?
[19:28] <marvin24_DT> armin76: you could try to flash it as a kernel and see if it boots up
[19:29] <ojn> yeah
[19:29] <ojn> that's the easiest way to do it on a current fastboot setup
[19:29] <ojn> just give it as the kernel argument
[19:29] <marvin24_DT> ojn: why is the flash not detected?
[19:29] <marvin24_DT> still TODO?
[19:31] <armin76> i have tried that, didn't work
[19:32] <marvin24_DT> maybe again a problem with the init vector
[19:35] <ojn> marvin24_DT: what flash?
[19:35] <marvin24_DT> see http://dpaste.com/256412/
[19:35] <ojn> armin76: ok. I haven't tried recently, so things might have changed
[19:36] <ojn> marvin24_DT: Ah, emmc. Well, probably because the emmc is not on that controller on your board? which one is that on? harmony?
[19:36] <ojn> THe MMC that is probed is the one next ot the PCI-e slots there, not the bayonet one. :(
[19:37] <armin76> bayonet?
[19:37] <marvin24_DT> probing is done in board/tegra2/common - correct?
[19:39] <ojn> armin76: the one that klicks in and out. the one ont he other side doesn't.
[19:39] <armin76> oh
[19:39] <ogra_ac> wohoo !!
[19:39] <ogra_ac> 3G works
[19:40] <ogra_ac> horrible lag but enough for IRC
[19:41] <ogra_ac> asac, is it normal that i have to configure the connection before inserting the SIM ?
[19:41]  * ogra_ac found that very confusing
[19:44] <marvin24_DT> ah, probing is done in tegra_sdmmc
[19:44]  * marvin24_DT needs a serial console
[21:05] <hrw|gone> NCommander: that was over 3 years ago post
[21:05] <hrw|gone> ah..
[21:05]  * hrw|gone off
[22:05] <vstehle-home> lool: Hello Loïc, are you awake? I am desperately looking for an URL about "croco". Would you have this at hand, please?