Here's a test image with a tiler enabled 4.8.1 kernel, and an u-boot that show the extlinux menu( on the serial output) . The default kernel will load after a 3 second timeout
http://packages.pyra-handheld.com/images/extra/tiler/pyra-debian-jessie-mate...
either extract the .img, and dd to an sd card , or use a disk image writer (i use gnome-disks, which can handle .img.xz directly)
At least an 8GB card is needed. The image contents are a lot less, but it's nice to have a bit of extra space without having to resize the partition.
The tiler hack is started automatically by systemd through tiler.service, and just runs the script located at /usr/share/pyra/scripts/tiler.sh
This also helps fix the problem I kept having where fbset reports a 1024x768 framebuffer, and nothing gets output on the lcd (probably because it sometimes seems to thinks nothing is connected to the lcd output during boot.)
Hi,
Am 14.10.2016 um 02:45 schrieb aTc atc@k-n-p.org:
Here's a test image with a tiler enabled 4.8.1 kernel, and an u-boot that show the extlinux menu( on the serial output) .
Oh nice! Will give it a try asap.
Would it be difficult to share the source code of the u-boot patches?
The default kernel will load after a 3 second timeout
http://packages.pyra-handheld.com/images/extra/tiler/pyra-debian-jessie-mate...
either extract the .img, and dd to an sd card
well, that can fail if the target SD is a little smaller (1-2% variation of "official" 8GB are possible) than baked into the .img.
, or use a disk image writer (i use gnome-disks, which can handle .img.xz directly)
At least an 8GB card is needed. The image contents are a lot less, but it's nice to have a bit of extra space without having to resize the partition.
How do you manage that with dd images? AFAIK they have a fixed partition size and simply don't use the space of bigger cards. So an 8GB dd image expanded onto a 16GB card gives an 8GB file system.
This is one of the main reasons why I have completely retired the dd images a while ago and developed the makesd tool. But if there is a better solution it would indeed be easier to distribute dd images of variable size.
So I am really curious to learn how this works.
The tiler hack is started automatically by systemd through tiler.service, and just runs the script located at /usr/share/pyra/scripts/tiler.sh
Would it be possible to provide a direct download link (instead of pulling from the .img).
I would like to include both, the Tiler kernel patches and this script in the Letux kernel tree so that we can build/modify that independently of user-space code and have a well known location where tiler kernel code and helper scripts are version-managed.
This also helps fix the problem I kept having where fbset reports a 1024x768 framebuffer, and nothing gets output on the lcd (probably because it sometimes seems to thinks nothing is connected to the lcd output during boot.)
BR and thanks, Nikolaus
On 14 October 2016 at 07:38, H. Nikolaus Schaller hns@goldelico.com wrote:
How do you manage that with dd images? AFAIK they have a fixed partition size and simply don't use the space of bigger cards. So an 8GB dd image expanded onto a 16GB card gives an 8GB file system.
resize2fs
Am 14.10.2016 um 08:21 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 14 October 2016 at 07:38, H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> wrote: How do you manage that with dd images? AFAIK they have a fixed partition size and simply don't use the space of bigger cards. So an 8GB dd image expanded onto a 16GB card gives an 8GB file system.
resize2fs
Yes, I know. If it works (has some subtle issues I don't remember in detail). And if you want to change partition sizes (if we have 2 partitions) it is also possible in combination with fdisk.
But if you have to run an additional tool on the result, why not do it in one step (./makesd ...) and right from the beginning?
On Fri, Oct 14, 2016 at 09:30:25AM +0200, H. Nikolaus Schaller wrote:
Am 14.10.2016 um 08:21 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 14 October 2016 at 07:38, H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> wrote: How do you manage that with dd images? AFAIK they have a fixed partition size and simply don't use the space of bigger cards. So an 8GB dd image expanded onto a 16GB card gives an 8GB file system.
resize2fs
Yes, I know. If it works (has some subtle issues I don't remember in detail). And if you want to change partition sizes (if we have 2 partitions) it is also possible in combination with fdisk.
But if you have to run an additional tool on the result, why not do it in one step (./makesd ...) and right from the beginning?
As a Gentoo fan, I admire building the image from source (that is, makesd) :)
Otherwise, I think it's to the point to mention "armbian" distro, which is distributed as dd-able file with partitions of minimal size; on the first boot, the system expands the partition(s?) to make use of all available space. May be worth looking and making use of their solution.
On 10/14/2016 07:38 AM, H. Nikolaus Schaller wrote:
Hi,
Am 14.10.2016 um 02:45 schrieb aTc atc@k-n-p.org:
Here's a test image with a tiler enabled 4.8.1 kernel, and an u-boot that show the extlinux menu( on the serial output) .
Oh nice! Will give it a try asap.
Would it be difficult to share the source code of the u-boot patches?
You can find them, and the tiler stuff here: http://packages.pyra-handheld.com/images/extra/tiler/
And about the patched u-boot, on my pyra the previous u-boot seemed to have glitched to do a saveenv for some reason ( it probably went into the fastboot stuff), which causes it not to pick up the new config. In that case you need to reset the env to its default (env default -a) and save it.
The default kernel will load after a 3 second timeout
http://packages.pyra-handheld.com/images/extra/tiler/pyra-debian-jessie-mate...
either extract the .img, and dd to an sd card
well, that can fail if the target SD is a little smaller (1-2% variation of "official" 8GB are possible) than baked into the .img.
Yes, that's why I made the image 7GB , i've had similar problems with the rpi image that was just a few bytes larger than my sd card.
I've got scripts to output the rootfs as either a .tar.xz/gz , and use a makesd type script to install it to sd, or as a full.img , which is much easier to install for an end user, since it requires far less support tools, and doesn't have as many problems running on win/mac.
I don't really like the "write a full image to an sd card" method either though :)
I would like to include both, the Tiler kernel patches and this script in the Letux kernel tree so that we can build/modify that independently of user-space code and have a well known location where tiler kernel code and helper scripts are version-managed.
the tiler patches came from Matthijs's kernel at https://github.com/mvduin/linux/tree/work/merged
I just merged them into the newer 4.8.1. There are still a lot of problems and evil code in there. (biggest problem is currently that the screen turns off after 10 seconds if /dev/dri/card0 isn't kept open, which is what tiler.sh tries to do)
Hi,
Am 14.10.2016 um 12:26 schrieb aTc atc@k-n-p.org:
On 10/14/2016 07:38 AM, H. Nikolaus Schaller wrote:
Hi,
Am 14.10.2016 um 02:45 schrieb aTc atc@k-n-p.org:
Here's a test image with a tiler enabled 4.8.1 kernel, and an u-boot that show the extlinux menu( on the serial output) .
Oh nice! Will give it a try asap.
Would it be difficult to share the source code of the u-boot patches?
You can find them, and the tiler stuff here: http://packages.pyra-handheld.com/images/extra/tiler/
Thanks! I will try to integrate it into the Letux kernel tree. I have started to rebase to v4.9-rc1.
And about the patched u-boot, on my pyra the previous u-boot seemed to have glitched to do a saveenv for some reason ( it probably went into the fastboot stuff), which causes it not to pick up the new config. In that case you need to reset the env to its default (env default -a) and save it.
Yes, I remember that I had to do that once a while.
For your patch I am not sure if it is wise to hard encode the dtb file name. It should be set by uEnv.txt.
But before applying any changes I still have to debug the u-boot 2016.09 source tree I have created last week. It does not even run MLO. So something went wrong or missing during upgrade. Maybe a simple CONFIG.
The default kernel will load after a 3 second timeout
http://packages.pyra-handheld.com/images/extra/tiler/pyra-debian-jessie-mate...
either extract the .img, and dd to an sd card
well, that can fail if the target SD is a little smaller (1-2% variation of "official" 8GB are possible) than baked into the .img.
Yes, that's why I made the image 7GB , i've had similar problems with the rpi image that was just a few bytes larger than my sd card.
Ok, that is of course a workaround. If a resize is required/recommended anyways, the image could also be made as small as possible. I.e. just 20% bigger than the sum of all files.
I've got scripts to output the rootfs as either a .tar.xz/gz , and use a makesd type script to install it to sd, or as a full.img , which is much easier to install for an end user,
Yes, in the long run there should be some image created by applying makesd to a loopback device. On the other hand it is probably only ED and some developers who want to make fresh SD cards without a Pyra.
makesd runs fine on a Pyra and can pull together things on a SD card in the second slot.
I always dream to write a small GUI wrapper for makesd so that people can simply open some "SD card generator" app. This could even either download a full image for simple unpack or run makesd (or a successor).
But I have to many other things to do.
since it requires far less support tools, and doesn't have as many problems running on win/mac.
Well, makesd has indeed a big problem on Mac... It can't write ext2/3/4 without problems. There is MacFUSE/OSXFuse but writing ext file systems is discouraged because it is slow and buggy.
I don't really like the "write a full image to an sd card" method either though :)
Then, we at least agree in that :) My answer was to develop makesd...
I would like to include both, the Tiler kernel patches and this script in the Letux kernel tree so that we can build/modify that independently of user-space code and have a well known location where tiler kernel code and helper scripts are version-managed.
the tiler patches came from Matthijs's kernel at https://github.com/mvduin/linux/tree/work/merged
Thanks! I will check if and how I can update the code in http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/te... for 4.9-rc1.
so that the result should be the same as merging.
I just merged them into the newer 4.8.1. There are still a lot of problems and evil code in there. (biggest problem is currently that the screen turns off after 10 seconds if /dev/dri/card0 isn't kept open, which is what tiler.sh tries to do)
Ok. Something that can be fixed as soon as more hardware is available.
BR and thanks, Nikolaus
-
Andrey Utkin -
aTc -
H. Nikolaus Schaller -
Matthijs van Duin