We've started to order things!


@zmatt I stumbled on a TI product support for another TI ARM SoC regarding the intricacies of configuration of 4GB RAM. I'm not sure if it would be any help though as it references an AM5728 instead of the OMAP5432. Both use dual A15 cores and 2-4 M4 cores, so maybe?

https://e2e.ti.com/support/arm/sitara_arm/f/791/p/464238/1670266

On the off chance that TI reuses anything from one ARM CPU to another, it might be worth a look? If not, I apologize in advance for taking your time on a wandering path.
[doublepost=1487901643,1487883341][/doublepost]
Grench said:
I've been trying to Debian Stretch command line only on a server and it's driving me nuts. The install works fine but GRUB won't boot from the hardware RAID unless I include the desktop environment for which Stretch overrides and installs XFCE (and components) even if deselected. Gotta love Debian testing releases. I'll have to drop back to Jessie for now I guess. Yes - topic strayed.
Click to expand...

Continuing my own off topic here a bit because I'm freekin' thrilled with my admittedly weak GNU/Linux hacking skills. It took me tens of hours, two server chassis & motherboard combinations, etc to figure this out. Many of you would have figured it out in minutes.

I fiddled with it some more. It seems that the Debian Stretch installer sees the USB stick as sda during the install. All partitioning menus then show the HDD (12TB hardware RAID 50 spanning eight 2TB drives in my case) as sdb. The grub installer then writes to grub to boot from sdb, in my case it listed sdb2 in the grub script. And that is where it gets weird. From intramfs I was able to see the partitions on the array, and it listed them all as sda1 through sda4. I edited the grub script and changed the boot partition from sdb2 (written by the Stretch installer) to sda2 and Bob's now my uncle.

Now if there were a way to report Debian Stretch (Testing RC2) bugs without disclosing my email address to the world wide spam distributors, I would submit this one.

Off topic topic [SOLVED].
 
I'm running off internal eMMC and SD card on this netbook at present, and I had a similar problem with sda and sdb swapping round depending on whether I booted from eMMC or from boot CD. This was under ArchLinux though, so modifying my fstab myself was part of the standard install process, and using mount-by-label instead of by-block-device solved any trouble I was having.

It does mean if I plug in a usb device with a partition named like my internal ones my system could fail to boot, or be compromised in a number of interesting ways, so I guess I should probably switch over to boot-by-uuid now I've got it all working to avoid that possibility, but I don't generally use this machine anywhere it could be tampered with so I'll take my time with that.
 
@Grench,levi:
The kernel enumerates devices in whatever order they come online. So if a USB stick is faster to respond that a disk array, then the USB stick will be listed as sda and the RAID as sdb.
This is not a bug and it is the reason why you should always use UUIDs to adress devices, because these are usually unique.

The only thing that is stange here is, that you say, that GRUB adressed the RAID by its block device name. This should not happen. By default, it should be adressed by UUID as well.

As for bug report emails, I suggest to set up a spam mail address somewhere, that allows you to automaltically forward emails to another address based on filters. Then from this account forward only these mails to your real account that are sent to the bug tracker.
This way you'll receive answers to your bug reports but only have to deal with the spam-flooded account when you want to write to the bug tracker.
 
That is excellent news! It's like a big check mark in one of the remaining outstanding items to be solved. Great work!

Edit: I wish this board had a Gnu/Linux (All other systems) for general Gnu/Linux discussions. It doesn't feel 'Offtopic' or chatty, but it probably doesn't belong in Pyra or Pandora specific areas.
 
Last edited:
Oh man, this is all getting so close to release now. And to think there's just a single "final" development prototype in the wilds, and 4GB RAM is already working - what will happen if all of them get spread around the world!?

Also, I fully agree with Grench on zmatt reporting about development. I don't understand much of it, but it's very fascinating what goes into such seemingly simple tasks no one (or at least me) never seems to think about too closely. And just researching what the hell you could mean and trying to learn about it can be seriously helpful.

Edit: But of course I would fully understand if explaining stuff to plebs like me is not worth your time, zmatt. Not everyone can handle 3 jobs and still have the time to write on a forum like ED...
 
