cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-rockchip
anarsoul has joined #linux-rockchip
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-rockchip
lkcl has quit [Ping timeout: 240 seconds]
VargaD has quit [Ping timeout: 255 seconds]
VargaD has joined #linux-rockchip
busterbcook has quit [Ping timeout: 276 seconds]
busterbcook has joined #linux-rockchip
<micken>
winlinux did the trick
sjg1_ has quit [Ping timeout: 256 seconds]
lvrp16 has quit [Ping timeout: 256 seconds]
sjg1_ has joined #linux-rockchip
lvrp16 has joined #linux-rockchip
<maz>
micken: what do you mean by "secure is optional"? All Cortex-A cores have secure, and reset in secure mode. it takes some active tinkering to switch to non-secure.
<micken>
maz: understood
<micken>
maz: Is there a relation between secure mode and secure grf?
<maz>
micken: I strongly suspect that the secure GRF is a secure device, hence only accessible from the secure side.
<micken>
ok
<micken>
maz: from what I can understand secure uses GROUP0 in GIC in GICD
<micken>
and there are some differences in how priority works
<maz>
micken: yes. you can basically device your priority space in two: group 0 interrupts must have prio[7] clear, and group 1 interrupts must have prio[7] set.
<maz>
s/device/divide/
<maz>
this ensures that a group 0 interrupt is always of higher priority than a group 1
<maz>
you must also configure the CPU interfaces (I assume you have a GIC400)
<maz>
otherwise, you'll never see a PPI.
BenG83_ has quit [Quit: Leaving]
<stdint>
except the rk3228, I am sure most of the rockchip products are not running under the secure zone
<wens>
arch/arm/cpu/armv7/nonsec_virt.S:_nonsec_init in u-boot pretty much handles the GIC stuff
<maz>
stdint: my veyron (3288) definitely runs secure.
<stdint>
I am not sure about chromebook, but I think most of the rockchip driver doesn't support TZ
<stdint>
and the devices under the TZ
lukasz has quit [Ping timeout: 264 seconds]
<maz>
stdint: that's a Linux issue. here, we're talking about a non-Linux OS that may or may not deal with booting from secure.
<stdint>
maz, I may miss something
<stdint>
actually the rk3288 don't boot from the secure zone, it doesn't support secure boot I think
matthias_bgg has joined #linux-rockchip
<micken>
Well, if that "handler" is installed I should be able to use it IF I am in secure mode, which I doubt somehow
<micken>
going to get some more sd-cards today
<micken>
I am going to trace this down
<maz>
stdint: you should really read the TRM (hint: I'm pretty well placed to know that A17 has a secure mode).
<stdint>
maz, I know I can put it into secure zone, but it is not the secure boot
<stdint>
the maskrom won't check the checksum of the bootloader
<maz>
stdint: secure boot is a software concept. we're talking about the HW here.
<stdint>
what I said is "it doesn't support secure boot I think"
<maz>
stdint: well, I misunderstood you then.
<stdint>
it is obvious that the rk3288 supports trustzone
<stdint>
from the rk32xx serial, I think all the rockchip's chips support trustzone
<maz>
stdint: you can go further than that. All ARM CPUs since ARM1176 do have a secure mode (and not trustzone, which is the name of a SW architecture).
<micken>
OK
<stdint>
trustzone actually is implementation by a hardware device
<stdint>
I am little confused, it looks the same thing as trustzone
<stdint>
and sgrf means it this grf is always a secure slave, in the future platform, even with the prefix s it is still the sgrf
<micken>
looks like the "bootm" command siwtches to non-secure
lukasz has joined #linux-rockchip
lkcl has joined #linux-rockchip
<vagrantc>
huh. cpufreq is working fine with 4.16-rc5 on a firefly-rk3399 , and on a different firefly-rk3399 one the fan53555 module crashes it almost as soon as it loads
<vagrantc>
i thought the only difference is the amount of physical ram on each board (the one that crashes is a 2GB variant, and the one that works is a 4GB variant) ... but the working one only sees 2GB of it's ram anyways
<vagrantc>
or just writing the write things to the right sectors should be enough?
<vagrantc>
the tools i can find to create a partition table don't even appear to handle things below sector 2048
<mmind00>
vagrantc: I think any partition table will only matter to actual loaders (binary or uboot), not the bootrom
<vagrantc>
that's what i figured
<vagrantc>
i've never managed to get this one firefly-rk3399 to boot with u-boot SPL + ATF
<vagrantc>
just grasping at straws to figure out what weird things might make it not work
<vagrantc>
i've got an old patched up u-boot working on microSD, but it has some curious quirks ... like after a reboot, i need to physically eject and re-insert the microsd or it just silently sits there ... even after a power cycle.
<vagrantc>
maybe there's some stray power through the serial console or something
<gab>
Hi, anyone here with rk3368 experience ?
<gab>
I'd like to know if this SoC's cores are true SMP or if these are big.LITTLE, and which top frequency does it reach
gnufan has quit [Ping timeout: 240 seconds]
gnufan has joined #linux-rockchip
BenG83_ has joined #linux-rockchip
VargaD has quit [Ping timeout: 240 seconds]
VargaD has joined #linux-rockchip
afaerber has joined #linux-rockchip
BenG83_ has quit [Remote host closed the connection]
BenG83_ has joined #linux-rockchip
nighty- has quit [Quit: Disappears in a puff of smoke]
BenG83_ has quit [Remote host closed the connection]
gnufan has quit [Ping timeout: 260 seconds]
BenG83_ has joined #linux-rockchip
gnufan has joined #linux-rockchip
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-rockchip
Pix has joined #linux-rockchip
nighty- has joined #linux-rockchip
cnxsoft has quit [Remote host closed the connection]
tlwoerner has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 264 seconds]
<micken>
HMm the non-sec siwthing in u-boot doesn't work on RK3288
<micken>
But the good news is that ethernet works in u-boot
tkaiser has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
<micken>
maz: stdint: In our i.MX6 port the devices are configured to be allowed to be accessed in a non-secure way
<micken>
Thats why it works there
BenG83_ has quit [Remote host closed the connection]
ayaka has joined #linux-rockchip
aleonard has joined #linux-rockchip
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-rockchip
<micken>
maz: I tried now to setup my own secure handler, in which I do the switch. It just halts at the write to p15
lesderid has quit [Quit: bai]
BenG83_ has joined #linux-rockchip
<maz>
micken: that's pretty vague. the cp15 space is fairly large, so you may want to elaborate a bit...
<micken>
alright
<micken>
just a sec
<micken>
back
<micken>
mcr p15, 0, r5, c1, c1, 0
<micken>
and r5 is
<micken>
the contents of cp15 and bic r5, r5, #0x4a orr r5, r5, #0x31
<micken>
maz: so NS bit is set IRQ away
<micken>
perhaps I just shoud deal with the NS bit
<maz>
have you transitioned to monitor mode before writing to SCR?
<micken>
yes
<micken>
I followed the u-boot way
<micken>
(not copy :9
<maz>
micken: well, the u-boot way is pretty reliable.
<micken>
ok .. need to add some debug around the SMC call
<micken>
It night be the monitor that goes into wrong ram
lesderid has joined #linux-rockchip
* vagrantc
tries mainline linux on the veyron-speedy again with about the same problems as ever
<vagrantc>
i'm starting to think i should just disable the eMMC in the .dts and see if that makes it more stable
<vagrantc>
although the usb is still quirky
<Pix>
i've stuck to 4.14 which is for me the more stable ( even if my USB3 drive is now seen as a 480Mpbs device, instead of a 5G one on the 4.4)
<vagrantc>
i had a small patch against 4.8 to the device-tree, but nothing since has ever worked for me
<vagrantc>
i should probably update the firmware or something
<vagrantc>
that's one thing that's stayed the same... an old build of libreboot
<micken>
maz: just figured out that the monitor is installed with mmu addresses (before mmu ofc) and I need to call smc after mmu is on. Now the MMU on fails...
<aalm>
you could map what you need VA=PA
<micken>
It looks like this: I have my kernel (the complete os) at the start of ram. The os image is fixed in virtual space and the monitor handler is installed pre mmu with address in that space
<micken>
and now the MMU on fails.
<aalm>
i would _not_ load the kernel at the beginning of RAM
<vagrantc>
beeble: just tried the usb power control and boot selection on the rk3399-q7 puma haikou (what is this thing actually called?)
<micken>
its not on 0
<micken>
its on 0x2000000
<aalm>
i suggest you start w/whatever defaults u-boot does provide, and have it working from there
<aalm>
ram doesn't start at 0, so that's not what i meant
<micken>
anyway it is the start address that u-boot suggests
<micken>
It works just fine or worked before I installed my smc monitor
BenG83_ has quit [Remote host closed the connection]
BenG83_ has joined #linux-rockchip
<micken>
TOP of physram is FF00_0000
<aalm>
so that's just the offset, actual address is something 0xXX200000
<micken>
below iospace,
<micken>
what?
<micken>
yes
<micken>
I am using all RAM above the OS
<aalm>
may i see the code?
<micken>
not the complete HAL, yet
<micken>
only local
<micken>
but you can see the MMU code and I can paste/give out the monitor stuff
aleonard has quit [Remote host closed the connection]
aleonard has joined #linux-rockchip
afaerber has quit [Quit: Leaving]
aleonard has quit [Quit: Leaving]
lkcl has joined #linux-rockchip
Easyfab has quit [Quit: Leaving]
anarsoul|2 has quit [Remote host closed the connection]
anarsoul|2 has joined #linux-rockchip
<micken>
Interesting , the write bit 0 in cp15 makes r14 go void
<micken>
maz: do you have a idea how I should return from my monitor? LR goes wrong after ns bit is set. If I push LR to stack make the write pull it back, it returns but bit 0 (ns) is not set
afaerber has joined #linux-rockchip
matthias_bgg has quit [Quit: Leaving]
LargePrime has quit [Read error: Connection reset by peer]
anarsoul|2 has quit [Remote host closed the connection]