OMAP5432 at home !


Yup, I have SD then eMMC as boot order.

I wonder if I have to create a uEnv.txt, because the rootfs device is not the same.
 
I used the script instead of doing it manually, and it booted the kernel.

But the boot hangs after USB detection, whichever the distro used :

Code: 
[    3.486328] smsc75xx 1-2.3:1.0 eth0: register 'smsc75xx' at uSB 2.0 Gigabit Ethernet,
...long time...
[   62.755706]  remoteproc0: failed to load tesla-dsp.xe64T
[   62.761474]  remoteproc1: failed to load ducati-m3-core0.xem3
...seems to have stopped...
 
Bought a mSATA 840 EVO 250G :

# dd bs=1M count=4096 if=/dev/zero of=test.dd conv=fdatasync
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 24.634 s, 175 MB/s

For the integrated eMMC :

# dd bs=1M count=256 if=/dev/zero of=test.dd conv=fdatasync
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 12.7446 s, 21.1 MB/s

On the micro-SD card (SanDisk Extreme PLUS 16G SDSDQX-016G-U46A 80MB/s) :

# dd bs=1M count=256 if=/dev/zero of=test.dd conv=fdatasync
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 82.8769 s, 3.2 MB/s
 
 
Last edited by a moderator:
Boards

IGEP TM v5 4G RAM uses two modules composed by 4 units of 4Gbits density (32Mwords, 16bits and 8 banks) of
DDR3 SDRAM Memories making possible the assembly of a total memory of 4096MB.

4096 MB DDR3 SDRAM 1066MHz (8x4Gb; 256Mwords x 16bits)

IGEP TM v5 Lite 1G RAM uses one bank with 2 units of 4Gbits density (32Mwords, 16bits and 8 banks) of DDR3 SDRAM
Memories with a total memory of 1024MB.
1024 MB DDR3 SDRAM 1066MHz (2x4Gb; 256Mwords x 16bits)

My actual setup :

mem=1008M@0x80000000

If I understood well, I have to add three more "mem=" parameters.
 
Last edited by a moderator:
You put the SSD on it?  So now this means you can run swap and do massive builds.  I'm very keen on knowing if you're doing that, how that works out for you...

EDIT: BTW, can you guys tell me which is the 'closest to Pyra' ARM devboard to get?  I need a small/light ARM machine for another project, and if the one that you guys are using as a "Pyra testbench" is suitable, I'll nip two buds with one swipe and get it.  The specs aren't super-important for my project - but Pyra compatability would mean it would be good for a bit of future work too ..
 
Last edited by a moderator:
Yup, a mSATA SSD.

The IGEPv5 Full edition has a mSATA port at the back.

I plugged the SSD, and it was recognized as /dev/sda.

The 'closest to Pyra' ARM devboard is the Ti one called EVM.
 
i've been building debian packages and kernels on my board with a sata hd (no ssd) connected since forever.

It obviously speeds up everything quite a bit. Swap isn't really needed for most things, when there's 2gb of ram available.

Don't expect any miracles though, it still takes 15-20 minutes to compile a kernel

the TI omap5432 evm is closest. It's what Nikolaus is using as a devboard, so all the current pyra test boards are set up to connect to that.

It's also what i'm using for the OS.

http://www.ti.com/tool/omap5432-evm

Basically any arm board can be used as a devboard at this stage, as long as it's capable of running debian jessie armhf , and a kernel that has aufs support.

Even a pandora will do fine for that, although it won't run things at quite the same speed of course.

The igep0050 would be fine too, since that's the same soc, but unfortunately they only support the 3.8 kernel, so you won't be able to run the current pyra kernel on that (the dts stuff mentioned before).

Which isn't that much of a problem, although since all my stuff is set up for the 5432evm, some extra configuring might be needed to run/boot the pyra image. (different kernel/u-boot, etc)

The 5432evm does also have the advantage that that'll be used to get the 3d hardware working (if it's even possible :) . The current drivers for the 5432 only work with the 3.8 kernel, and an ancient ubuntu version with modifications done to xorg. (and even there it hardly worked)
 
Thanks for the details aTc, I'll go shopping for that TI board then .. 
 
EvilDragon said:
Nikolaus is just his internal testing, the one from me is an outdated aTc one (as we need to find a way to make the buildserver reliable), so aTcs one is the recommended one.
Click to expand...
Well, it is not only for "internal testing", but "external" for Goldelico users and is a continued effort. GDC simply runs a multi-architecture GNU/Linux distribution project where SD card images can run (almost binary compatible as long as technically feasible) on the GTA04, the Letux variants, the BeagleBoard, BeagleBone, OMAP5432EVM, OpenPandora, Neo900, Pyra, and more to come.It combines a patched upstream kernel with some Debian LXDE/XFCE4, or Android/Relicant, or QtMoko or QuantumSTEP as handheld device "Desktops" or "Palmtops".

This all will be extended in the next months (maybe with a rename to remove the thigh connection with the "GTA04" device the current project name seems to imply).

Therefore it is not (and does not try to be) "the" Pyra OS. It is just one option that can also be installed. It is optimized for multi-platform support. With that it helps us during development of the Pyra hardware for two things:

* hardware bring-up needs an OS that we can easily modify and extend to support new chips and test situations, but is also mature enough so that we don't have to fix bugs in other areas than the hardware-kernel interface

* upstreaming of kernel patches (since the kernel is also multi-platform) - to test them you also need some OS to do tests