Last edited:
tmlind said:
OK so it should be close to working then :)
Click to expand...
[ 0.000000] Memory: 4099344K/4174848K available (6144K kernel code, 651K rwdata, 2328K rodata, 2048K init, 8145K bss, 59120K reserved, 16384K cma-reserved, 3372032K highmem)

For testing I just passed mem=2032M@0x80000000 mem=2048M@0x200000000 as kernel args, I still need to dig a bit to see where u-boot normally writes this stuff into the DT.

Note that the second 4GB of memory technically resides at 0x200000000, although using 0x300000000 like igep does works too since the excess row bit is ignored by the memory hence the two regions are aliases.

For the u-boot SPL debugging you need to be careful it still fits into SRAM for the size.
Click to expand...
It's only 65K for me right now (out of max 120K).

... lol, how did we get here? "only" 65K for the bootloader-loader ?

I've also uncovered the mystery of the stolen memory at 0xFF000000: it is intended to trap accesses to unmapped TILER/PAT memory. I'm wondering who makes use of that exactly since mainline linux just maps unused TILER pages all to the same valid page.

Even if we want to keep it, it wouldn't be hard to get that 16M back if we care: just program the trap section only into DMM (and not into LSM) and use mem=2032M@0x80000000 mem=2064M@0x2FF000000
 
Grench said:
https://e2e.ti.com/support/arm/sitara_arm/f/791/p/464238/1670266
Click to expand...

Neat. I work for TI as a web developer and I was assigned to the E2E website at the beginning of this month. I didn't write the site but I'll be maintaining it (and hopefully rewriting large portions of it).

It does seem like the site may be an invaluable resource when troubleshooting hardware issues. I know we (TI) are committed to ensuring every person who needs help gets a prompt response from an engineer.

Disclaimer: I am not here in an official capacity and know very little about hardware engineering.
 
WOOOO! 4GB LETS PARTY
community_image_1383546237.gif
 
this is great news that the 4gb ram is working. you guys keep amazing us here
 
mecksg1 said:
this is great news that the 4gb ram is working. you guys keep amazing us here
Click to expand...
Not only you. It is amazing us as well.

zmatt has patched a single bit in U-Boot while working on 4GB RAM and that one surprisingly appears to make my 2GB Pyra prototype run at full load @1.5Ghz until it runs into thermal shutdown after ca. 5 minutes.

It is too early to say this issue is solved as well, but likelihood that it is solved by the combination of new CPU board layout and this patch is extremely close to 100%.
 
hns said:
Not only you. It is amazing us as well.

zmatt has patched a single bit in U-Boot while working on 4GB RAM and that one surprisingly appears to make my 2GB Pyra prototype run at full load @1.5Ghz until it runs into thermal shutdown after ca. 5 minutes
Click to expand...

Is the software currently using any of the CPU sleep modes, or is this just running full pelt at 1.5GHz, fully wakened - or were you running some test app to keep the CPU speed at or close to max most of the time?

Also, I wasn't aware of a CPU board change that would extend the thermal envelope of the chip very much. The last one I was aware of was the one to add the extra vias to reduce capacitance in the power lines, which was causing the CPU to crash clocked too fast. If this is running on the old board with the reduced vias, 5 minutes is especially impressive!
 
levi said:
Is the software currently using any of the CPU sleep modes, or is this just running full pelt at 1.5GHz, fully wakened - or were you running some test app to keep the CPU speed at or close to max most of the time?

Also, I wasn't aware of a CPU board change that would extend the thermal envelope of the chip very much. The last one I was aware of was the one to add the extra vias to reduce capacitance in the power lines, which was causing the CPU to crash clocked too fast. If this is running on the old board with the reduced vias, 5 minutes is especially impressive!
Click to expand...

I have the on-demand govenor running, and OPP from 250MHz up to 1.5GHz in 250MHz steps. And DSS, X11 and panel+backlight are also running.

Then we run a tool that uses assembler code to fully stress the NEON processor. This task is run in two background processes at 100% each. A third process is monitoring current clock rate and temperatures inside the OMAP5.

