[opensuse-arm] openSUSE Hackweek upcoming !
Hi, SUSE is doing another Hackweek shortly, and there is a website for it put online: https://hackweek.suse.com/ The Nuernberg SUSE employees will do a Hackweek October 7th - 11th, and we're looking for projects and interested people that want to join those projects. Community people are welcome. Anyone got ideas with ARMs ? :-) Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Le 20/09/2013 18:40, Dirk Müller a écrit :
Hi,
SUSE is doing another Hackweek shortly, and there is a website for it put online:
The Nuernberg SUSE employees will do a Hackweek October 7th - 11th, and we're looking for projects and interested people that want to join those projects. Community people are welcome.
Not sure about my availability, but I will try to help a bit. Should be reachable by IRC or at least by mail.
Anyone got ideas with ARMs ? :-)
Maybe we could add/take ideas to trello ARM board? Here are some random ideas. * Have our ARM images building fine! (Non-rootfs images build still broken. At least in my Factory:ARM branch.) * Continue works on Chromebook. * Have a proper image for Raspberry Pi : * need kiwi fix (only in git repo ATM) * having u-boot working on RPi (not sure what is the current status) * update images to use u-boot (once u-boot is ok on RPi) * Use only one partition when possible, see Marcus Bug: https://bugzilla.novell.com/show_bug.cgi?id=841469 * test beagle and panda with DTB and if it works properly, modify u-boot and images to use it. * Test all boards : * to update wiki: http://en.opensuse.org/openSUSE:Supported_ARM_boards * Use and improve the test script. I have a little script to test some things, available here: http://guillaume.gardet.free.fr/openSUSE/ARM_tests/arm_boards_tests_script-2... (I guess there will be a better place to store it if people use it and want to update it). Guillaume
Greetings, Dirk
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Guillaume, Am 23.09.2013 15:47, schrieb Guillaume Gardet:
* Have a proper image for Raspberry Pi : * need kiwi fix (only in git repo ATM) * having u-boot working on RPi (not sure what is the current status) * update images to use u-boot (once u-boot is ok on RPi)
Well, U-Boot has a problem (for me): It's drivers are often very "simple" compared to the linux drivers: * the mmc driver can not read all SSDs. My 16GB Class10 Transcend Cards can not be read by u-boot (they work fine with linux and with bootcode.bin) Other cards (new SanDisk UHS-1 micro-sdhc, and old / cheap no-name cards) work fine. * often, I get "illegal extent" when trying to load the kernel from ext4 after unclean shutdown. But a fsck etc. does not find any problem with the rootfs. The only way to correct this is to create a copy of the kernel and/or initrd, and then rename it to the original filename. => it is not really robust :-( The feature I wanted most from u-boot was the ability to read from ext3/4, read the zImage symlink and maybe having some kind of boot menu. However, I then realized that even though I can display a boot menu, I have no way of doing anything without a serial console, so it is not that much better. So since perl-bootloader/yast need to deal with FAT boot partitions anyway (for UEFI) we can probably just cheat somehow, pretend to be UEFI and just have the FAT partition mounted at /boot. (Hey, I even tried to use the linux kernel as boot loader with a kernel/initrd, "boot menu" script and then load the final kernel and kexec into it, but then kexec failed miserably on the pi m( ) What we could do is use the safe-mode feature to select two different kernels based on the safe-mode GPIO pin or such, but that's all in config.txt, no special magic needed. If you still want to try u-boot on raspi, get home:seife:ARM/u-boot-rpib It contains a patch that gets the original boot args from bootcode.bin env and passes them on to the booted linux kernel. Otherwise some important setup stuff (which seems hardcoded in bootcode.bin and is not in config.txt) will be missing and e.g. the SD card will not work. Best regards, seife -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Guys,
I am willing to test, if you need testers.
Chuck
On Mon, Sep 23, 2013 at 3:59 PM, Stefan Seyfried
Hi Guillaume,
Am 23.09.2013 15:47, schrieb Guillaume Gardet:
* Have a proper image for Raspberry Pi : * need kiwi fix (only in git repo ATM) * having u-boot working on RPi (not sure what is the current status) * update images to use u-boot (once u-boot is ok on RPi)
Well, U-Boot has a problem (for me): It's drivers are often very "simple" compared to the linux drivers:
* the mmc driver can not read all SSDs. My 16GB Class10 Transcend Cards can not be read by u-boot (they work fine with linux and with bootcode.bin) Other cards (new SanDisk UHS-1 micro-sdhc, and old / cheap no-name cards) work fine. * often, I get "illegal extent" when trying to load the kernel from ext4 after unclean shutdown. But a fsck etc. does not find any problem with the rootfs. The only way to correct this is to create a copy of the kernel and/or initrd, and then rename it to the original filename.
=> it is not really robust :-(
The feature I wanted most from u-boot was the ability to read from ext3/4, read the zImage symlink and maybe having some kind of boot menu. However, I then realized that even though I can display a boot menu, I have no way of doing anything without a serial console, so it is not that much better.
So since perl-bootloader/yast need to deal with FAT boot partitions anyway (for UEFI) we can probably just cheat somehow, pretend to be UEFI and just have the FAT partition mounted at /boot.
(Hey, I even tried to use the linux kernel as boot loader with a kernel/initrd, "boot menu" script and then load the final kernel and kexec into it, but then kexec failed miserably on the pi m( )
What we could do is use the safe-mode feature to select two different kernels based on the safe-mode GPIO pin or such, but that's all in config.txt, no special magic needed.
If you still want to try u-boot on raspi, get home:seife:ARM/u-boot-rpib It contains a patch that gets the original boot args from bootcode.bin env and passes them on to the booted linux kernel. Otherwise some important setup stuff (which seems hardcoded in bootcode.bin and is not in config.txt) will be missing and e.g. the SD card will not work.
Best regards,
seife -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- Terror PUP a.k.a Chuck "PUP" Payne (678) 636-9678 ----------------------------------------- Discover it! Enjoy it! Share it! openSUSE Linux. ----------------------------------------- openSUSE -- en.opensuse.org/User:Terrorpup openSUSE Ambassador/openSUSE Member Community Manager -- Southeast Linux Foundation (SELF) skype,twiiter,identica,friendfeed -- terrorpup freenode(irc) --terrorpup/lupinstein Register Linux Userid: 155363 Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. See you at Southeast Linux Fest, June 7-9, 2013 in Charlotte, NC. www.southeastlinuxfest.org -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, On Mon, 23 Sep 2013, Guillaume Gardet wrote:
Le 20/09/2013 18:40, Dirk Müller a écrit :
SUSE is doing another Hackweek shortly, and there is a website for it put online:
The Nuernberg SUSE employees will do a Hackweek October 7th - 11th, and we're looking for projects and interested people that want to join those projects. Community people are welcome.
Not sure about my availability, but I will try to help a bit. Should be reachable by IRC or at least by mail.
Anyone got ideas with ARMs ? :-)
[...] Here are some random ideas.
* Have our ARM images building fine! (Non-rootfs images build still broken. At least in my Factory:ARM branch.)
* Continue works on Chromebook. [...]
Xorg and powersaving on the Chromebook desperately need love. E.g. if the
screensaver kicks in, it becomes unusable (cf. my previous post). My
current workaround is to completely disable the screensaver. But even then
I experience occasional unwanted screen blanking for some reason.
If these problems can be resolved in 13.1, openSUSE on the Chromebook is
IMHO ready for production use. In case shooting for the moon is allowed:
Accelerated video using ChromeOS' libmali. Since laptops are prone to be
lost or stolen, an option for an encrypted separate home partition during
installation for SD cards > 8GB would be fine. Alternatively complete
encryption as an option.
I like my Chromebook. It is small, cheap, has no moving parts and
surprisingly good performance and battery life. In the meantime I tried
all kinds of arbitrary stuff on it, like capturing network packets using
Wireshark, connecting weird USB devices like an USB-to-serial adapter,
editing images using GIMP, building RPM packages, transcoding video
(slowly ;-), etc.pp. Everything worked as expected. Good support by
openSUSE would make it a decent companion, high Geek factor included.
Best regards,
--D.
--
Daniel Bischof
participants (5)
-
Chuck Payne -
Daniel Bischof -
Dirk Müller -
Guillaume Gardet -
Stefan Seyfried