1 of 1 people found this helpful
Unless you have a really good reason to stay with 0.7.5, go with 1.0.0.
0.8.0 is no longer available for download.
The 0.7.5 spi image is broken - the reboot button is not functional. I would move to a later firmware just for that reason, although you can not use the IDE to update any firmware past 0.7.5. Serial cable works great.
I have not seen any problems running with a later firmware and an earlier SD image. I am running 0.9.0 firmware with 0.8.0 image - no problems.
Thanks rmm200, I'm trying to update to the 1.0.0 FW now as per Alex's README instructions:
I've copied the capsule files on to a blank SD (no image on the SD card) and when I try to boot my Galileo and hit 'F7' in PuTTY, I run into an issue. The instructions in Section 10.1 of the BSP Build Guide (in the Download Center) state that you should connect to the serial console and then power-on your device. How is this possible without losing the connection to your Galileo in PuTTY?
Plug your serial cable into your PC. Even without plugging it into the Galileo, PuTTY should be able to open the connection. The USB to serial adapter is powered by your PC end, and requires nothing from the Galileo.
Plug your cable into the Galileo, plug in your power, and you should see all the boot messages in PuTTY.
To enter F7 through PuTTY, make sure you have it configured correctly.. Select SCO on the terminal/Keyboard page for function keys.
Once you get everything communicating, updating the flash is real easy. Good luck!
When you refer to the serial connection, do you mean the USB cable into the Client port or an actual RS232 connector plugged into the 3.5mm jack? With the USB cable plugged into the Client port, I don't see the COM port showing up in windows.
I think what we have here is a failure to communicate...
The serial cable uses what looks like an audio jack on the Galileo. Refer to this post:
The other end is a USB connector that plugs into your PC, The cable contains active logic, like an FDDI chip.
The flash process takes place before any of the Galileo USB or ethernet ports are opened.
Sorry for the delay, got a bit bogged down here.
Gotcha, that makes sense. I'll dig up one of those serial cables and give it a try when I have a chance. I've finally gotten the 0.7.5 SPI image (which I know is broken) to compile in my environment, so I'm going to give the full image and then 1.0.0 a shot.
1 of 1 people found this helpful
Practice is good. On my PC, every build attempt is an overnight run. Don't do like I did - take three tries trying to figure out how big a build disk is needed. Start with 50GB and see how much winds up being used. The option to remove work files cuts the required space about in half. Also note - the build instructions change with each release, so don't just assume you know how to do it based on 0.7.5. Read the docs for the build you are doing. Have fun!
Thanks for the tips, yea it's slowly but surely getting there. I made it to about 2000/3000 packages on the bitbake before my latest fail. It appears that the Python tarball that I downloaded on CentOS 5 (see Re: Bitbake requires Python 2.6 on CentOS 5.7) doesn't have the 'grp' module:
DEBUG: Executing python function sstate_task_prefunc
DEBUG: Python function sstate_task_prefunc finished
DEBUG: Executing python function do_package
DEBUG: Executing python function package_get_auto_pr
DEBUG: Python function package_get_auto_pr finished
DEBUG: Executing python function perform_packagecopy
DEBUG: Python function perform_packagecopy finished
DEBUG: Executing python function split_and_strip_files
DEBUG: Python function split_and_strip_files finished
DEBUG: Executing python function fixup_perms
ERROR: Error executing a python function in /home/mjstanis/meta-clanton_v0.7.5/poky/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:
ImportError: No module named grp
ERROR: The stack trace of python calls that resulted in this exception/failure was:
ERROR: File "fixup_perms", line 228, in <module>
ERROR: File "fixup_perms", line 3, in fixup_perms
ERROR: The code that was being executed was:
ERROR: 0224: each_file = os.path.join(root, f)
ERROR: 0225: fix_perms(each_file, fs_perms_table[dir].fmode, fs_perms_table[dir].fuid, fs_perms_table[dir].fgid, dir)
ERROR: *** 0228:fixup_perms(d)
ERROR: [From file: 'fixup_perms', lineno: 228, function: <module>]
ERROR: 0002:def fixup_perms(d):
ERROR: *** 0003: import pwd, grp
ERROR: 0005: # init using a string with the same format as a line as documented in
ERROR: 0006: # the fs-perms.txt file
ERROR: 0007: # <path> <mode> <uid> <gid> <walk> <fmode> <fuid> <fgid>
ERROR: [From file: 'fixup_perms', lineno: 3, function: fixup_perms]
DEBUG: Python function fixup_perms finished
DEBUG: Python function do_package finished
ERROR: Function failed: fixup_perms
I can't tell you anything useful on this one. I am running Ubuntu 12.04, and the Python is 2.7.3.
Import grp works just fine on this one. This link is useful to describe grp:
With any reasonable make based build process, I would say fix your error (add grp) and continue where you left off.
Yocto seems to have it's own rules though, and I have never been able to restart a build. So start those 3000 steps over...
Make sure that you try Python from the command line when you get it sorted out, and verify "import grp" succeeds.
Thanks for the suggestions. I ended up switching back to the EPEL version of Python (2.6.8), which 'import grp' worked on and I began running bitbake where I left off. A bit crude, I know (as I'm pretty sure bitbake failed to start the first time I ran with the EPEL version of Python), but it began compiling again until I hit the next error.
Seems that the grub-efi package is not happy now, I've never seen a 'gcc failed to produce assembly code' error:
checking for command to convert module to ELF format...
checking whether `gcc' generates calls to `__enable_execute_stack()'... no
checking whether `gcc' has `-fPIE' as default... no
checking whether `gcc' has `-fPIC' as default... no
checking whether `gcc' accepts `-fstack-protector'... yes
checking whether `gcc' accepts `-mstack-arg-probe'... yes
checking if C symbols get an underscore after compilation... configure: error: gcc failed to produce assembly code
Configure failed. The contents of all config.log files follows to aid debugging
ERROR: oe_runconf failed
ERROR: Function failed: do_configure (see /home/mjstanis/meta-clanton_v0.7.5/yocto_build/tmp/work/x86_64-linux/grub-efi-i586-native/2.00-r2/temp/log.do_configure.22625 for further information)
Thoughts? I'm almost there :-)