The log clearly shows that the CPU starts with 1500MHz and when the temperature gets above 100°C, the kernel tries to throttle by reducing the clock for 1-2 seconds. Then it heats up again. This starts after ca. 20-30 seconds. Extra cooling might extend this time. The new boards and special measures for mounting and heat spreading might do that.

So it is not 5 minutes until the kernel is starting clock rate limiting. It was 5 minutes test time and when clock rate limiting was no longer successful in limiting below 125°C, there was a shutdown. This might be because the environment of the OMAP5 is heating up over time and the 1-2 seconds cool-down phase might become too short to avoid shooting over 125°C as temperature peak (details need more experimentation and logging). This triggers some interrupt and Linux does a quick shutdown (maybe this can be configured to kill or freeze high-load processes instead).

And: I just tested with 1.7GHz and except that it heats up even faster, there is no freeze. Before this new setup, a freeze occurred after 1-2 seconds - if the board did boot at all:

root@letux:~# ./high-load -n
100% load stress test for 2 cores
Sat Jan 1 06:07:22 UTC 2000 44° 45° 44° 29° 4036mV 1000MHz
Sat Jan 1 06:07:22 UTC 2000 44° 45° 44° 29° 3992mV 1000MHz
Sat Jan 1 06:07:23 UTC 2000 44° 45° 45° 29° 3870mV 1700MHz
Sat Jan 1 06:07:25 UTC 2000 47° 45° 45° 29° 3859mV 1700MHz
Sat Jan 1 06:07:26 UTC 2000 67° 52° 53° 29° 3862mV 1700MHz
Sat Jan 1 06:07:27 UTC 2000 75° 58° 59° 31° 3857mV 1700MHz
Sat Jan 1 06:07:29 UTC 2000 79° 65° 63° 31° 3827mV 1700MHz
Sat Jan 1 06:07:30 UTC 2000 85° 68° 68° 31° 3843mV 1700MHz
Sat Jan 1 06:07:32 UTC 2000 87° 72° 71° 31° 3840mV 1700MHz
Sat Jan 1 06:07:33 UTC 2000 90° 74° 75° 32° 3830mV 1700MHz
Sat Jan 1 06:07:35 UTC 2000 90° 74° 75° 32° 3818mV 1700MHz
Sat Jan 1 06:07:36 UTC 2000 93° 79° 76° 32° 3808mV 1700MHz
Sat Jan 1 06:07:38 UTC 2000 95° 81° 78° 32° 3799mV 1700MHz
Sat Jan 1 06:07:39 UTC 2000 98° 83° 80° 33° 3811mV 1700MHz
Sat Jan 1 06:07:41 UTC 2000 100° 84° 83° 33° 3974mV 1000MHz
Sat Jan 1 06:07:42 UTC 2000 103° 86° 84° 33° 4034mV 250MHz
Sat Jan 1 06:07:45 UTC 2000 81° 82° 77° 31° 3826mV 1700MHz
Sat Jan 1 06:07:46 UTC 2000 73° 74° 72° 31° 3805mV 1700MHz
^Ckill 2659 2660

root@letux:~#
 
I would be happy whit decend, Dreamcast and DS Emulation, and maybe some proper PC Ports as Doom3 and Morrowind..
But it's pretty good news to hear that 1,5 ghz and 4gb now are working..

I ditnt want PS2 Emulation, because the Games are pretty big, as they came on DVD, maybe i can get a second big SDHC Card to fit my favorite PS2 Games,
But I would rather play older Games on Pyra as they need less Batterie Power
 
You must log in or register to reply here.

Similar threads

EvilDragon
4GB and 1,5GHz? Confirmed.
4 5 6
Replies
100
Views
58K
Jan-Nik
Jan-Nik
EvilDragon
Surprise Attack!
5 6 7
Replies
125
Views
49K
jonlad1
J
EvilDragon
Stop the sirring noise!
6 7 8
Replies
141
Views
73K
Grench
Grench
EvilDragon
Travelling to Vienna
2 3
Replies
58
Views
21K
rygD
rygD
EvilDragon
A final Pyra Newspost!
2 3 4
Replies
62
Views
28K
CFWhitman
C
Back
Top