> Am 27.03.2019 um 17:32 schrieb Paul Boddie <[email protected]>:
> 
> On Wednesday 27. March 2019 15.47.28 H. Nikolaus Schaller wrote:
>> 
>> 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.
> 
> I agree with this. You have to start somewhere.
> 
>> 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.
> 
> Yes, this is the unsustainable thing with Free Software components that 
> supposedly isolate the Linux kernel from proprietary software.
> 
>> The latter is what I am trying to achieve...
>> 
>> Yes, it is already a lot of work. But also fun.
> 
> But it is worth pursuing even if it just prolongs the life of a few products.
> 
> [Installing U-Boot in a gap between the partition table and the first 
> partition]
> 
>> 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=
> 
> That is a neat hack, it must be said.
> 
>> 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.
> 
> Yes, once you know what the requirements are, it really shouldn't be 
> difficult 
> to support the necessary copying commands.
> 
>> So I am really tempted to try to get one now :)
> 
> If you do, you should find it pretty easy to get a distribution working. 
> There 
> were some problems with Debian Stretch if you wanted to avoid systemd, which 
> was something I was attempting for the sake of continuity, and it seemed that 
> only Debian Jessie could support that configuration.

Well, LetuxOS has some letux-system-d.deb package... If it is installed it
will "remove" (i.e. prevent) systemd to be installed by setting an apt config.
So far it seems to work quite well - but only for Jessie.

Anyways, my systemd experiences with Stretch and Buster were not that bad.
In most cases it boots faster and sometimes it is easier to understand if
daemons with dependencies must be defined. But it is difficult to understand
the existing ones written by someone else.

One thing has changed since systemd and Debian 8 did appear: it is much easier
to google for examples and tutorials and documentation. That was difficult
during Jessie + systemd times.

> 
> With systemd, Stretch seems to work fine. There might be some extra package 
> configuration required in any case. I seem to be very good at finding corner 
> cases in Debian that cause things not to work properly for me.
> 
> Even if you don't get one, if you let me know which repositories I should be 
> looking at, I might be able to take a closer look at the code.

So I have ordered one some minutes ago. The key idea was that I expect to
get a board where I can more easily test and debug the MIPS variant of
LetuxOS incl. kernels. And then this might help to get it onto the
MipsBooks/Letux 400...

BR,
Nikolaus

_______________________________________________
Community mailing list
[email protected]
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Reply via email to