[08:03] <stm__> hi all
[08:03] <stm__> iam using root stock to build filessystem
[08:04] <stm__> iam following  from here http://elinux.org/BeagleBoardUbuntu
[08:04] <stm__> now iam building it for pandaboard
[08:05] <stm__> i have doubt in the --seed  mentioned in above link
[08:05] <stm__> document says
[08:05] <stm__> "--seed linux-image-omap"
[08:06] <stm__> for beagle board
[08:06] <stm__> what should i relace for the pandaboard
[08:29] <MrCurious> is there a way to tell the cpu temp on ubuntu 11.04 on a panda board?
[16:22] <mahmoh> problem: PXE -> netboot is hanging for me on panda:  http://pastebin.ubuntu.com/641355/  and  http://pastebin.ubuntu.com/641394/   any help would be appreciated
[16:24] <GrueMaster> Give me a sec as I am still pulling the latest netboot stuff (& getting properly caffienated).
[16:27] <persia> mahmoh, Do you have anything connected to HDMI?  If so, maybe try without "debian-installer/framebuffer=false console=ttyO2,115200n8"
[16:28] <mahmoh> persia: it's all remote so I'll have to check tomorrow, that was another thing under debug-todo
[16:28] <persia> Ah.  Remote makes it trickier :)
[16:28] <mahmoh> more fun that way
[16:31] <GrueMaster> That's why I am taking a look.
[16:32] <GrueMaster> mahmoh: Tell me how you have the system setup to boot so I can replicate.
[16:32] <persia> Do you know if your serial tool closes on HUP?  I wonder if there's a HUP or BREAK sent between u-boot and linux.
[16:32] <Jotschi> Is there somewhere a git tree containing a more recent version of the linux omap4 kernel? (newer than 2.6.38) natty tree contains only upto 2.6.38 and the Oneiric omap4 branch contains also 2.6.38
[16:32] <mahmoh> it's open all the time
[16:33] <persia> Jotschi, A specifically Ubuntu kernel, or any kernel?
[16:33] <GrueMaster> Jotschi: There is work being done on 3.0, but it is full of segfaults atm.
[16:34] <Jotschi> I need the omap4 ubuntu kernel because it seems it is the only kernel (at least i know of) that supports the powervr graphics driver.
[16:34] <persia> That's ABI-dependent, not code dependent.
[16:35] <persia> The issue being that the powervr driver is only distributed as binary blobs, so need to be used with a kernel they were linked against.
[16:35] <mahmoh> GrueMaster: tftp & dhcp, the config above sits in the tftboot/pxelinux.cfg directory with as the IP in hex (or 00000000 in my case)
[16:36] <mahmoh> GrueMaster: I'm not using dhcp for now since I'm setting ipaddr and serverip manually along with kernel_ram and initrd_ram (0x80000000 / 0x81600000 )
[16:38] <Jotschi> persia, i see but why is that so? Other binary drivers can be used with multiple kernel version. I was told that the kernel itself needs to contain some sort of code to work with the powervr driver. Sorry don't have any further info on that topic.
[16:39] <persia> Jotschi, Most of the binary drivers that work with multiple kernel versions have some sort of open-source shim layer, which translates the ABI of the kernel it is compiled against to the ABI required by the binary driver.  To my knowledge, nobody has done this for the powervr drivers.
[16:39] <persia> The few exceptions are wildly lucky accidents, and inherently untrustworthy in the face of continued kernel development.
[16:40] <persia> http://git.linaro.org//linux-linaro-oneiric.git has some 2.6.39 stuff, but everything is upstreamable there, so it may not include the binary stuff (I'm not sure).
[16:43] <persia> http://kernel.ubuntu.com/ppisati/ubuntu-oneiric.git has some 3.0 stuff, but is known buggy work-in-progress.
[16:44] <persia> I don't know against precisely which tree the demo of powervr running unity was built, but I know that this isn't all uploaded to Ubuntu yet.
[16:48] <mahmoh> GrueMaster: manual bootargs didn't work any better for me
[16:50] <Jotschi> persia, i see. Thanks for the explanation.
[16:58] <persia> mahmoh, If you manually load that kernel and initrd with no PXE, does it behave as expected?
[16:59] <mahmoh> persia: haven't tried but I think GrueMaster did.  I'll add it to my todo for tmw when I can physically assault the panda ;)
[17:00] <GrueMaster> I've booted the netboot images with no problem before. Haven't tried the latest yet (just pulled it).
[17:00] <mahmoh> GrueMaster: pls let me know if the latest works for you
[17:02] <persia> mahmoh, You ought to be able to do it with just a serial connection and remote power control, if you can load u-boot.
[17:02] <persia> Worst case, PXE-boot u-boot so you have a console.
[17:03] <GrueMaster> Ok, latest netboot (boot.img-serial) behaves as it should.  Has to be something either with the pxe cfg or u-boot's pxe internals.
[17:03] <GrueMaster> I have d-i running over serial console.
[17:03] <mahmoh> I'm in u-boot now ... do you mean the usb-boot?  I can't drop anything onto the MMC remotely - at least I didn't know that I could
[17:03]  * GrueMaster goes back to enabling pxe environment.
[17:04] <persia> mahmoh, No, I mean u-boot.  Since you have a working ethernet driver in u-boot, you ought be able to load the images over the network from the u-boot console.
[17:04] <mahmoh> GrueMaster: can you try it using just the uImage and uInitrd and not the boot.img  to get a bit closer to what I'm doing?
[17:04] <persia> mahmoh, Once you have the images loaded, then bootm as normal.
[17:06] <mahmoh> ah, I see, trying ...
[17:06] <GrueMaster> mahmoh: I first need to re-enable pxe on my server & dhcp server.
[17:08] <mahmoh> persia: that worked!
[17:09] <mahmoh> uh, but I forgot to specify the initrd ;)
[17:09] <persia> mahmoh, Excellent.  You have now verified that the issue is not with the uImage and uInitrd!
[17:09] <persia> Now, check to see what is different about u-boot directly loading things and u-boot being instructed by PXE...
[17:09] <mahmoh> persia: user error ;)
[17:10] <mahmoh> that may be above my pay grade
[17:11] <mahmoh> old joke, worry
[17:11] <persia> Right.  Troubleshooting 101 :)
[17:11] <mahmoh> sorry even
[17:11] <persia> So, first check your u-boot console output to see if anything is different before control was handed over to linux.
[17:13] <mahmoh> persia: the only difference that I "see" is that the kernel boots with bootm and doesn't with pxe boot
[17:13] <persia> There doesn't appear to be any difference in the addresses from which things load or anything else?
[17:13] <persia> That's annoying.
[17:14] <persia> Next, check to see if there is a way to get u-boot into verbose mode, and try both again with more verbose information.
[17:14] <mahmoh> I can try reversing the entries to see of that makes a difference, since it tried to boot the lastly loaded initrd first last time
[17:14] <persia> Given the u-boot output you pasted before, I strongly suspect the problem lies in the passing of the boot arguments.
[17:14] <mahmoh> don't know how to do that, GrueMaster jcrigby rsalveti - u-boot verbose mode or debug mode?
[17:15] <persia> Maybe worth trying: I'm a big fan of understand-before-doing but doing-to-understand has a huge history.
[17:15] <persia> mahmoh, You'd have to recompile, setting DBGFLAGS in config.mk
[17:16] <mahmoh> you learn better that way, I agree
[17:16] <persia> Not necessarily: engineers have been known to discover all sorts of things that confused scientists (although the opposite is also true).
[17:17] <mahmoh> maybe I can con one of these guys ^^^ to recompile and provide both binaries for a while, if not I'll get to it tomorrow then
[17:18] <persia> Recompiling: `apt-get source foo; cd foo-${version); edit-some-stuff; dch -i 'Fiddle around'; debuild -b`
[17:18] <mahmoh> noted, thx
[17:20] <persia> I'm just not a fan of being stuck waiting.  If you feel like doing something else, go ahead.  If you feel frustrated and stuck, I'm happy to help give hints (where I can) to help you keep going.
[17:20] <mahmoh> persia: I appreciate that
[17:20] <GrueMaster> mahmoh: So far I am still in the setup phase.  It looks like on reset, it is looking for panda/netboot.scr via bootp.  What do you have for that?
[17:21] <mahmoh> GrueMaster: interesting, I don't - I think that's for bootp and I'm doing pxe so ... but I might use that as a fallback until pxe is working
[17:22] <GrueMaster> So when u-boot starts, you interrupt it and set things manually?
[17:23] <mahmoh> right now I have been, yes
[17:29] <MrCurious> is there a way to tell the cpu temp on ubuntu 11.04 on a panda board?
[17:29] <GrueMaster> Interesting.  On boot, it tries to load either boot.scr, uEnv.txt, or uImage from the SD before switching to bootp to find panda/netboot.scr.  I am going to try creating this file.  Should be similar to boot.scr in format.
[17:34] <GrueMaster> Ok, that appears to work...somewhat.
[17:35] <GrueMaster> It is kind of painful waiting for pxe to whittle down the mac addr before loading pxelinux.cfg/default.
[17:36] <mahmoh> MrCurious: donno but once I'm installed I'll check unless someone else beats me to it, check the panda specs and see if there's a temp sensor, if there is (I'm guessing so) there should be a way to grab the info out of sys or proc or some other utility (lm-sensors)
[17:36] <mahmoh> GrueMaster: save default as 00000000
[17:36] <mahmoh> or link it
[17:38] <persia> MrCurious, There is an i2c bus, but it looks like the support in i2c tools didn't land until 3.0.3: you may need to backport or run oneiric to use them.
[17:38] <GrueMaster> Actually, pxelinux uses the mac address, not ip.  It needs to be panda/pxelinux.cfg/C0A80040.
[17:38] <MrCurious> no worries, iwill wait for next release then
[17:38] <MrCurious> ty
[17:39] <persia> MrCurious, If you have a spare SD, and want to try the Alpha, someone filing bugs about i2c issues would likely help make sure that we have full support in oneiric :)
[17:39] <persia> (mind you, if you have time to spare from constructing our new robotic overlords :) )
[17:40] <GrueMaster> mahmoh: I am now able to boot with MLO & u-boot only on SD.  It pulls panda/netboot.scr using bootp.  That file is http://paste.ubuntu.com/641426/
[17:41] <GrueMaster> But it is failing using the pxelinux.cfg file you linked.
[17:41] <GrueMaster> missing environment variable: initrd_ram
[17:41] <mahmoh> GrueMaster: yeah, that's why you have to do it manually
[17:42] <mahmoh> or you can include those two in the uEnv.txt if you want for now
[17:42] <GrueMaster> Nothing should be done manually (that's the point in this exercise).
[17:42] <mahmoh> I think jcrigby will fix once we have a working formula ;)
[17:45] <persia> If the uEnv.txt is provided over the network, is this used?
[17:46] <mahmoh> I don't believe it can be now, just on the SD
[17:48] <GrueMaster> uEnv.txt, no.  But you can create a netboot.scr and put it on the tftp server under panda/netboot.scr.  Use mkimage to create it.  Same format as boot.scr.
[17:48] <persia> Oh, cool.  That gives much richer control over the command line, etc.
[17:49] <persia> Is it safe to just grab one of the boot.scr files from the netboot page, and rename that?
[17:49] <prpplague^2> GrueMaster: you tinkering with the lan9514 support in u-boot?
[17:49] <GrueMaster> persia:  not quite that simple, but close.  prpplague^2 yes.
[17:50] <GrueMaster> ok, I think I have all the right sauce, rebooting.
[17:50] <prpplague^2> GrueMaster: dandy, i just heard about the support last week
[17:52] <persia> GrueMaster, What needs doing to convert boot.scr -> netboot.scr?  Should d-i spit out some netboot.scr files?
[17:52] <GrueMaster> hrm.  File not found loading panda/uInitrd.
[17:53] <GrueMaster> persia: eventually we can have d-i generate them.  Let me figure out what it needs specifically first.
[17:54] <persia> GrueMaster, Sorry.  I thought maybe that was known.  No hurry :)
[17:54] <GrueMaster> Currently, mine looks like this:  http://paste.ubuntu.com/641432/
[17:54] <GrueMaster> Getting closer.  Just not sure why it failed to load the kernel & ramdisk.
[18:04] <GrueMaster> interesting.  Something is off with pxelinux.cfg/default.  When I run 'tftpboot 0x81600000 panda/uInitrd' it loads fine.  Using the pxelinux.cfg mahmoh supplied, it fails.  Same file is attempted to load.
[18:06] <GrueMaster> Seems to be a bug in the pxe handler.
[18:06] <persia> Very strange.
[18:08] <GrueMaster> My u-boot output.  http://paste.ubuntu.com/641435/
[18:09] <mahmoh> do you have that file under your tftp root?  panda/uInitrd ?
[18:09] <GrueMaster> yes.
[18:10] <GrueMaster> Note the chopped '.lename ' line.  Very odd.
[18:11] <mahmoh> do you have both the uImage and uInitrd under the tftp root also?  I'm unsure why it's looking for it both under / and panda/
[18:12] <GrueMaster> It works when I use tftpboot to load them.  Same path.
[18:12] <mahmoh> I can get it to load but then it dies after booting the loaded files (via pxe boot)
[18:12] <GrueMaster> What address are you using for pxecfg_ram?
[18:12] <mahmoh> right, same here.  0x816000000
[18:13] <mahmoh> 0x81600000
[18:13] <GrueMaster> That should be for uInitrd.
[18:13] <mahmoh> it looks like it has both paths
[18:14] <GrueMaster> Mine is defaulting to 0x88000000
[18:14] <mahmoh> I think that's were it's loading the pxe config file
[18:15] <GrueMaster> That's why I was asking.
[18:15] <GrueMaster> Do you have the READE.pxecfg from the u-boot source?
[18:15] <mahmoh> yea
[18:15] <mahmoh> oh, you need a full pxe config!
[18:18] <mahmoh> GrueMaster: try this one - http://paste.ubuntu.com/641441/
[18:18] <mahmoh> that should work with your setup, it may even really work for you if my theory is correct
[18:20]  * persia suspects the failure to load uInitrd above was a spurious carriage return somewhere
[18:25] <GrueMaster> mahmoh: The "panda/" is redundant.  By default it looks in that directory on the tftp server.
[18:25] <mahmoh> GrueMaster: it's not for pxe unless you setup your tftp root to be panda/
[18:26] <GrueMaster> With your config, I now get "Retreiving file: panda/panda/uInitrd"
[18:26] <GrueMaster> So, yes it is.
[18:27] <GrueMaster> That or you are using a different u-boot.bin than I am.
[18:27] <mahmoh> wha?  that doesn't make sense
[18:27]  * mahmoh reviews the pastebin again
[18:28] <GrueMaster> Put all of your config files & u-boot.bin in a tarball and throw it up on people.u.c for me to compare.
[18:30] <mahmoh> GrueMaster: do me one favor then and remove the leading panda from both the kernel and initrd in the pxe config and try that
[18:30]  * mahmoh waits another 30 mins. for netboot install to complete!
[18:30] <mahmoh> on an sd card that is
[18:31] <GrueMaster> mahmoh: see my earlier pastebin for my config.  It has the correct path, but there is something broken in the pxecfg boot. sequence.  I can manually pull the uInitrd just fine.
[18:32] <mahmoh> GrueMaster: you need the first four lines from http://paste.ubuntu.com/641441/
[18:33] <GrueMaster> mahmoh: no, you don't.  They make absolutely no difference.
[18:33] <GrueMaster> The DEFAULT only fails, the IPAPPEND is ignored.
[18:34] <GrueMaster> Ignoring unknown command: IPAPPEND
[18:35] <mahmoh> GrueMaster: then our setups are very different, I'll send you what I have once my netinstall finishes so you have exactly what I have, if the boot fails you'll have to wait until tmw
[18:35] <GrueMaster> I am getting different output from u-boot.bin than you are, and I am using the u-boot.bin from the deb you linked.  So again, please send me a tarball so I can compare the two.
[18:37] <persia> Or, if there is some technical limitation in sending a tarball, at least all of filesize, md4sum, sha1sum, and sha256sum (as triple collisions are rare)
[18:38] <GrueMaster> persia: Total tarball size should be less than 1M.
[18:38] <persia> I know.
[18:40] <mahmoh> I can email
[18:40] <GrueMaster> that works too.  Sent it to me @ gmail.com (same userid).
[18:41] <GrueMaster> Gets here faster w/o skipping back & forth over the pond.
[18:45] <mahmoh> GrueMaster: this is the one I gave you before?  this is the one I think I'm using (still waiting on the install) http://launchpadlibrarian.net/74393697/u-boot-linaro-omap4-panda_2011.06.5-0ubuntu1_armel.deb
[18:45] <GrueMaster> That's what I am using.
[19:37] <GrueMaster> Ok, I took a break from mucking with the pxe stuff and just ran tftpboot manually to pull the kernel & initrd (after pxecfg had errored out).  It boots into netinstall no problem.  So there is still something off with the pxecfg stuff, either in the script files or in u-boot.bin.
[19:37] <persia> Nice reduction of the problem!
[19:38] <persia> Has anyone tried the same PXE scripts on some device with native PXE support in shipped firmware?
[19:38] <persia> Obviously, it would need different kernel/initrd, but the netinstall stuff for the appropriate architecture should be in a parallel location.
[19:39] <GrueMaster> I tried the pxe config example in the README.pxecfg that is part of the u-boot source.  It has all kinds of fail (beyond the kernel stuff).  It has an issue chaining pxelinux.cfg files.
[19:39] <mahmoh> if you mean non-arm then yes, I know my pxe setup works
[19:40] <persia> mahmoh, I don't really care about the architecture, but I do mean not using the u-boot you're testing on pandas.
[19:40] <persia> For the alternate device, have you tested with an Ubuntu netinstall image?  With the same method of passing arguments, etc.?
[19:40] <mahmoh> I think the answer is yes then
[19:40] <mahmoh> yes
[19:41] <persia> Well, that's kinda annoying.  It points the problem at u-boot. :(
[19:41] <persia> Didn't someone say they had it working about 10 days ago?
[19:42] <mahmoh> I think we have to update that to pxe is somewhat working, just can't boot with it ;) unless there's another problem
[19:43] <mahmoh> it has to be u-boot, since the uImage and uInitrd work, and the pxe setup and netinstall work, so the only piece left is u-boot
[19:43] <mahmoh> rsalveti: jcrigby: ^
[19:53] <persia> In that case, I think we need a debug build of u-boot to run through the failure scenarios.
[19:53] <mahmoh> agreed
[19:53] <persia> I'm not convinced that it's trivial to have a known verified working PXE environment for most folk.
[19:54] <persia> Is that something you can build locally?  I can prepare something if not, but I don't have a good way to get you my builds in a trusted manner.
[19:59] <mahmoh> persia: I can build the u-boot debug locally but I'd have to set it up, I only need the binary to you could compress and email?
[19:59] <mahmoh> just make 100% sure it's the latest ;)
[19:59] <persia> If you trust email, you're doing it wrong :)  But that's another matter.
[20:00] <mahmoh> persia: there's gpg ;)
[20:00] <persia> I have about the same setup as you, but I've done the setup more times :)
[20:00] <persia> I don't believe we've exchanged keys.  As a result, I doubt you can be sure it's really me (although I suppose you could check against my upload key, which would give you some confidence).
[20:01] <mahmoh> persia: it's a debug u-boot, if someone tries to poison it, I'd love to see it - it would make me smile
[20:02] <mahmoh> I'm sure they'd rather hack at my bank accounts or CC, assuming I have those
[20:02] <mahmoh> at least one would hope
[20:11] <GrueMaster> Ok, figured out what was wrong with my pxelinux.cfg.  Damn paste.ubuntu.com had left some erroneous crlf in the file when I initially pulled it.  Now it is pulling the kernel & initrd properly, but hangs after booting.  Panda leds are in rapid blink.
[20:11] <mahmoh> GrueMaster: ok, so you're stuck where I am now, welcome
[20:12] <persia> GrueMaster, Is that the same hang (based on u-boot output) mahmoh posted earlier?
[20:12] <GrueMaster> No output past loading kernel & initrd.
[20:12] <GrueMaster> Retrying.
[20:12] <mahmoh> looks like it
[20:12] <persia> So, like http://pastebin.ubuntu.com/641355/ ?
[20:14] <GrueMaster> yes.
[20:15] <GrueMaster> Hangs after init ramdisk:  Verifying Checksum ... OK
[20:15] <persia> Well, there's a lot to be said for repeatable results.
[20:15] <mahmoh> so it fails to load the kernel image!
[20:16] <mahmoh> jcrigby: ^
[20:16] <GrueMaster> Not sure that it fails to load the image.  Fails to boot using the pxeboot method.  Looking into it now.
[20:16] <persia> No, the kernel is loaded (see the stanza directly above that).  The issue is just that the kernel doesn't appear to be doing anything at this point.
[20:16] <GrueMaster> But my results match your original pastebin.
[20:17] <mahmoh> ^load^boot
[20:17] <persia> GrueMaster, Do you have HDMI on that device?  Does it generate something there?
[20:17] <persia> Grrr.  My mirror seems unable to build an oneiric armel build environment on my panda today.
[20:17] <GrueMaster> I'll have to switch to YAP for that.  (Yet Another Panda)  :P
[20:18] <persia> mahmoh, I won't be building you a debug build anytime soon.
[20:18] <mahmoh> np
[20:18] <GrueMaster> persia: I can here in a minute.  My babbage is a mini buildd.
[20:19] <persia> Mine is gathering dust, as it only booted the once, which didn't seem reproducible :(
[20:19] <persia> The panda was *supposed* to be a buildd, but the IO options make it less ideal than I'd prefer.
[20:20]  * persia is currently looking at new boards, hoping to find someting a bit more useful: maybe the quickstart or snowball.
[20:20] <GrueMaster> If/when I can break away from here, I plan on going to Fry's and getting some external drive enclosures for my panda's.  I have the drives, just no way to plug them in.
[20:22] <mahmoh> GrueMaster: you won't be using the drives as boot drives will you?  root drives you can
[20:22] <GrueMaster> Ok, same failure on 3 pandas.
[20:23] <mahmoh> no hdmi?
[20:23] <GrueMaster> No, they will only be for rootfs.
[20:23] <GrueMaster> Nothing on hdmi.
[20:23] <GrueMaster> I don't think it is actually jumping to the kernel.
[20:24] <GrueMaster> As I usually get "Starting kernel ..."  Which is from the kernel init code.
[20:24] <persia> What happens if one loads uboot, rather than linux that that point?  Do we jump to the new u-boot?
[20:24] <mahmoh> it's not, that's probably the bug - someone could go look a the code and compare the pxe to the bootp and see what's the diff.
[20:24]  * persia wants to make sure that it's not something related to the kernel command line, but rather a failure to execute-in-place
[20:25] <GrueMaster> I don't know the code that well and it has a lot of platforms it works with.
[20:26] <GrueMaster> persia: If I let u-boot pull the pxelinux.cfg but boot manually, it works fine, meaning it is getting the kernel cmdline from pxelinux.cfg properly.
[20:27] <GrueMaster> What appears to be happening is u-boot's pxe boot code isn't jumping to the right kernel location.
[20:27] <persia> GrueMaster, So the only difference is whether bootm is called manually or in netboot.scr?
[20:27] <GrueMaster> I am running into a time constraint here.  I really need to get these drive enclosures and it is Sunday.
[20:28] <GrueMaster> bootm is called internally by the pxecfg code in u-boot.
[20:28] <GrueMaster> And appears to be wrong.
[20:28] <persia> I suspect you're right.
[20:29] <persia> But go shopping: electronics stores have fixed hours, but #ubuntu-arm doesn't.
[20:29] <GrueMaster> It works if I just use my netboot.scr to manually tftp the kernel & initrd followed by a bootm call.
[20:29] <GrueMaster> Back in several (3+) hours.
[20:37] <mahmoh> nice, root=/dev/sda2 (usb root!) that should speed things up a bit!
[20:38] <persia> By a factor of 4-5, usually.
[20:39] <GrueMaster> Grrr.  Son took the car to the store.
[20:40]  * GrueMaster has to wait to go to Fry's...again.
[20:45] <rsalveti> huge backlog
[20:46] <rsalveti> GrueMaster: mahmoh: what is the current issue?
[20:46] <persia> rsalveti, http://pastebin.ubuntu.com/641355/
[20:46] <GrueMaster> pxecfg boot fails to properly jump into the kernel startpoint.
[20:46] <GrueMaster> to be more precise.
[20:46] <persia> If *anything* is done manually, it works, but from what we can tell, u-boot isn't handing over execution to linux when booted from PXE
[20:46] <mahmoh> rsalveti: pxe boot fails to start the kernel, it loads both uimage + uinitrd, gets to checksum verification, then hangs
[20:47] <rsalveti> GrueMaster: and you said it worked when doing the same steps with tftpboot?
[20:47] <rsalveti> interesting that it's loading the kernel and initrd
[20:49] <GrueMaster> rsalveti: essentially, if I use tftpboot to load the kernel & initrd into their respective memory locations then I can get them to boot using bootm $kernel_ram $initrd_ram.
[20:50] <GrueMaster> but pxecfg boot fails.
[20:51] <GrueMaster> No output on serial console or hdmi.  Only indicator is both leds start blinking very rapidly on the panda.
[20:54] <rsalveti> that means a hang at x-loader/u-boot
[20:55] <GrueMaster> Is there any way to see what pxecfg is doing behind the scenes?  Like a debug switch I can turn on at compile time?
[20:57] <rsalveti> GrueMaster: what are the mem addresses you're loading uImage and uInitrd when doing tftp by hand?
[20:57] <rsalveti> let me check the code
[20:57] <GrueMaster> Same as those used in the normal boot.scr
[20:58] <rsalveti> pxe is using a different address
[20:59] <rsalveti> Load address: 0x81600000
[20:59] <rsalveti> Load address: 0x80000000
[20:59] <GrueMaster> why?  I have kernel_ram & initrd_ram set to use the same addresses.
[20:59] <GrueMaster> That's what I have.
[20:59] <GrueMaster> Unless they are opposite.
[20:59] <mahmoh> yeah, bootp to those same addresses works too
[21:00] <rsalveti> yeah, it should be fine
[21:00] <rsalveti> for some reason my boot.src file is using a different address for uImage
[21:01] <rsalveti> mahmoh: what is the pxe file you're using at the host size?
[21:02] <rsalveti> will try to reproduce the error here
[21:02] <mahmoh> 3.1M 4.M initrd
[21:06]  * GrueMaster won't be able to go to Fry's today, rolls up sleaves and dives back into debugging.
[21:11] <rsalveti> GrueMaster: do you have the pxecfg file in hands?
[21:11] <rsalveti> the one you're using
[21:11] <GrueMaster> Yes.  Where do you want it?
[21:11] <rsalveti> GrueMaster: just paste it somewhere
[21:12] <GrueMaster> http://paste.ubuntu.com/641509/
[21:13] <GrueMaster> Here's my netboot.scr http://paste.ubuntu.com/641511/
[21:14] <GrueMaster> I only have MLO & u-boot.bin on my SD.  On boot, u-boot pulls netboot.scr via bootp.
[21:16] <rsalveti> ok, cool, let me try
[21:43] <mahmoh> GrueMaster: which suites are you running for phoronix?
[21:44] <GrueMaster> I've only ran the disk test suite for benchmarking filesystem performance on SD.
[21:46] <mahmoh> and my board rebooted! great
[21:53] <GrueMaster> mahmoh: So that was a netboot install running through u-boot manually, right?
[22:00] <mahmoh> GrueMaster: via bootp, so almost everything over the net except up to u-boot
[22:02] <GrueMaster> Until the pxecfg issue gets resolved, you could use a netboot.script.  Just add tftpboot to the netboot.scr I posted earlier to pull kernel & initrd.  Not as good as pxe, but workable.
[22:08] <mahmoh> GrueMaster: yeah, I think I may have to do something like that but I'm guessing the pxe issue could get resolved quickly
[22:08] <persia> What's the disadvantage to traditional dhcp+tftp when compared to PXE?
[22:08] <GrueMaster> pxe gives you a menu of boot options and a default.
[22:09] <rsalveti> mahmoh: yeah, hopefully :-)
[22:09] <mahmoh> I have full confidence ;)
[22:09] <rsalveti> finally able to install a working tftp server and such, with a panda able to test
[22:09] <rsalveti> had all my setup at another computer
[22:09] <mahmoh> GrueMaster: so I'm running the apache system test suite with a usb root disk, let's see how that goes
[22:10] <GrueMaster> mahmoh: Are you doing it through jenkins?  I'm still looking into getting that up and running.
[22:10] <persia> GrueMaster, Where does the menu display?  At console, or on the automation host?
[22:10] <mahmoh> not yet, one step at a time
[22:11] <GrueMaster> persia: on the serial console.
[22:12] <mahmoh> bbl
[22:12] <persia> Ah.  So exceedingly useful for local (or remote-serial) activity, and equivalent for the total automation scenario.  Not that I don't like improved ability to troubleshoot or shift defaults :)
[22:13] <GrueMaster> It can be very useful in a fully automated environment.
[22:14] <GrueMaster> But first we need to get pxe working, then make it work more intelligently (instead of having a mac address built in at compile time).
[22:14] <persia> I thought there was a plan to sort that, and generate a meaningful mac address.
[22:15] <GrueMaster> Time for me to do something else for a while.
[22:15] <GrueMaster> There is, just not implemented yet.
[22:15] <persia> Oh, heh.
[22:46] <skymera> xchat for ARM?
[23:12] <persia> So, yeah, xchat is so very available for ARM.