Comments on: TODO Items and Work Plan (02.07.2019) http://bvt-trace.net/2019/07/todo-items-and-work-plan-jul2019/ Fri, 21 Aug 2020 17:11:44 +0000 http://polimedia.us hourly 1 By: Contribution Guidelines for TMSR OS « Dorion Mode http://bvt-trace.net/2019/07/todo-items-and-work-plan-jul2019/#comment-104 Contribution Guidelines for TMSR OS « Dorion Mode Sat, 14 Dec 2019 06:32:32 +0000 http://bvt-trace.net/?p=41#comment-104 [...] Mogosanu (WoT: spyked) for December 2019 and Eric Benevides for December 2019, bvt (WoT: bvt) for July 2019 and Young Hands. [↩] Articles publishing a vpatch, should have context about the vpatch, your [...] [...] Mogosanu (WoT: spyked) for December 2019 and Eric Benevides for December 2019, bvt (WoT: bvt) for July 2019 and Young Hands. [↩] Articles publishing a vpatch, should have context about the vpatch, your [...]

]]> By: Stanislav Datskovskiy http://bvt-trace.net/2019/07/todo-items-and-work-plan-jul2019/#comment-24 Stanislav Datskovskiy Sun, 07 Jul 2019 19:49:12 +0000 http://bvt-trace.net/?p=41#comment-24 Re: RK3399: sounds like that old Czech folk tale, where they had: "the king demands your hand in marriage." "is he young?" "he's old!" "is he kind?" "no, vicious!" "old and vicious, just like a husband ought to be!" Re: RK3399: sounds like that old Czech folk tale, where they had: "the king demands your hand in marriage." "is he young?" "he's old!" "is he kind?" "no, vicious!" "old and vicious, just like a husband ought to be!"

]]> By: bvt http://bvt-trace.net/2019/07/todo-items-and-work-plan-jul2019/#comment-23 bvt Sun, 07 Jul 2019 19:19:34 +0000 http://bvt-trace.net/?p=41#comment-23 @Stanislav Datskovskiy: My expectation was that the board will work reasonably well with storage, i.e. m.2 SSD. The problem is that its m.2 slot is not designed to be used for storage as is -- it has a weird pinout that is compatible with wifi cards or some other crap; to use an SSD with that slot you need an adapter board that will make the slot pinout match the standard (available from the vendor, and no, it's not b-key to m-key, it's something board-specific). I could've also used an usb3 SSD, however in this case any cheaper boards will work as well. Another problem is that I failed to get a usable TCP speed on this board -- the sustained download/upload speed (TCP/http, no sslisms involved) was ~100kbps, over 1G wire; and the connection was never stable. The network tweaks that I knew about did not work out, and I did not have enough time to go into device tree tweaking (that some do), or picking kernel version on which the network would work reliably (I never tested wifi with the board). So in summary you have an expensive board that is clearly not designed to work with storage, big.LITTLE -> not designed to work with stock kernel, which requires time investment with unclear outcome to be even useful due to unstable wired network. It very much seems that that rk3399 is a multimedia chipset, that is supposed to be used in various toys, and lacks the things that you'd want in a small server. The core of the work that I did was to build uboot with a configuration capable of booting the board off SSD (without which you can't really gentoo), and then to tweak uboot script to ignore the kernel arguments in the device tree, and use uboot-provided ones -- I had little experience with ARM boards before. But yes, your rootfs worked nicely with it. @Stanislav Datskovskiy: My expectation was that the board will work reasonably well with storage, i.e. m.2 SSD. The problem is that its m.2 slot is not designed to be used for storage as is -- it has a weird pinout that is compatible with wifi cards or some other crap; to use an SSD with that slot you need an adapter board that will make the slot pinout match the standard (available from the vendor, and no, it's not b-key to m-key, it's something board-specific). I could've also used an usb3 SSD, however in this case any cheaper boards will work as well. Another problem is that I failed to get a usable TCP speed on this board -- the sustained download/upload speed (TCP/http, no sslisms involved) was ~100kbps, over 1G wire; and the connection was never stable. The network tweaks that I knew about did not work out, and I did not have enough time to go into device tree tweaking (that some do), or picking kernel version on which the network would work reliably (I never tested wifi with the board).

So in summary you have an expensive board that is clearly not designed to work with storage, big.LITTLE -> not designed to work with stock kernel, which requires time investment with unclear outcome to be even useful due to unstable wired network. It very much seems that that rk3399 is a multimedia chipset, that is supposed to be used in various toys, and lacks the things that you'd want in a small server.

