Hi,
as we need to have an easy and fast way to test the Pyra boards for defects, I'd like to start working on a Test- and OS-Flasher-Card that will also be used by GC to preinstall and test the units on mass production.
Similar to the one on the Pandora: https://cloud.openpandora.org/index.php/s/HiXoyEsaXryhx20
Basically, it boots up a minimal kernel and filesystem (takes 2 seconds) and then starts the initialize.sh-Script.
This is something I could work on with a little help.
Nikolaus already has a collection of scripts for testing and notaz already adopted the input tester.
I can work on the test and scripts file, but I need someone who can create the basic filesystem for booting and testing.
Who can help me there? :)
Am 18.03.2017 um 09:15 schrieb Michael Mrozek shop@dragonbox.de:
Hi,
as we need to have an easy and fast way to test the Pyra boards for defects, I'd like to start working on a Test- and OS-Flasher-Card that will also be used by GC to preinstall and test the units on mass production.
Similar to the one on the Pandora: https://cloud.openpandora.org/index.php/s/HiXoyEsaXryhx20
Basically, it boots up a minimal kernel and filesystem (takes 2 seconds) and then starts the initialize.sh-Script.
This is something I could work on with a little help.
Nikolaus already has a collection of scripts for testing and notaz already adopted the input tester.
Yes, especially the hw-test tool:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/hw-test;h=0...
I use this for the GTA04 to create test reports like this:
http://www.gta04.org/serial.php?serial=5285-0050
But it is not as fully automatic as it should be to hand over to the production facility.
I can work on the test and scripts file, but I need someone who can create the basic filesystem for booting and testing.
Who can help me there? :)
You could try:
http://download.goldelico.com/letux-debian-rootfs/latest-minimal.tbz
and mix with latest u-boot, kernel.
In other words:
DEV=/dev/sdd makesd pyra -r debian
This is currently still a Debian Jessie and sysvinit (8.7) but upgrade to Debian 9.0 systemd is in the works. I think X11 is installed but no GUI. So you can either apt-get install lxde or xfce4 if you need.
Then you can remove drivers and things from the boot process that are not needed.
But of course there are thousands of roads to Rome :)
BR, Nikolaus
-- Mit freundlichen Grüßen,
Michael Mrozek
DragonBox Shop OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.dragonbox.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: info@dragonbox.de
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am Sat, 18 Mar 2017 11:58:30 +0100 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Nikolaus already has a collection of scripts for testing and notaz already adopted the input tester.
Yes, especially the hw-test tool: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/hw-test;h=0...
Thanks for the link.
I use this for the GTA04 to create test reports like this: http://www.gta04.org/serial.php?serial=5285-0050 But it is not as fully automatic as it should be to hand over to the production facility.
Well, writing scripts to mostly automate that is what I can do.
I can work on the test and scripts file, but I need someone who can create the basic filesystem for booting and testing. Who can help me there? :)
You could try:
http://download.goldelico.com/letux-debian-rootfs/latest-minimal.tbz and mix with latest u-boot, kernel. In other words:
DEV=/dev/sdd makesd pyra -r debian This is currently still a Debian Jessie and sysvinit (8.7) but upgrade to Debian 9.0 systemd is in the works. I think X11 is installed but no GUI. So you can either apt-get install lxde or xfce4 if you need.
That's probably not what we can use for the mass production, as I can't imagine Debian booting up in 2 seconds.
The card on the Pandora starts with the tests immediately after loading the kernel, there's no OS that needs to be booted.
Then you can remove drivers and things from the boot process that are not needed.
Wrong idea: We shouldn't even have a real boot process there, as that takes too long.
This could be used for setting up such a test pretty fast, but I'd rather start with the "real" test SD Card (for the mass production) right away, otherwise he have to do it twice.
-- Mit freundlichen Grüßen,
Michael Mrozek
DragonBox Shop OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.dragonbox.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: info@dragonbox.de
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 18.03.2017 um 12:59 schrieb Michael Mrozek shop@dragonbox.de:
Am Sat, 18 Mar 2017 11:58:30 +0100 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Nikolaus already has a collection of scripts for testing and notaz already adopted the input tester.
Yes, especially the hw-test tool: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/hw-test;h=0...
Thanks for the link.
I use this for the GTA04 to create test reports like this: http://www.gta04.org/serial.php?serial=5285-0050 But it is not as fully automatic as it should be to hand over to the production facility.
Well, writing scripts to mostly automate that is what I can do.
My tool could also start automatically right after booting, but since it includes an upload to the server to store the MAC and IMEI addresses and requires manually typing in some serial number, it would also need to set up a test PC...
You may wonder why I read out the MAC and IMEI addresses? This is to print the individual device label since it is handy to have these printed somewhere without opening or booting the device. It also makes the devices better traceable for production issues, repair, warranty etc. But AFAIsee it is not necessary to do so.
I can work on the test and scripts file, but I need someone who can create the basic filesystem for booting and testing. Who can help me there? :)
You could try:
http://download.goldelico.com/letux-debian-rootfs/latest-minimal.tbz and mix with latest u-boot, kernel. In other words:
DEV=/dev/sdd makesd pyra -r debian This is currently still a Debian Jessie and sysvinit (8.7) but upgrade to Debian 9.0 systemd is in the works. I think X11 is installed but no GUI. So you can either apt-get install lxde or xfce4 if you need.
That's probably not what we can use for the mass production, as I can't imagine Debian booting up in 2 seconds.
Yes, it indeed takes longer. It typically needs ~30 seconds up to X11.
But I don't know how much the networking stack and low console RS232 speed is influencing. Or checking the SD card rootfs for integrity. BTW: systemd is booting much faster.
If you want 2 seconds it is a real challenge. U-Boot already waits 2 seconds until it starts the boot script. Maybe you can use the SPL Falcon mode (which makes SPL load and start a RAM image of the kernel+FTD bypassing the whole U-Boot stuff - basically you cache the RAM before "Starting kernel...").
The card on the Pandora starts with the tests immediately after loading the kernel, there's no OS that needs to be booted.
One thing we need to test the display is to load the full DSS/DSI/MIPI stuff. Or we have no display. That is different from the Pandora where it is possible to use the display in U-Boot. If you use Falcon mode you already have a kernel with DSS support.
Then you can remove drivers and things from the boot process that are not needed.
Wrong idea: We shouldn't even have a real boot process there, as that takes too long.
You are right... I am currently flashing and testing a tiny fraction of the Pyra quantity of GTA04A5 boards and it takes quite boring time waiting...
This could be used for setting up such a test pretty fast, but I'd rather start with the "real" test SD Card (for the mass production) right away, otherwise he have to do it twice.
I see. Please feel free to take my scripts as blueprints for controlling the peripherals.
BR, Nikolaus
Hi,
On Sat, Mar 18, 2017 at 10:15 AM, Michael Mrozek shop@dragonbox.de wrote:
Hi,
as we need to have an easy and fast way to test the Pyra boards for defects, I'd like to start working on a Test- and OS-Flasher-Card that will also be used by GC to preinstall and test the units on mass production.
Similar to the one on the Pandora: https://cloud.openpandora.org/index.php/s/HiXoyEsaXryhx20
I think we can adapt and reuse the pandora's one, IIRC it doesn't do anything hardware specific before it starts the main script. That is unless somebody has a better idea.
Pandora's rootfs is appended to boot.scr, get it with: dd if=boot.scr of=rootfs.gz bs=4k skip=801
Then on a Pyra, set up u-boot to use that rootfs as a init ram disk. In uEnv.txt: fatload mmc 0 0x81000000 rootfs.gz setenv bootargs console=${console} ramdisk_size=8192 root=/dev/ram0 rw rootfstype=ext2 initrd=0x81000000,8M
With that it should hopefully boot into the ramdisk. You can gunzip rootfs.gz and mount it on a PC to add/edit stuff, but I suggest keeping as much as possible in the scripts directly on the SD card. The scripts themselves of course need to be completely redone.
This is all untested and probably needs adjustments, it's a real chore to work with my current board so I'd like to avoid that.
Gražvydas
Am Sat, 18 Mar 2017 19:49:45 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
as we need to have an easy and fast way to test the Pyra boards for defects, I'd like to start working on a Test- and OS-Flasher-Card that will also be used by GC to preinstall and test the units on mass production. Similar to the one on the Pandora: https://cloud.openpandora.org/index.php/s/HiXoyEsaXryhx20
I think we can adapt and reuse the pandora's one, IIRC it doesn't do anything hardware specific before it starts the main script. That is unless somebody has a better idea.
That's perfectly fine with me :)
Pandora's rootfs is appended to boot.scr, get it with: dd if=boot.scr of=rootfs.gz bs=4k skip=801
Okay, easily possible.
Then on a Pyra, set up u-boot to use that rootfs as a init ram disk. In uEnv.txt: fatload mmc 0 0x81000000 rootfs.gz setenv bootargs console=${console} ramdisk_size=8192 root=/dev/ram0 rw rootfstype=ext2 initrd=0x81000000,8M
Okay, then I'll need some u-boot then which does load uEnv.txt. No idea what the status is, we have various testing U-Boots around, but Matthijs might be able to help me here.
With that it should hopefully boot into the ramdisk. You can gunzip rootfs.gz and mount it on a PC to add/edit stuff, but I suggest keeping as much as possible in the scripts directly on the SD card. The scripts themselves of course need to be completely redone.
Well, we can reuse some parts (parts of the Wifi-Test, USB- / SD-Card tests, etc.), but that should be something I can mostly do myself.
Having the scripts directly on the SD Card is easiest, as it makes adjusting the scripts a lot more convenient.
This is all untested and probably needs adjustments, it's a real chore to work with my current board so I'd like to avoid that.
I'll try to assemble another unit for you this week (hopefully one without any errors, as I cannot fully test them without the tester card ;))
Just send me your new address :)
Gražvydas _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 18.03.2017 um 20:25 schrieb Michael Mrozek shop@dragonbox.de:
Am Sat, 18 Mar 2017 19:49:45 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
as we need to have an easy and fast way to test the Pyra boards for defects, I'd like to start working on a Test- and OS-Flasher-Card that will also be used by GC to preinstall and test the units on mass production. Similar to the one on the Pandora: https://cloud.openpandora.org/index.php/s/HiXoyEsaXryhx20
I think we can adapt and reuse the pandora's one, IIRC it doesn't do anything hardware specific before it starts the main script. That is unless somebody has a better idea.
That's perfectly fine with me :)
Yes, that is probably the quickest approach.
Pandora's rootfs is appended to boot.scr, get it with: dd if=boot.scr of=rootfs.gz bs=4k skip=801
Okay, easily possible.
Then on a Pyra, set up u-boot to use that rootfs as a init ram disk. In uEnv.txt: fatload mmc 0 0x81000000 rootfs.gz setenv bootargs console=${console} ramdisk_size=8192 root=/dev/ram0 rw rootfstype=ext2 initrd=0x81000000,8M
Okay, then I'll need some u-boot then which does load uEnv.txt. No idea what the status is, we have various testing U-Boots around, but Matthijs might be able to help me here.
Just use our u-boot 2016.11.
It is already uEnv.txt based:
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=Letux/boot-scr/uEnv-let...
But you need to adapt to use an init ram disk.
BTW: this is something we should do anyways for the PyraOS since then we can get the display running very early and use Linux for a boot menu.
With that it should hopefully boot into the ramdisk. You can gunzip rootfs.gz and mount it on a PC to add/edit stuff, but I suggest keeping as much as possible in the scripts directly on the SD card. The scripts themselves of course need to be completely redone.
Well, we can reuse some parts (parts of the Wifi-Test, USB- / SD-Card tests, etc.), but that should be something I can mostly do myself.
Having the scripts directly on the SD Card is easiest, as it makes adjusting the scripts a lot more convenient.
This is all untested and probably needs adjustments, it's a real chore to work with my current board so I'd like to avoid that.
I'll try to assemble another unit for you this week (hopefully one without any errors, as I cannot fully test them without the tester card ;))
Just send me your new address :)
Gražvydas _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
DragonBox Shop OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.dragonbox.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: info@dragonbox.de
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel