Hello,
On the armStoneA8 board, using NBoot V14 and U-Boot, I'm trying to boot
the downstream 3.3.7 kernel (BSP V1.1) from SD with a LimeJeOS rootfs on
SD. I had to reconfigure the kernel with CONFIG_LBDAF to mount the
ext3[*] rootfs r/w. This is what I get now:
[...]
mmc0: new high speed SDHC card at address b368
IPv6 over IPv4 tunneling driver
mmcblk0: mmc0:b368 NCard 7.48 GiB
NET: Registered protocol family 17
can: controller area network core (rev 20090105 abi 8)
mmcblk0: p1
NET: Registered protocol family 29
can: raw protocol (rev 20090105)
can: broadcast manager protocol (rev 20090105 t)
Registering the dns_resolver key type
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 2
s3c-rtc s3c64xx-rtc: setting system clock to 2000-01-01 00:00:00 UTC
(946684800)
kjournald starting. Commit interval 5 seconds
EXT3-fs (mmcblk0p1): using internal journal
EXT3-fs (mmcblk0p1): recovery complete
EXT3-fs (mmcblk0p1): mounted filesystem with ordered data mode
VFS: Mounted root (ext3 filesystem) on device 179:1.
Freeing init memory: 148K
Failed to mount /dev: No such device
Our rootfs definitely contains /dev, so what is this complaining about?
Thanks,
Andreas
[*] U-Boot seemed to hang loading zImage from ext4.
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi Petr,
When running parted to create or modify an MBR label, it tries to be clever and throws a dummy x86 boot sector onto the MBR, so the disk is bootable on PCs.
While that's nice and helpful for a bunch of use cases, it doesn't exactly help when running on ARM. Some ARM devices, such as the OMAP3 series, have a buggy boot rom that simply goes into nirvana if it finds non-0 in the first 4 bytes of the SD card.
Please see libparted/labels/dos.c:1271 for the place that copies a generic x86 asm MBR into the MBR when its first byte is 0.
We need to have the first byte be 0 though. Otherwise later on the whole machine won't be bootable anymore :). Any idea how to resolve this? The easy fix I could imagine would be to just not do the fixup on ARM, but that sounds slightly hackish :(.
Alex
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi Michal,
Currently compiling openjdk on ARM fails for us with what looks like a generic zero engine issue. Do you have any idea what could be causing this? Did someone change internal interfaces and not update the zero vm?
g++ -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO -DTARGET_ARCH_NYI_6939861=1 -DARM -DZERO_LIBARCH=\"arm\" -DPRODUCT -I. -I/home/abuild/rpmbuild/BUILD/java-1_7_0-openjdk/openjdk/hotspot/src/share/vm/prims -I/home/abuild/rpmbuild/BUILD/java-1_7_0-openjdk/openjdk/hotspot/src/share/vm -I/home/abuild/rpmbuild/BUILD/java-1_7_0-openjdk/openjdk/hotspot/src/share/vm/precompiled -I/home/abuild/rpmbuild/BUILD/java-1_7_0-openjdk/openjdk/hotspot/src/cpu/zero/vm -I/home/abuild/rpmbuild/BUILD/java-1_7_0-openjdk/openjdk/hotspot/src/os_cpu/linux_zero/vm -I/home/abuild/rpmbuild/BUILD/java-1_7_0-openjdk/openjdk/hotspot/src/os/linux/vm -I/home/abuild/rpmbuild/BUILD/java-1_7_0-openjdk/openjdk/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.0-b21\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"abuild\"" -DHOTSPOT_LIB_ARCH=\"arm\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_zero -DTARGET_ARCH_MODEL_zero -DTARGET_OS_ARCH_linux_zero -DTARGET_OS_ARCH_MODEL_linux_zero -DTARGET_COMPILER_gcc -fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -D_LITTLE_ENDIAN -pipe -g -O3 -fno-strict-aliasing -gstabs -DVM_LITTLE_ENDIAN -DINCLUDE_TRACE -Werror -Wpointer-arith -Wsign-compare -c -MMD -MP -MF ../generated/dependencies/cppInterpreter_zero.o.d -o cppInterpreter_zero.o /home/abuild/rpmbuild/BUILD/java-1_7_0-openjdk/openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp
/home/abuild/rpmbuild/BUILD/java-1_7_0-openjdk/openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp: In static member function 'static void CppInterpreter::process_method_handle(oop, Thread*)':
/home/abuild/rpmbuild/BUILD/java-1_7_0-openjdk/openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:817:7: error: 'get_ek_bound_mh_info' is not a member of 'MethodHandles'
/home/abuild/rpmbuild/BUILD/java-1_7_0-openjdk/openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:965:7: error: 'get_ek_adapter_opt_swap_rot_info' is not a member of 'MethodHandles'
The full log is available here once it's finished rebuilding again:
https://build.opensuse.org/package/live_build_log?arch=armv7l&package=java-…
Alex--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hello all:
I have a couple of ARM systems here that have a four core chip by Marvell on a System On Module or SOM made by Cogent. This SOM is then socketed into a development motherboard that has four full size USB ports, two 1Gig-E network ports, two SATA ports, and a built-in serial-to-USB console. The SOM has 2GB of memory and the Marvell MV78460 chip has hardware floating point so the architecture shows up as armv7l or armv7hl or armv7hfp depending on what OS bits are loaded. I am supposed to be receiving a third system shortly for additional testing.
Right now I have Fedora-13 ARM distro bits installed on a partition on a 500GB SATA hard drive. I was able to do this with a tarball of the root filesystem provided by the Fedora project. Once I had that unpacked on the hard drive I was able to alter the u-boot environment to still use the kernel resident on the internal NAND flash but use the root filesystem on the SATA disk. Later for ease of testing new kernel images I altered the u-boot environment again to use a kernel downloaded via tftp. I had downloaded the complete group of rpms Fedora-13 for ARM so I could setup a yum repo to facilitate adding more packages to the systems as needed.
Unfortunately neither Marvell or Cogent are feeding any sort of platform support patches they have developed back to the standard kernel development process so I am limited to working with the source tree they have provided for right now. That is currently based around a 3.0.6 kernel tree.
What I am wondering is if the OpenSUSE-arm project has a similar root filesystem tarball available that I could use to boot strap one of these systems to the current OpenSuSE-arm bits if they are released at all. That way I could do some testing of that build on this platform.
--
Steven DuChene
Hi,
would it be possible to enable JeOS image creation for armv5 so that we can have a rootfs for armv5 targets?
I should receive my Raspberry Pi this week and I would like to test openSUSE armv5el on it.
Cheers,
Guillaume
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
Is there any reason to have all the lines commented in the config file 20-omapfb.conf for xorg-x11-drv-omapfb?
Guillaume
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi all,
I now have two working openSUSE ARM images. For the Pandaboard and the
Toshiba AC100.
I wonder if we have a location where these images can be put so people who
want to test or help out the openSUSE ARM project?
These images can be used for a local native (osc/kiwi) build.
Regards,
Joop.
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
I am back from Solutions Linux [0] in Paris where we hold a booth. We also had a demo of openSUSE running on ARM, on a Beagleboard xM.
Some pictures: http://guillaume.gardet.free.fr/openSUSE/SSL_2012/
It was very attractive to have a little ARM board on our booth, lots of people come to our booth.
The demo was quite simple, it was only a video playing (Big buck bunny [1]). We did not used the DSP accelerated codecs since it does not work yet with gstreamer but we used a software player based on libav and designed for omap devices (Beagleboards (xM) and pandaboards (ES)): omapfbplay.
The demo was running all the day without any problem.
omapfbplay is available on my personnal build service [2] and directly from my repo [3].
For the next booth, I hope to have a real little computer on my Beaglebord xM. (Xorg, firefox, ...)
If you have any question, please ask.
Cheers,
Guillaume
[0]: http://www.solutionslinux.fr/?lg=en
[1]: http://www.bigbuckbunny.org/
[2]: https://build.opensuse.org/package/show?package=omapfbplay&project=home%3AG…
[3]: http://download.opensuse.org/repositories/home:/Guillaume_G:/ARM/openSUSE_F…
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi andrew,
I saw you added support to Exynos in opensuse.
Could you please fill the following page with boards supported by your kernel config: http://en.opensuse.org/openSUSE:Supported_ARM_boards
You may also add support for "Flattened Device Tree based board for EXYNOS SoCs".
Cheers,
Guillaume
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Aloha Geekos,
Attached is a patch for all the current ARM configs rebasing them
against kernel 3.5.0-rc3. Before I send it to the kernel folks, please
could you review it to make sure I haven't completely screwed things
up?
Many thanks,
Andy
--
Andrew Wafaa
IRC: FunkyPenguin
GPG: 0x3A36312F
