Hi Paul, > Am 27.03.2019 um 14:40 schrieb Paul Boddie <[email protected]>: > > On Wednesday 27. March 2019 08.26.29 H. Nikolaus Schaller wrote: >> >>> Am 25.03.2019 um 11:55 schrieb Paul Boddie <[email protected]>: >>> >>> Yes, I have a CI20 board. >> >> Ah, great! > > I may have mentioned it before somewhere, maybe not on this list, though. > > [...] > >>> Apart from that, I have used the Debian GNU/Linux distribution on the >>> CI20, but since I don't care about the GPU (and don't like proprietary >>> drivers/firmware), >> >> Yes, I don't as well, but if it is the only choice, I am not that >> ideological... Anyways there is the GPLed kernel driver which I am >> currently interested in. > > It would actually be interesting to make alternative firmware,
yes, this is the very very long term goal. > and I think > efforts have been made for other GPU technologies in this regard, but it > requires a lot of time and reverse engineering plus familiarity with the > technologies involved. > > But even with GPL-compatible kernel drivers, these proprietary GPUs cause > considerable problems, although I am surely telling this to someone who > already knows about the practical difficulties they cause. :-) I think we articficially make the long-term goal even farther away by not having a working GPLed kernel driverfor loading and interfacing to the specific SoC. Therefore everyone has to start with getting something working. Which may already too painful because it is not available for the latest kernel, there are parts missing (e.g. for omap in the clocks and hwmods setup). So the barrier to start reverse engineering of closed parts is high, because the open source parts are not easily working. The latter is what I am trying to achieve... Yes, it is already a lot of work. But also fun. > >>> I haven't used it with the GPU enabled. On some occasions, I have used it >>> as a desktop system, but more often I log into it across the network. >> >> That is like what I do with a Letux Cortex 8 and a RasPi 3B+. Just to habe >> specific compute power for special tasks. For example debootstrapping the >> LetuxOS rootfs images. > > Right. Indeed, I should use it a bit more for building things, and I think > the > power consumption is pretty good, although I haven't measured it. One thing > that disappointed people was the wired network performance, recalling the > reaction from the OpenWrt community. (I also haven't tried the wireless > network support because that involves another binary blob.) > > [...] > >>> I then used a later kernel (3.18 instead of 3.08) for which the supplied >>> GPU drivers probably wouldn't work, anyway, and I didn't fetch newer >>> ones. Of course, Imagination have dropped the CI20 completely, so the >>> links on elinux.org do not work (as you probably saw already): >>> >>> https://www.elinux.org/CI20-SGX_kernel_module >> >> Yes. I have already been able to find a copy of the DDK1.14 files. >> >> Comparing with the TI provided DDK1.14 shows that they are almost the same, >> except that TI added better OMAP support than the IMG package. But there >> are ca. 15 code changes in general code which will become interesting to >> study. > > I should probably take a look. I have occasionally browsed the documentation > for PowerVR in case there were some helpful things released that might make > improved Free Software support possible, but I don't really have a focus on > this kind of thing. > > [...] > >>> I tend to use SD cards for new installations, however, leaving the flash >>> memory alone. >> >> Yes, that is probably not a big issue then. >> >> A question about the SD format for the non-Flash case: does it also have the >> standard 2-Partition scheme (FAT for u-boot and uImage and DTB) plus an ext >> for rootfs? > > The instructions I followed are here: > > https://www.elinux.org/CI20_Dev_Zone#Making_a_bootable_SD_card_from_sources > > I don't think the FAT partition is needed. On one of my cards, I just have a > single "Linux" partition: > > Device Boot Start End Sectors Size Id Type > /dev/sdc1 4096 15278079 15273984 7.3G 83 Linux > > And the partition uses the ext4 filesystem. So it is a similar arrangement to > that supported by the Ben NanoNote, with the difference being that the > NanoNote has a modified U-Boot in the flash memory that understands ext2/3/4 > to access the SD card, whereas the process is supported directly by the CI20 > hardware by changing a "jumper" on the board. > > (It's possible that the JZ4720 on the NanoNote might also support booting to > SD, but it could be a feature of newer SoCs. The JZ47xx series support > booting > over USB in the SoC which is also a possibility with the CI20.) > >> Then we might be easily able to have makesd support the CI20 as well. >> >> If it uses a hidden section for binary U-Boot and/or kernel it is also >> possible but a little more tricky and more difficult to maintain. >> >> So it is good to know that you have such a board an might be able to help >> testing or setting up another one. > > As far as I remember, it is all rather transparent. There is no special FAT > boot partition like on the Letux 400, and the uImage just lives in /boot in > the main partition. U-Boot itself gets installed into a specific region near > the start of the disk, but I don't think this is particularly exotic. Yes, that is what I mean with the "hidden section". It seems to contain the SPL and U-Boot. Basically using a FAT partition was just a trick on OMAP to make life easier. The BootROM started to look for the boot loader (MLO, now called SPL) at a specific sector. If the SD card was formatted as FAT and the first file written to it was called "MLO" it happened to sit at the correct position (and checksums inside the file made the BootROM accept it). So this was equivalent to a dd seek= Later omap chips and others got a BootROM that understands FAT... While other SoC did not even try to "overlay" a FAT partition. The Udoo neo (i.MX6) is such an example. Therefore, makesd understands macros to shift the beginning of the first sector of a partition to make room. And another option allows to install a file directly into some sector(s) by running some dd after download. So the CI20 doesn't seem to be an exception here and makesd should be able to handle it without new functionality. Just needs the (U-Boot+SPL) file to be installed on the server and a macro that describes the partition scheme and runs the dd commands in the elinux page you have mentioned. So I am really tempted to try to get one now :) BR, Nikolaus _______________________________________________ Community mailing list [email protected] http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
