ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
Pali has quit [Ping timeout: 240 seconds]
prabhakarlad has quit [Quit: Client closed]
djrscally has quit [Quit: Konversation terminated!]
iivanov has joined #armlinux
iivanov has quit [Ping timeout: 240 seconds]
apritzel_ has quit [Ping timeout: 244 seconds]
Tokamak has quit [Read error: Connection reset by peer]
sakman has quit [*.net *.split]
abelvesa has quit [*.net *.split]
ardb has quit [*.net *.split]
neocow has quit [*.net *.split]
netonaut_ has quit [*.net *.split]
wolfshappen has quit [*.net *.split]
netonaut_ has joined #armlinux
ardb has joined #armlinux
sakman has joined #armlinux
neocow has joined #armlinux
wolfshappen has joined #armlinux
abelvesa has joined #armlinux
wolfshappen has quit [Max SendQ exceeded]
wolfshappen has joined #armlinux
Tokamak has joined #armlinux
ravan has quit [Quit: Leaving]
CrashTestDummy2 has joined #armlinux
CrashTestDummy has quit [Ping timeout: 260 seconds]
apritzel_ has joined #armlinux
guillaume_g has joined #armlinux
apritzel_ has quit [Ping timeout: 250 seconds]
iivanov has joined #armlinux
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
iivanov has quit [Client Quit]
iivanov has joined #armlinux
CrashTestDummy2 has quit [Read error: Connection reset by peer]
guillaume_g has quit [Quit: Konversation terminated!]
Amit_T has quit [Ping timeout: 246 seconds]
kristo has quit [Ping timeout: 268 seconds]
headless has joined #armlinux
kristo has joined #armlinux
Amit_T has joined #armlinux
tudorel has quit [Quit: tudorel]
alexels has joined #armlinux
alexels has quit [Quit: WeeChat 3.3]
torez has quit [Ping timeout: 250 seconds]
sikkiladho has joined #armlinux
<sikkiladho>
Can we ask questions about armv8 assembly here?
Pali has joined #armlinux
<maz>
why not?
<sikkiladho>
Thank you. how can one move a value like 0x200000 into a 64-bit register? Since, mov and movz can only move 16-bit values.
<sikkiladho>
mov x4, #0x0000
<sikkiladho>
movk x4, #0x20, lsl #16
<sikkiladho>
is this the right wayy?
<maz>
no, you should be able to do 'mov x0, #0x20000'. but you can't do it for arbitrary values.
<maz>
mov (and other instructions sharing a similar encoding) are able to encode a bit pattern.
<geertu>
$ cat a.c
<geertu>
unsigned long long f(void)
<geertu>
}
<geertu>
{ return 0x200000;
<geertu>
aarch64-linux-gnu-gcc -S a.c
<geertu>
cat a.s
<geertu>
movx0, 2097152
<sikkiladho>
Thank you.
<HdkR>
You could also just `movz x4, #0x20, lsl #16` Since it'll zero the rest of the register :P
<sikkiladho>
Yeah, but it's unnecessary step, I get it now.
<sikkiladho>
Actually, I'm trying to write a simple hypervisor at el2 on raspberry pi 4. The hypervisor just prints Hello World to the UART. I have been able to do this. Now I want the standard kernel to run after the hypervisor at el1.
<maz>
for details of how values are encoded, see aarch64_encode_immediate(). I'll never do that again.
torez has joined #armlinux
luispm has joined #armlinux
<sikkiladho>
continuing the question, therefore, I loaded the hypervisor at the place of kernel(kernel=el2-kernel.img) and loaded the standard arm64 kernel for rpi4 at 0x200000 using initrams. Since kernel needs the device tree blob, I load it at 0x200000 - size of the dtb file using initramfs. Inside the hypervisor, I eret to 0x200000 and jump to el1.
<sikkiladho>
I don't see anything after the Hello World, which means standard kernel is not able to run.
<j`ey>
SikkiLadho: but you dont set x0 to the address of the dtb
<sikkiladho>
Thank you. So no matter where the dtb is stored. I should only set x0 to the address of dtb, right?
<j`ey>
SikkiLadho: yep, that's what the booting.rst document says
<sikkiladho>
and changing exception levels doesn't change the generel purpose values.
<sikkiladho>
j`ey, thank you. I wil read it again and search if I don't understand anything. Thank you, you have been a lot helpful.
<javierm>
broonie, ukleinek: just noticed your discussion from the other day about commit 6840615f85f6 ("spi: spidev: Add SPI ID table") and compatible = "spidev" not working anymore
<javierm>
broonie, ukleinek: my take on this is that we should add a "spidev" entry to the spi_device_id table
<ukleinek>
IMHO we shouldn't
<javierm>
ukleinek: but then is a regression since newer kernels will break older DTBs that used to work
<ukleinek>
it used to work with a big fat warning that there is a problem
<javierm>
ukleinek: yeah but I thought that DT was considered an ABI. Then in that case probably the warning should make and error and spidev_probe() return -EINVAL or something
<javierm>
there's no point to continue if is going to fail anyways
apritzel has quit [Ping timeout: 256 seconds]
<ukleinek>
javierm: anyhow, feel free to send a patch. I won't oppose but wouldn't be surprised if broonie does.
<javierm>
ukleinek: I never bought on the DT is stable argument anyways, so I'm OK with breaking this :)
<javierm>
I do think that we should make it more visible that's an error now and return early. I'll post a patch for that if broonie agrees
<broonie>
Anyone using spidev in their DT like that clearly didn't buy the DT as a stable description of hardware either.
<javierm>
broonie: that's a good point
<broonie>
javierm: I'm more likely to have an opinion on a patch I've seen :P
<javierm>
broonie: Ok, I'll post then :)
<j`ey>
im confused by 6840615f85f6 / 5fa6863ba69, does it mean that you need to put the devices you expect the spi to be used with in the spi driver?
<j`ey>
(related to the spi_device_id thing)
<j`ey>
(Im getting the 'SPI driver %s has no spi_device_id for..' warning)
<broonie>
It means you should always have a spi_device_id table as well even if you're actually binding with DT in practice.
<j`ey>
must be something Im not understanding, I thought the spi drivers wouldnt care about whats connected on the other end
<javierm>
j`ey: tl;dr DT should describe the hardware topology and spidev is a linux implementation detail
<broonie>
This is for the device drivers, not the controller drivers.
<broonie>
Controller drivers don't see any of this, the drivers are loaded and bound by the SPI core and general driver/module infrastructure.
<j`ey>
broonie: are drivers in drivers/spi all controller drivers?
<broonie>
yes
<j`ey>
so the warning is actually coming from the driver that uses the spi interface?
<broonie>
Yes.
<j`ey>
that makes a lot more sense, thanks!
dianders has joined #armlinux
luispm has quit [Ping timeout: 250 seconds]
luispm has joined #armlinux
headless has quit [Quit: Konversation terminated!]
ravan_ has joined #armlinux
sudeepholla has joined #armlinux
ravan has quit [Ping timeout: 240 seconds]
SikkiLadho21 has joined #armlinux
sikkiladho has quit [Ping timeout: 250 seconds]
CrashTestDummy3 has joined #armlinux
ravan__ has joined #armlinux
sikkiladho has joined #armlinux
ravan__ is now known as ravan
Misotaur- has joined #armlinux
Emantor_ has joined #armlinux
sboyd_ has joined #armlinux
mcfrd has joined #armlinux
SikkiLadho21 has quit [Ping timeout: 246 seconds]
<sikkiladho>
j`ey, in /Documentation/arm64/booting.rst, there is a is list of conditions which should be met before jumping into the kernel. setting x0 with dtb address is just one. I understand this is a list for all arm boards, should I have to make sure of all these conditions for raspberry pi 4, too?
apritzel_ has joined #armlinux
<j`ey>
SikkiLadho: yes
ravan_ has quit [*.net *.split]
matthias_bgg has quit [*.net *.split]
djrscally has quit [*.net *.split]
CrashTestDummy2 has quit [*.net *.split]
mcfrdy has quit [*.net *.split]
sboyd has quit [*.net *.split]
Misotauros has quit [*.net *.split]
russ has quit [*.net *.split]
Emantor has quit [*.net *.split]
mcfrd is now known as mcfrdy
sboyd_ is now known as sboyd
djrscally has joined #armlinux
<sikkiladho>
j`ey, this would be really tedious task, is there any open source code which has done something similar, I will try to study the code.
<j`ey>
SikkiLadho: dunno, it's not that bad, mostly just 2mb alignment of the kernel and dtb in x0
apritzel_ is now known as apritzel
russ has joined #armlinux
matthias_bgg has joined #armlinux
<sikkiladho>
But there also conditions to quiet the DMA capable devices, disbaling MMU, timers, coherency and system registers.
<apritzel>
SikkiLadho: which hopefully the boot loader has already done for you before loading your hypervisor
<apritzel>
the easiest is to add a kernel header to your hypervisor and sell your HV as a Linux kernel
matthias_bgg has quit [Quit: Leaving]
<sikkiladho>
apritzel , which kernel header should I add?
<j`ey>
apritzel: they want to load the kernel after their hypervisor is loaded
<apritzel>
yes, but the HV is super minimal, so the bootloader can satisfy all the kernel boot protocol requirements, and they just drop into EL1
<sikkiladho>
This might seem a silly question, but I'm a beginner please bear with me. How can add that 64-byte header? Should I just a struct in a header file and include it in m hypervisor? like in /arch/riscv/include/asm/image.h
<apritzel>
SikkiLadho: just smear it into your boot.S file ;-)
<apritzel>
SikkiLadho: and do not touch at least x0 initially, since this gives you the DT address, from the bootloader
<sikkiladho>
apritzel boot.S file contains assembly instructions. So I ust declare these varables inside the boot.S file?
<apritzel>
SikkiLadho: see the Xen example above
<apritzel>
just have a simple "b start" at the beginning, to jump over the header to your actual entry point, instead of the MZ trick for EFI, like in Xen or Linux do
Amit_T has quit [Ping timeout: 264 seconds]
SikkiLadho28 has joined #armlinux
sikkiladho has quit [Ping timeout: 246 seconds]
<SikkiLadho28>
apritzel I just smeared the header in boots.S and jumped over the header to my actual entry point. Here's the commit:https://github.com/SikkiLadho/Leo/commit/61fb380e1eb07305c0bb92c2663261b0bf9e807f
<SikkiLadho28>
Now, I need to set the x0 with dtb address and then eret to el1 at the kernel load address
<apritzel>
SikkiLadho28: you could just *keep* x0
<apritzel>
as this is where the RPi firmware puts the DT address already
<apritzel>
and just use "b" instead of "bl"
<apritzel>
also put something into the size field, just some upper boundary for your HV
<SikkiLadho28>
Thank you, I will changed b to bl and I will also just not mess with x0.
<SikkiLadho28>
the size field can also be the size of the HV image?
<apritzel>
then you can pick up the DT address in C, by using the first argument to your kernel_main()
<apritzel>
SikkiLadho28: yes, but it's not really critical, just put 64K or so in there
<apritzel>
void kernel_main(unsigned long dt_address)
<SikkiLadho28>
but it won't already be in x0?
<j`ey>
SikkiLadho28: it wont stay there
<j`ey>
since youre calling other functions
<SikkiLadho28>
yeaah, so i will keep it in the dt_address variable and mov it to x0 just before eret?
<j`ey>
make it: jump(dt_adddress); then the C compiler will move it to x0
<SikkiLadho28>
thank you. when I eret to el1, x0 should have the dt address.
<SikkiLadho28>
I will work on it right now and see what happens.
SikkiLadho28 has quit [Quit: Ping timeout (120 seconds)]
<sikkiladho>
Only difference is that, now I see Hello World printed to UART two times.
<apritzel>
but you still clobber x0 in boot.S, don't you?
<apritzel>
just use x4 and x5 there
<sikkiladho>
I pereseved x0 in x5 at the start and then moved it back to x0 ust before eret. Won't that be enough?
<sikkiladho>
got you
<sikkiladho>
boot.S
<sikkiladho>
let me try again.
<apritzel>
yeah, util.S looks alright in this respect
alpernebbi has quit [Ping timeout: 268 seconds]
alpernebbi has joined #armlinux
djrscally has quit [Quit: Konversation terminated!]
djrscally has joined #armlinux
Turingtoast has joined #armlinux
iivanov has quit [Remote host closed the connection]
<sikkiladho>
apritzel instead of replacing x0 with x5, I can also mov preserve x0 into x5 and when call kernel_main, I will move x5 back into x0. That should work.
<apritzel>
SikkiLadho: but why? you don't have register pressure in boot.S, so just use some "higher" registers
<sikkiladho>
It seemed easier, but I will now just replace x0 with higher registers.
iivanov has joined #armlinux
iivanov has quit [Ping timeout: 240 seconds]
Pali has quit [Ping timeout: 246 seconds]
<sikkiladho>
Hi, I have noticed one difference. Since I have TF-A which prints entry address. Now it prints entry address for HV as 0x200000, which it only did for standard kernel before. We have sold our HV as the kernel.
<sikkiladho>
Therefore, I changed the load address for standard kernel(el1-kernel.img) to 0x400000 and changed elr before eret to 0x400000 as well. But after printing Hello World, it is stuck and rpi4 doesn't blink the green led.