The core of the work that I did was to build uboot with a configuration capable of booting the board off SSD (without which you can't really gentoo), and then to tweak uboot script to ignore the kernel arguments in the device tree, and use uboot-provided ones -- I had little experience with ARM boards before. But yes, your rootfs worked nicely with it.

]]> By: Stanislav Datskovskiy http://bvt-trace.net/2019/07/todo-items-and-work-plan-jul2019/#comment-22 Stanislav Datskovskiy Sat, 06 Jul 2019 21:38:54 +0000 http://bvt-trace.net/?p=41#comment-22 Re: 100% ASMistic FFA: FWIW I cannot currently think of any good reason to do this. Re: Firefly, I looked at this board in the past, rejected it on account of expense (it cost more than twice than the board I ended up using in the pilot plant.) Would still be interesting to read about it, however, if you tested it (would seem to me that my existing OS would run there without modification?) Re: FG-eating kernel: the principal difficulty is to ensure that no two processes can ever end up being fed the same sequence of FG outputs. IMHO a direly needed item, however. And one that I thought would surely end up on my own conveyor, AFAIK no one has taken it up yet, if you do it -- I promise to test and comment. Re: 100% ASMistic FFA: FWIW I cannot currently think of any good reason to do this.

Re: Firefly, I looked at this board in the past, rejected it on account of expense (it cost more than twice than the board I ended up using in the pilot plant.) Would still be interesting to read about it, however, if you tested it (would seem to me that my existing OS would run there without modification?)

Re: FG-eating kernel: the principal difficulty is to ensure that no two processes can ever end up being fed the same sequence of FG outputs. IMHO a direly needed item, however. And one that I thought would surely end up on my own conveyor, AFAIK no one has taken it up yet, if you do it -- I promise to test and comment.

]]> By: Mircea Popescu http://bvt-trace.net/2019/07/todo-items-and-work-plan-jul2019/#comment-21 Mircea Popescu Sat, 06 Jul 2019 16:37:18 +0000 http://bvt-trace.net/?p=41#comment-21 > I'd be hesitant to take up this project I don't think it's a priority atm, fwiw. > Ripping out kernel RNG This however is a major priority ; especially because it can turn the currently worked-upon cuntoo from a flavour project some group stylistically flavours to a must-have item with no possible competition in the professional (as opposed to toy&smartphone) IT space. > "buffered RNG is not useful RNG" rule This rule only applies to new development. When we write a kernel, we'll write it correctly, to treat entropy demands as events rather than whatever the fuck current haphazard nondesigned cOpS (coincidentally-operationg pseudo-system) do. Until then, simply filling the kernel entropy pools as they currently stand with FG-sourced noise rather than the current FtMeade sourced noise is good enough. That's your work-around right there. Point 3 is quite interesting as well. > For vtools, I have a candidate fix This should be released right now, I don't expect wrapping to take more than a few hours ? > Writeup about the firefly board Please. > avoiding gcc5 step in the cuntoo build process As you say, this should wait. > Testing the cuntoo-based TRB rotor This is liable to be both very intensive and also drive large changes downstream. I get that it appears sexy, but empty the pipe and clear your table before you start with this. Not like we have the spare hands to delve into build systems right this instant anyway. Cheers. > I'd be hesitant to take up this project

I don't think it's a priority atm, fwiw.

> Ripping out kernel RNG

This however is a major priority ; especially because it can turn the currently worked-upon cuntoo from a flavour project some group stylistically flavours to a must-have item with no possible competition in the professional (as opposed to toy&smartphone) IT space.

> "buffered RNG is not useful RNG" rule

This rule only applies to new development. When we write a kernel, we'll write it correctly, to treat entropy demands as events rather than whatever the fuck current haphazard nondesigned cOpS (coincidentally-operationg pseudo-system) do.

Until then, simply filling the kernel entropy pools as they currently stand with FG-sourced noise rather than the current FtMeade sourced noise is good enough.

That's your work-around right there.

Point 3 is quite interesting as well.

> For vtools, I have a candidate fix

This should be released right now, I don't expect wrapping to take more than a few hours ?

> Writeup about the firefly board

Please.

> avoiding gcc5 step in the cuntoo build process

As you say, this should wait.

> Testing the cuntoo-based TRB rotor

This is liable to be both very intensive and also drive large changes downstream. I get that it appears sexy, but empty the pipe and clear your table before you start with this. Not like we have the spare hands to delve into build systems right this instant anyway.

Cheers.

]]>