ED has an almost orthogonal goal: make "the best" OS for the Pyra. Therefore he provides an optimized image for the Pyra, optimized for gaming, emulators, speed, etc. But it runs only on the Pyra and no other device.

So the gta04-rootfs, gta04-makesd, gta04-kernel projects etc. do not intend to replace the Pyra OS or even compete. It is just something that can be the better choice for some users and is for us during the current project phase.

And, this multitude of choices allows to run different binaries on the device and this sometimes reveals issues we would to have seen.
 
Last edited by a moderator:
aTc said:
login/password is root/root

The normal users are set up in the first-run-wizard

I don't remember wally having these issues with his board.

The most weirdness he had was caused by him not extracting the rootfs to the sd card as root.

Are you sure you're using, and booting, the right kernel and modules ?

you could retry reinstalling the complete rootfs, with all the modules and firmware, maybe something went wrong during the setup stage on the very first boot.
Click to expand...
The pyra/pyra login/password didn't work.

I had to remove the card after the second "boot", and enable root login in ssh.

Anyway X was up and I was able to run the Pyra wizard.

Nice to have a Pyra preview ;^).
 
hns said:
EvilDragon said:
Nikolaus is just his internal testing, the one from me is an outdated aTc one (as we need to find a way to make the buildserver reliable), so aTcs one is the recommended one.
Click to expand...
Well, it is not only for "internal testing", but "external" for Goldelico users and is a continued effort. GDC simply runs a multi-architecture GNU/Linux distribution project where SD card images can run (almost binary compatible as long as technically feasible) on the GTA04, the Letux variants, the BeagleBoard, BeagleBone, OMAP5432EVM, OpenPandora, Neo900, Pyra, and more to come.
Click to expand...
Thanks for clarifying :)

I didn't know your rootfs actually was that OS - as the last I tried from you needed a lot of config changes to even let a normal user run X, so I thought it was just for testing :)
 
hns said:
EvilDragon said:
Nikolaus is just his internal testing, the one from me is an outdated aTc one (as we need to find a way to make the buildserver reliable), so aTcs one is the recommended one.
Click to expand...
Well, it is not only for "internal testing", but "external" for Goldelico users and is a continued effort. GDC simply runs a multi-architecture GNU/Linux distribution project where SD card images can run (almost binary compatible as long as technically feasible) on the GTA04, the Letux variants, the BeagleBoard, BeagleBone, OMAP5432EVM, OpenPandora, Neo900, Pyra, and more to come.
It combines a patched upstream kernel with some Debian LXDE/XFCE4, or Android/Relicant, or QtMoko or QuantumSTEP as handheld device "Desktops" or "Palmtops".


This all will be extended in the next months (maybe with a rename to remove the thigh connection with the "GTA04" device the current project name seems to imply).


Therefore it is not (and does not try to be) "the" Pyra OS. It is just one option that can also be installed. It is optimized for multi-platform support. With that it helps us during development of the Pyra hardware for two things:


* hardware bring-up needs an OS that we can easily modify and extend to support new chips and test situations, but is also mature enough so that we don't have to fix bugs in other areas than the hardware-kernel interface


* upstreaming of kernel patches (since the kernel is also multi-platform) - to test them you also need some OS to do tests


ED has an almost orthogonal goal: make "the best" OS for the Pyra. Therefore he provides an optimized image for the Pyra, optimized for gaming, emulators, speed, etc. But it runs only on the Pyra and no other device.


So the gta04-rootfs, gta04-makesd, gta04-kernel projects etc. do not intend to replace the Pyra OS or even compete. It is just something that can be the better choice for some users and is for us during the current project phase.


And, this multitude of choices allows to run different binaries on the device and this sometimes reveals issues we would to have seen.
Click to expand...
Now I am interested.  I guess I will be looking into this a lot more.
 
EvilDragon said:
hns said:
EvilDragon said:
Nikolaus is just his internal testing, the one from me is an outdated aTc one (as we need to find a way to make the buildserver reliable), so aTcs one is the recommended one.
Click to expand...
Well, it is not only for "internal testing", but "external" for Goldelico users and is a continued effort. GDC simply runs a multi-architecture GNU/Linux distribution project where SD card images can run (almost binary compatible as long as technically feasible) on the GTA04, the Letux variants, the BeagleBoard, BeagleBone, OMAP5432EVM, OpenPandora, Neo900, Pyra, and more to come.
Click to expand...
Thanks for clarifying :)

I didn't know your rootfs actually was that OS - as the last I tried from you needed a lot of config changes to even let a normal user run X, so I thought it was just for testing :)
Click to expand...
No OS is free of bugs. Unfortunately, they are not fixed without efforts :)
 
I now have 4G ram.

I thought only a custom u-boot.img was needed, but in fact the newly compiled MLO was needed too !
 
root@darkstar:~# free
                               total            used         free           shared    buffers     cached
Mem:                      4134740     222660    3912080    0             25824      161520
-/+ buffers/cache:   35316         4099424
Swap:                     0                 0              0

 
 
I managed to run a few ARM distros and integrated them into the build script. Some of them need aTc's systemd-enabled kernel :

Pyra-OS

Debian

Slackware-14.1 : mini and full image
Slackware-current : mini and full image

Slackware-armhf : old unsupported build
Gentoo : stage 3 archive
Archlinux
Opensuse : quite nice
Kali : not working
Fedora-mini
Fedora-xfce : graphically slow
 
You must log in or register to reply here.

Similar threads

Peamur
Interessante Information über WIZ
Replies
4
Views
2K
sbock
sbock
Back
Top