Hi Pavel and others who already responded, Am 01.12.2015 um 13:22 schrieb Pavel Borecki <pavel.bore...@gmail.com>:
> Hi all, > > my personal opinions on this matter: > > 1. don't risk incompatible hw mixture, which could not be functional > from hw point of view. > It means, that if combination of this model of OMAP3 SoC and 1GB RAM is > unsupported/discouraged from TI, then don't do it. There is no problem with recommendation (there isn't any). It is just some risk that it has only been tested on two BeagleBoard XM units for the Neo900. > But Neo900 project is using the same SoC, so it seems, that this > combination (SoC + 1GiB RAM is safe from hw point of view)? > > 2. regarding sw support (bootloader) > There are potentially two projects, which are interested in porting > newer uBoot and add support for more RAM - GTA04A5 with 1GB RAM and > Neo900. Especially for second one 512MB isn't an option, so this work > must be done by them. So, why not cooperate in this too? In fact we had cooperated for this. I have found that we already have merged the correct patch into our MLO/X-Loader to handle 1GB RAM: http://git.goldelico.com/?p=gta04-xloader.git;a=commit;h=5489cbb2269dab6a1cf00f68cb6d183628906ed9 So the issue reduces to useability of the OneNAND. It is not really required for the MLO/X-Loader if it comes from µSD. But we can't store the boot environment if we can't flash the OneNAND. And flashing for X-Loader and u-boot is done by our u-boot which does not (yet) support OneNAND well/correctly enough. > > 2a. regarding bootloader itself - as wise as be able to run vanilla > upstream kernel, it would be good to have upstream support in bootloader > too. Because sustainability. If future kernels will change something, > which reflects in changes in bootloaders, then it will be good to have > possibility to flash current one. Maybe worth of other subproject as > gta04-kernel upstreaming like? Well, there is no need to do this in a hurry. The kernel gets release candidates every week and releases every 2-3 months. And you can simply put a new version on a different µSD and swap them back and forth. U-Boot also has releases every now and then. But there was no new feature for approx. 4 years we really need. In other words: never touch a running boot loader (unless you must). So IMHO it is not necessary to have quick releases. The last major change influenced by the kernel we did was to change the partition scheme because the kernel did grow >4MB binary. And now we have to think about one new feature: support OneNAND. Yes, we should switch to u-boot 2015.10 and port all our extensions. But then leave it as it is for a while... This is quite some work because it must be finished and 100% tested before shipping devices. Of course it can be done in parallel to the GTA04A5 production planning and setup so that we have some weeks to do it. Testing is the key bottleneck. But I have an idea. We might be able to rework one of the "Second Choice" GTA04A4 board where something is broken to a level that it can't be used as a phone. But after replacing the memory chip it can be used for developing and testing. > > Why bother with more than 512 MB of RAM? Because the one OS, which is > really usable for daily use as phone is Replicant. And according > personal experience with some older Samsung with 512MB of RAM, 1GB would > be really nice... > (this platform and applications aren't resources friendly) Yes, it would be better - but because someone asked: Replicant works on the GTA04A4 with 512 MB RAM without apparent issues. Some apps might of course suffer. Regarding alternative systems to fit into the 512 MB NAND, QtMoko is a good choice, but we must first get it compiling again to do adjustments for the new GTA04A5 hardware. For X11 systems we just have to find out what needs so much space. The first A3 and A4 boards were shipped with Debian Squeeze and LXDE on X11. And it did fit into 512 MB. Only Wheezy and now Jessie increased the footprint without walking better or faster... If someone wants to test, please install: http://download.goldelico.com/gta04-debian-rootfs/20151024-jessie-8.2-lxde.tbz and tun the /root/flash-nand script from http://git.goldelico.com/?p=gta04-rootfs.git;a=blob;f=config/root/flash-nand;hb=refs/heads/master and analyse if there are more things (packages, caches?) we can remove w/o problems. To summarise comments: community is in favour of 1 GB RAM and accepting some potential work/delay to get the OneNAND working and some default/demo/test OS squeezed into the smaller NAND. I am now also in favour of this approach and will prepare the required tests and actions. BR, Nikolaus > > What are thoughts of other pre-owners (voucher buyers) and potential > buyers? > > P. > > H. Nikolaus Schaller píše v So 28. 11. 2015 v 20:08 +0100: >> Hi Pavel, >> >> Am 27.11.2015 um 19:50 schrieb Pavel Borecki <pavel.bore...@gmail.com>: >> >>> Hi, >>> >>> will GTA04A5 have 512 MB or 1GB of RAM? >>> In shop, there is 512 MB stated, but on order tracking, there is a >>> message: >>> >>> "3. good news: we participated in the risk buy of Samsung 1GB RAM+512MB >>> NAND chips (as planned for the Neo900). So you will get 1 GB RAM and >>> faster NAND! Twice as much RAM as the GTA04A4 has. It has already been >>> tested by reworking a BeagleBoard XM and modifying the OS." >>> >>> So, what amount of RAM will be soldered as PoP package? >> >> Thanks for asking! This is one of the things I forgot to mention. >> >> It is also something I am not really sure about yet, but we must decide in >> the next >> couple of days. Chips of both types are available to us so we simply can >> choose >> and have no sourcing problems. >> >> The first issue is that the PoP RAMs with 1GB+512MB have only been tested on >> a BB-XM yet. Not on a real GTA04 board. And we have no complete boot system >> for it in our software setup. Just some partially manual tests have been done >> (e.g write NAND, read back). This means we can't test the boards right after >> production >> because we have no known good µSD card image, because that needs a GTA04 >> to develop and test the µSD card image first... >> >> A second issue is that we can use OneNAND only with a more recent U-Boot than >> we currently have. But this means porting our special U-Boot extensions to a >> newer U-Boot and test and get it working first. >> >> This isn't that easy as it looks because we have some 2009 U-Boot as the >> basis >> and the latest is 2015.10 :) Bridging upstream developments of >5 years is a >> big >> project. And the boot-loader should be rock solid. The old one is - except >> for >> supporting the OneNAND of the 1G+512MB chips. >> >> In other words: with 512MB+1GB this is not a risk area at all (because half >> of >> the GTA04A4 boards have this configuration and run w/o any problems). >> >> The 1GB + 512MB increases the project risks. >> >> Another (probably easier to solve) issue for the 1GB + 512MB is that we want >> to provide some default Linux+Debian+LXDE (or something else) in NAND for >> all GTA04A5 boards we ship. So that you have something to boot into before >> partitioning and even buying any µSD card. >> >> Unfortunately we have not yet managed to squeeze Wheezy nor Jessie images >> so that they fit into ~450 MB. They end up with ~800 MB. >> >> Therefore they would easily fit into the 512MB + 1GB chips, but not in the >> 1GB + 512MB. >> >> If someone has an idea how to strip it better down than this script, please >> let >> me know: >> >> <http://git.goldelico.com/?p=gta04-rootfs.git;a=blob;f=config/root/flash-nand;hb=refs/heads/master> >> >> (this script already strips unneeded kernel modules and most debian caches). >> >> So we have to trade off between risk and having a working system installed >> when you want to test your motherboard exchange results. >> >> I guess everyone has his/her own preferences so that I would like to learn a >> little >> about your opinions before we decide. >> >> BR and thanks, >> Nikolaus >> >> >>> >>> Thanks >>> Pavel > > _______________________________________________ > Community mailing list > Community@openphoenux.org > http://lists.goldelico.com/mailman/listinfo.cgi/community > http://www.openphoenux.org _______________________________________________ Community mailing list Community@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.openphoenux.org
