ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
<psydroid>
Tenkawa, so you already used Unix before I was born. I want to learn more about Unix some day to get a bit more of a historical perspective on things
<Tenkawa>
psydroid: I was a HP-UX admin for years
<Tenkawa>
that was my favorite "Unix"
<Tenkawa>
SCO Unix, SunOS, Solaris I didn't really care for. IBM AIX was the last "commercial" one I used as a job.
<Tenkawa>
now I stick to Linux on embedded as a hobby and teaching it to people
<psydroid>
I got my Orange Pi Win Plus in 2017 and it was my first ARM SBC
<psydroid>
I always compare it to "My First Sony"
<Jmabsd>
psydroid,Tenkawa: you mean the A64 is nice in some sense but just too slow
<psydroid>
everything works on it these days, but I don't think it's great for running one of the common modern UNIX-like operating systems
<psydroid>
Jmabsd, yes
<Tenkawa>
Amlogic Rockchip, and although I hesitate to say them..BCM work.... Allwinner I can break easily
<Tenkawa>
Jmabsd: no... they are just inconsistent for me
<psydroid>
I do think you could get good performance out of it running a really lightweight optimised operating system, but that woul be more of a specialty system
<Tenkawa>
but that could be the supply chain problems
<psydroid>
Jmabsd, I would just focus on RK3588 for now
* Tenkawa
agrees with psydroid
<psydroid>
there is no need to focus on the past
<Tenkawa>
when that comes out... it "should" be a game changer
<Jmabsd>
Tenkawa: July.
<Jmabsd>
psydroid: It will take a year for RK3588 laptops to come
<Jmabsd>
i was thinking what is a non-Intel not 100% shit, tiny ARM laptop
<Jmabsd>
to run uni
<psydroid>
a new baseline of what is available in generic ARM hardware
<Jmabsd>
x
<psydroid>
Jmabsd, I just use this x86 laptop until something is released with RK3588
<Tenkawa>
this odroid-m1 is pretty nifty
<psydroid>
I'm installing Debian ARM64 in QEMU now to be able to do some assembly programming while my Orange Pi is offline
<Tenkawa>
psydroid: the joys of having a mac m1 muhaahaaahaaa
<psydroid>
I wasn't sold on Pinebook (Pro) so far
<robmur01>
on-topic-wise there's always Pinephone Pro as well. I like the NanoPi R2S for being the tiniest board that can still do enough to be useful
<psydroid>
Tenkawa, indeed, that's what I also told Jmabsd
<Tenkawa>
if you want a tiny arm box.. nanopi neo plus 2
<Tenkawa>
not a ton of power but novel box
<Tenkawa>
or the nanopi neo
<Jmabsd>
hmm
<Tenkawa>
I have the plus 2
<psydroid>
even if you hate Apple as a company and what they stand for, these first few generations of Apple Silicon (M1 and M2) will be hard to catch up with for the next year or two
<Tenkawa>
now I need to figure out what dtb might work to update this kernel from 4.x to 5
<psydroid>
Tenkawa, I have some old Powermacs and was never interested in their Intel hardware, even though I understand why they had to make that move when they did it
<psydroid>
I even ported some of my assembly code from x86_64 to ARM64 and from there to RISCV64 and PPC64/LE
<Tenkawa>
psydroid: heheh I still have powered off g5 50 lb tower up stairs too
<psydroid>
I just can't wrap my head around x86, it just feels alien to me
<Tenkawa>
I've used so many different architectures over the years it all feels innate to me
<psydroid>
yeah, it's heavy
<Tenkawa>
I knew microchannel inside and out
<Tenkawa>
token ring etc
<Tenkawa>
all that odd stuff
<psydroid>
I can never remember what those x86 register names mean, probably because I lack the historical context of what they were actually meant for
<psydroid>
you said HP-UX was your favourite UNIX
<psydroid>
was Solaris hyped up too much?
<Tenkawa>
Solaris is... ok
<Tenkawa>
its still around
<Tenkawa>
a new version was released a week or two ago
<mps>
solaris was always strange to me
<Tenkawa>
mps: exactly
camus has quit [Remote host closed the connection]
<psydroid>
and in terms of stability, reliability and scalability on PA-RISC/Itanium compared to Solaris on SPARC/Intel?
camus has joined #linux-rockchip
<Tenkawa>
PA-RISC was stable
<mps>
psydroid: only what I can say is that the old machine were more reliable than nowadays machines
<Tenkawa>
Itanium was junk
<psydroid>
mps, I had to deal with some of these machines at work for running Oracle and my company's middleware on them, but never really did anything with the hardware and operating systems themselves
<psydroid>
I just know I had to help a customer with AIX and its shell was so broken that I had to walk them through copying and pasting each line from a shell script one by one, because it just wouldn't work the same as RHEL on POWER
<Tenkawa>
haahaa'
* Tenkawa
has had to work on all of the above
<mps>
so I had a luck to never work with AIX
<Tenkawa>
AIX actually isn't bad
<Tenkawa>
now Ultrix and VMS.... those were rough
matthias_bgg has quit [Read error: Connection reset by peer]
<psydroid>
yes, it was probably more the case that the person had no clue how to use a shell other than the default one for interactive purposes
<psydroid>
sometimes developers are made to work on machines they don't actually understand
camus has quit [Quit: camus]
<Tenkawa>
and people forget... developers != admins != endusers
<Tenkawa>
so the tools never match up
<Tenkawa>
very few especially now more than ever had to do the "wear all hats role" as I did most of my career
<Tenkawa>
so you design things for a very isolated area. Its just the way it is.
<psydroid>
I can see that, yeah
matthias_bgg has joined #linux-rockchip
<macc24>
would it be possible to have TPL or SPL soc agnostic as long as it's something rockchip?
<Tenkawa>
yeah then I'd be optimistic.. it would probably need some experimenting
<Tenkawa>
ouch
<Jmabsd>
Tenkawa: The Pinephone Pro's boot order should be, uh, the RK3399's UBoot will take eMMC boot first
<Tenkawa>
thats backwards from normal
<Jmabsd>
and then, are you saying that uBoot supposedly boots syslinux/extlinux?
camus has joined #linux-rockchip
<Tenkawa>
usually (and dont quote my not so great memory) the microsd should boot before the emmc if found
<Jmabsd>
wait
<Jmabsd>
"The SPI flash and the eMMC chip can be bypassed during boot by temporarily disabling them at the hardware level using the following method, which can be used in cases such as having corrupted installation on the SPI flash or the eMMC:
<Jmabsd>
On the Explorer Edition hold the RE button underneath the cover for a few seconds, while powering on the device."
<Jmabsd>
Tenkawa: look at that statement in the wiki. So, you boot off the MicroSD simply by pushing a particular button at boot. Yey! ?
<psydroid>
Jmabsd, if you want to experiment, it's better to use the microsd card to be able to easily switch operating systems
<Tenkawa>
yep
<Tenkawa>
microsd is always better for experimenting
<Jmabsd>
psydroid: totally agreed.
<psydroid>
if I was interested in running OpenBSD and Linux on the device permanently, I would just get another identical phone
<Jmabsd>
okay this is quite stellar. so the Linux is known to work. the OpenBSD *may* work
<Jmabsd>
quite "sexy" this
<psydroid>
that's actually what I'm thinking of doing with a new SBC
<psydroid>
I would get a few identical ones to be able to run various operating systems on them on a permanent basis
<Jmabsd>
okay stellar. among RK3399 computers actually this PinePhone Pro is the most "carryable".
<psydroid>
many people mistakenly believed early ARM devices were meant for end users, but I would say they were strictly for developers
<psydroid>
and now we're finally seeing devices that should be usable by end users
<psydroid>
or they were using the wrong approach to doing things like trying to watch youtube videos in Firefox instead of using dedicated applications for that, which perform decently
vagrantc has joined #linux-rockchip
<robmur01>
macc24: in short, no.
<macc24>
robmur01: is there no identifier in soc itself? no random efuse? no register? no otp memory?
<robmur01>
TPL is only even a thing because SoC-specific SPL code got too big to fit in SRAM
<robmur01>
where ya gonna load all the code for *all* the different memory controllers and DRAM configurations at once?
<macc24>
robmur01: is boot device memory mapped?
<robmur01>
If you mean for SPI NOR, I'm not aware that anything supports that. But most typical RK devices boot from SD card or eMMC anyway
<Jmabsd>
wait can you remind, on the RK3399[S] is there flashable boot software aside from eMMC/SPI/microSD actually????
<Jmabsd>
Say the Linux wants to install a stealth virus on the RK3399. Can it?
<Jmabsd>
that withstands wiping the eMMC; that would also infect the RK3399 on microSD boot
<phh>
let's say no
<Jmabsd>
psydroid,Tenkawa,robmur01: what do you say =)
<Jmabsd>
wow.
<phh>
(bootrom might be patchable through OTP, but that's quite unlikely, and I'm pretty sure noone knows how to do that)
<Jmabsd>
wait remind OTP is short for what
<phh>
One-Time Programmable
<Jmabsd>
ahh.
<phh>
it's an area of the SoC you can write to, to setup stuff, like secure boot keys
<macc24>
robmur01: i've seen rk3326 boot from spi nor :v
<Jmabsd>
One quirk with the PinePhone Pro may be that when you boot off the microSD card, then the computer cannot access the eMMC at all
<macc24>
and i meant sd card
<Jmabsd>
so there could be a thinkable issue that the eMMC would catch a virus and you wouldn't notice - but at least when you boot off microSD the computer is clean.
<robmur01>
macc24: well yeah, the boot ROM knows where its SoC's SPI controller is, and can use its data transfer registers just fine
<robmur01>
Jmabsd: that would be pretty useless for system recovery, and is certainly not the case for any systems I know of. Sure, I *can* hold down the button to disable the eMMC clock pin all the way through the entire boot process, until Linux's MMC driver also fails to detect a card present and gives up, but if I do, I've only myself to blame
<phh>
speaking of malware prevention, can PPP's SPI storage be put into read-only?
<phh>
chromebook-like
<robmur01>
phh: looking at the schematic, it doesn't seem so
<Jmabsd>
the PinePhone Pro would be even more kickass with a real NVMe SSD
<Jmabsd>
eMMC is a SD memory card bus is it, that is so archiaic
<vagrantc>
it's a balance between power consumption and performance
<phh>
smartphones use UFS rather than NVMe for high-performance storage, but sadly rk3399 doesn't have that
<phh>
(nor does the rk3588 btw)
<Jmabsd>
Uhh guys, if boot off the PinePhone Pro's eMMC gets trashed, how do you fix it
<Jmabsd>
Except for throwing the PinePhone and buying a new one
<Jmabsd>
phh: UFS is SATA.
<Jmabsd>
not so fast. RK3399 has PCIe. fast!
<macc24>
Jmabsd: insert sd card with u-boot and it will work
<macc24>
if not, flash the spi flash chip with u-boot
<macc24>
if not, use rockusb
<Jmabsd>
macc24: Pine's wiki says when you are in the microSD boot mode, the OS *CANNOT* access the eMMC's contents !?
<Jmabsd>
macc24: how do you boot via rockusb mode on PinePhone Pro?
* macc24
shrugs
<Jmabsd>
macc24: oh, the OS *CAN* access the eMMC????
<Jmabsd>
really
<Jmabsd>
that's wow!
<macc24>
why would it be
<macc24>
it's just an internface
<macc24>
interface*
<Jmabsd>
I would be interested to find a special USB-C cable which will split the one connector into: 1x displayport, 1x USB3 for peripherals, and 1x USBC connector for power delivery charging. does it exist =) I should ask #hardware
<Jmabsd>
macc24: getting the URL for you, sec
<Jmabsd>
macc24: getting the URL for you, sec
<macc24>
no need to say it twice
<macc24>
no need to say it twice
<Jmabsd>
macc24: https://wiki.pine64.org/wiki/PinePhone_Pro#Boot_order aaaa i misread! "Note: When holding the RE button (or when shorting the contact points in case of the Developer Edition) for a longer time at boot the operating system will not initialize the SPI and eMMC and it will not be possible to write to these storage mediums until the next reboot. "
<Jmabsd>
apologies my own typing error
<Jmabsd>
macc24: rightright you are so right - the OS *WILL* have access, unless you push "very long" whatever that means
<Jmabsd>
Is that PCIe occupied with anything??? hummm
Rathann has quit [Ping timeout: 240 seconds]
<Jmabsd>
if there'd be some way to be able to connect an M.2 NVMe SSD to that PCIe would be something he he. 500MB/sec and excellent latency afterall :)
<Jmabsd>
jakllsch,*: do you have the skill to see the RK3399S's pinouts on the schematics, https://wiki.pine64.org/wiki/PinePhone_Pro#Datasheets,_schematics_and_certifications , do you have ability to tell where the PCIe is going
robmur01 has quit [Quit: Leaving]
<Jmabsd>
Ohh guys, the RK3399 it actually only has 2x A72 cores???
<Jmabsd>
RK3588 has proper 4x A76 (+ 4x A55 like RK3399
<Jmabsd>
)
robmur01 has joined #linux-rockchip
<Jmabsd>
marcin at the Matrix group has thoughts about where the PCIe connectors go
<psydroid2>
yes, I was never that interested in RK3399
<psydroid2>
RK3588 was supposed to come out 2 years ago
<Jmabsd>
he refers to "dsimic" (there too)
<Jmabsd>
anyhow a mod of the PinePhone Pro to expose the PCI to connect to M.2 would be too deep. it would not be worth it.
<robmur01>
also being able to accommodate a 2280 SSD to make your phone nearly twice as big and able to drain the battery in an hour or so doesn't seem like a feature with a great return on investment...
<Tenkawa>
awww... people use to carry backpacks connected to their phones... lol
<Tenkawa>
and still got about as much battery life
lurchi__ is now known as lurchi_
<macc24>
is there any upstreaming effort for pinephone pro and rk3399s?
<robmur01>
I thought RK3399S was basically just a binned RK3399, where presumably the "S" stands for "slow" :D
<macc24>
yeah
<macc24>
i wonder if anyone is interested in upstreaming pinephone pro stuff
lurchi_ is now known as lurchi__
<robmur01>
hmm, I seem to be getting a WARN() from DRM via the analogix_dp driver, apparently thanks to having a panel-rotation property set... that's nice :/
<robmur01>
don't suppose anyone else uses eDP on RK3399 with a rotated panel?
* macc24
stares at robmur01 with MIPI-DSI look of superiority