We've started to order things!


@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:
OK so it should be close to working then :)
[ 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.
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
 

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
 
this is great news that the 4gb ram is working. you guys keep amazing us here
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%.
 
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

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!
 
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!

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
 
While it's good news on it's own, it bring back the sad truth that it simply won't be possible to 100% the CPU for an extended period of time. I know this handcrafted test to stress the CPU to the fullest extend, but for purposes like longer time 2 thread compiling or really well optimized software:
What is the clock speed where the OMAP5 doesn't reach critical temperatures at all? The planned cooling stuff will only postpone the emergency downclock, so I think it may be better to avoid that stage if possible. For demanding games you'd probably also rather want consistent performances instead of random drops.
 
@hns - What are you running for simulating stress? I've used the stress command with a varying number of CPU hogs enabled and don't get the high temperatures you seem to get on the EVM.

@elvissteinjr - We can't yet say how real life CPU load behaves, I'm not sure if they've even played with applying thermal pads/paste yet to help it dump the heat to the PCB.
 
@Trashy

hns says above:
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.

Sounds like something hand-cranked to me. Dunno if it's on a public repo or not.
 
Back
Top