Hi,
as ED is going distribute current prototypes to general public, it would be great if they would be detectable in software to distinguish them from potentially fixed future boards. Probably best if it can be detected by u-boot, so that it can select a DT file with appropriate CPU frequencies, as it sounds like the current prototypes should be fully functional otherwise. It makes no sense to throw those boards away or "deprecate" them, I think the default OS should be able to support them indefinitely.
Gražvydas
Hi Notaz,
Am 05.12.2016 um 19:11 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
as ED is going distribute current prototypes to general public, it would be great if they would be detectable in software to distinguish them from potentially fixed future boards. Probably best if it can be detected by u-boot, so that it can select a DT file with appropriate CPU frequencies, as it sounds like the current prototypes should be fully functional otherwise. It makes no sense to throw those boards away or "deprecate" them, I think the default OS should be able to support them indefinitely.
Yes, that is the plan. Like we auto-detect the 600MHz/1GHz pandoras.
It is just not implemented anywhere... Another open item, not closed because it wasn't essential for me yet.
I currently use different SD cards and either cp the correct DT file or modify uEnv.txt.
The revision detection is done by two GPIOs. They are either floating, pulled up or pulled down by an external 10k resistor. This can be detected by modifying the OMAP PU/PD and check if it is floating or stuck at 0 or 1. Gives 3 values per gpio. So we can detect 9 combinations.
The GPIOs are gpio2_32 and gpio2_33.
There is a table on sheet 28/51 - but it is wrong. So there will be a new version of the PD soon.
It should be
CPU board Revisions (there were no revisions before 4.9): 4.9: no resistors - summer 2015 5.0: GPIO2_32=PU - dec 2015 5.1: GPIO2_32=PD - sept 2016 5.2: GPIO2_33=PU - mass production 5.3: GPIO2=33=PD 5.4: GPIO2_32+33=PU 5.5: GPIO2_32+33=PD 5.6: GPIO2_32+33=PU+PD 5.7: GPIO2_32+33=PD+PU
Unfortunately there is no generic revision handling method in U-Boot so that we just have to write a gpio driver... Everyone has his own way of getting different device trees loaded. Either by setting some environment variables, by adding a default script compiled into U-Boot, or by adding a boot.scr. All this is quite fragile.
What makes the Pyra even more complex is that we might end up in different revisions for the mainboard and CPU and having them mixed. But let's see if this really is a problem because the kernel can detect almost all chips on the mainboard.
So you could think about submitting a patch for our U-Boot:
http://git.goldelico.com/?p=gta04-uboot.git;a=tree;f=board/goldelico/letux-c...
BR, Nikolaus
Am 06.12.2016 um 10:51 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Notaz,
Am 05.12.2016 um 19:11 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
as ED is going distribute current prototypes to general public, it would be great if they would be detectable in software to distinguish them from potentially fixed future boards. Probably best if it can be detected by u-boot, so that it can select a DT file with appropriate CPU frequencies, as it sounds like the current prototypes should be fully functional otherwise. It makes no sense to throw those boards away or "deprecate" them, I think the default OS should be able to support them indefinitely.
Yes, that is the plan. Like we auto-detect the 600MHz/1GHz pandoras.
It is just not implemented anywhere... Another open item, not closed because it wasn't essential for me yet.
I currently use different SD cards and either cp the correct DT file or modify uEnv.txt.
The revision detection is done by two GPIOs. They are either floating, pulled up or pulled down by an external 10k resistor. This can be detected by modifying the OMAP PU/PD and check if it is floating or stuck at 0 or 1. Gives 3 values per gpio. So we can detect 9 combinations.
The GPIOs are gpio2_32 and gpio2_33.
There is a table on sheet 28/51 - but it is wrong. So there will be a new version of the PD soon.
s/PD/PDF/
It should be
CPU board Revisions (there were no revisions before 4.9): 4.9: no resistors - summer 2015 5.0: GPIO2_32=PU - dec 2015 5.1: GPIO2_32=PD - sept 2016 5.2: GPIO2_33=PU - mass production 5.3: GPIO2=33=PD 5.4: GPIO2_32+33=PU 5.5: GPIO2_32+33=PD 5.6: GPIO2_32+33=PU+PD 5.7: GPIO2_32+33=PD+PU
Unfortunately there is no generic revision handling method in U-Boot so that we just have to write a gpio driver... Everyone has his own way of getting different device trees loaded. Either by setting some environment variables, by adding a default script compiled into U-Boot, or by adding a boot.scr. All this is quite fragile.
What makes the Pyra even more complex is that we might end up in different revisions for the mainboard and CPU and having them mixed. But let's see if this really is a problem because the kernel can detect almost all chips on the mainboard.
So you could think about submitting a patch for our U-Boot:
http://git.goldelico.com/?p=gta04-uboot.git;a=tree;f=board/goldelico/letux-c...
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 06.12.2016 um 11:13 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 06.12.2016 um 10:51 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Notaz,
Am 05.12.2016 um 19:11 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
as ED is going distribute current prototypes to general public, it would be great if they would be detectable in software to distinguish them from potentially fixed future boards. Probably best if it can be detected by u-boot, so that it can select a DT file with appropriate CPU frequencies, as it sounds like the current prototypes should be fully functional otherwise. It makes no sense to throw those boards away or "deprecate" them, I think the default OS should be able to support them indefinitely.
Yes, that is the plan. Like we auto-detect the 600MHz/1GHz pandoras.
It is just not implemented anywhere... Another open item, not closed because it wasn't essential for me yet.
I currently use different SD cards and either cp the correct DT file or modify uEnv.txt.
The revision detection is done by two GPIOs. They are either floating, pulled up or pulled down by an external 10k resistor. This can be detected by modifying the OMAP PU/PD and check if it is floating or stuck at 0 or 1. Gives 3 values per gpio. So we can detect 9 combinations.
The GPIOs are gpio2_32 and gpio2_33.
There is a table on sheet 28/51 - but it is wrong. So there will be a new version of the PD soon.
s/PD/PDF/
It should be
CPU board Revisions (there were no revisions before 4.9): 4.9: no resistors - summer 2015 5.0: GPIO2_32=PU - dec 2015 5.1: GPIO2_32=PD - sept 2016 5.2: GPIO2_33=PU - mass production 5.3: GPIO2=33=PD 5.4: GPIO2_32+33=PU 5.5: GPIO2_32+33=PD 5.6: GPIO2_32+33=PU+PD 5.7: GPIO2_32+33=PD+PU
Unfortunately there is no generic revision handling method in U-Boot so that we just have to write a gpio driver... Everyone has his own way of getting different device trees loaded. Either by setting some environment variables, by adding a default script compiled into U-Boot, or by adding a boot.scr. All this is quite fragile.
What makes the Pyra even more complex is that we might end up in different revisions for the mainboard and CPU and having them mixed. But let's see if this really is a problem because the kernel can detect almost all chips on the mainboard.
So you could think about submitting a patch for our U-Boot:
http://git.goldelico.com/?p=gta04-uboot.git;a=tree;f=board/goldelico/letux-c...
I just looked into the code and it turns out that I have already implemented a while ago what you propose:
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=board/goldelico/letux-c...
Only translating into the proper DTB isn't implemented. And, detecting major mainboard variants is missing in
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=board/pandora/pyra%2Blc...
Nothing difficult.
BR, Nikolaus
Hi,
I just looked into the code and it turns out that I have already implemented a while ago what you propose:
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=board/goldelico/letux-c...
Only translating into the proper DTB isn't implemented. And, detecting major mainboard variants is missing in
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=board/pandora/pyra%2Blc...
Nothing difficult.
I have now finished it and fixed some minor bugs in the code so that U-Boot 2016.11 can be used:
Here is what the automatic can do (the detected DTB is still overwritten in uEnv.txt):
Found LC15 V5.1 Found Pyra MB V5.0 Device Tree: letux-cortex-15-v5.1+pyra-v5.0.dtb
Fortunately, you made me really implement and test this now and not in some weeks.
Because it brought another hidden hardware issue to the surface.
The problem is that the OMAP5 has stronger pull-up/down than I was used to from OMAP3 and I didn't read the data sheet fully. It says in a footnote that the typical PU/PD current is 100µA.
But using a 10k resistor for version encoding pullup/down (which is good for OMAP3) makes a voltage of 1V which means that having a PU programmed by OMAP5 and PD by resistor installed in factory is still read as "1" and not "0" as an external PD should indicate.
This means we have to use an 1k to be on the safe side (and kernel should turn off the PU/PD to save several 100 µA).
After fixing this in 3 CPU and 2 Mainboards I got some combinations working (e.g. 5.0 + 5.1, 5.1 + 5.0, 5.1 + 5.1).
Latest U-Boot code is here:
http://git.goldelico.com/?p=gta04-uboot.git;a=shortlog;h=refs/heads/letux-20...
If you run it on your board there might be false reports unless you fix the resistors. So please keep the uEnv.txt...
So thanks and BR, Nikolaus
On Tue, Dec 06, 2016 at 10:51:10AM +0100, H. Nikolaus Schaller wrote:
Yes, that is the plan. Like we auto-detect the 600MHz/1GHz pandoras.
It is just not implemented anywhere... Another open item, not closed because it wasn't essential for me yet.
For now, as there's not much hardware samples, could we resort to such boring non-scalable way as writing revision name on hardware itself with some kind of permanent marker or sticker?
However, I suppose something like this is already in use.
Hi,
Am 06.12.2016 um 20:24 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Tue, Dec 06, 2016 at 10:51:10AM +0100, H. Nikolaus Schaller wrote:
Yes, that is the plan. Like we auto-detect the 600MHz/1GHz pandoras.
It is just not implemented anywhere... Another open item, not closed because it wasn't essential for me yet.
For now, as there's not much hardware samples, could we resort to such boring non-scalable way as writing revision name on hardware itself with some kind of permanent marker or sticker?
However, I suppose something like this is already in use.
Yes, it is embossed in the silk screen of the PCB which means that you can read "V5.0" or "V5.1.2" in golden letters on green background.
But there is no camera to read this and decide which device tree to load during boot :)
Just kidding...
It is of course easier to have auto-detection and manage a single SD card image that fits every variant than telling users to choose amongst multiple variants.
BR, Nikolaus
On 06/12/16 11:51, H. Nikolaus Schaller wrote:
What makes the Pyra even more complex is that we might end up in different revisions for the mainboard and CPU and having them mixed. But let's see if this really is a problem because the kernel can detect almost all chips on the mainboard.
A tiny i2c eeprom on every board would be perfect. Of course, then you'll struggle with the fact that the production will forget to flash it...
Tomi
Am 07.12.2016 um 09:29 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 06/12/16 11:51, H. Nikolaus Schaller wrote:
What makes the Pyra even more complex is that we might end up in different revisions for the mainboard and CPU and having them mixed. But let's see if this really is a problem because the kernel can detect almost all chips on the mainboard.
A tiny i2c eeprom on every board would be perfect. Of course, then you'll struggle with the fact that the production will forget to flash it...
It is more cost effective to program their Pick&Place machine once than every eeprom :)
BR, Nikolaus
On 07/12/16 12:33, H. Nikolaus Schaller wrote:
Am 07.12.2016 um 09:29 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 06/12/16 11:51, H. Nikolaus Schaller wrote:
What makes the Pyra even more complex is that we might end up in different revisions for the mainboard and CPU and having them mixed. But let's see if this really is a problem because the kernel can detect almost all chips on the mainboard.
A tiny i2c eeprom on every board would be perfect. Of course, then you'll struggle with the fact that the production will forget to flash it...
It is more cost effective to program their Pick&Place machine once than every eeprom :)
If you have pins to spare for that kind of gpio-board-detection use, you're not fully utilizing the SoC! ;)
Tomi
-
Andrey Utkin -
Grazvydas Ignotas -
H. Nikolaus Schaller -
Tomi Valkeinen