Hello everyone,
I am having trouble getting the network to work on L4Linux running on the zedboard. I have enabled the macb driver which my net card needs, I have created a device tree telling l4linux where to find the device and I have written the io configuration.
The problem is that L4linux doesn't have access to the 3 clocks it needs for the network device to work. Those are "pclk", "hclk", "tx_clk". I understand that I have to assign those clocks to l4linux. But how can I do that? I cannot find any examples of assigning clocks. Won't this create an issue to the Fiasco kernel? Should the driver use "l4kipclk" instead of "pclk"?
Below you will find the dmesg output, my io files, my cfg file and the device tree.
Thank you for your time and help! Manolis
----dmesg output part begin---- __l4x_ioremap: Mapping physaddr e000b000 [0x1000 Bytes, e000b000+001000] to 00002000+000000 /amba/ethernet@e000b000: could not find phandle ERROR: could not get clock /amba/ethernet@e000b000:pclk(0) macb e000b000.ethernet: failed to get macb_clk (4294967294) macb: probe of e000b000.ethernet failed with error -2 ----dmesg output part end----
---- zynq.dts begin ---- { model = "L4Linux (DT)"; compatible = "L4Linux";
#address-cells = <1>; #size-cells = <1>; chosen { }; aliases { };
amba { compatible = "simple-bus"; #address-cells = <0x1>; #size-cells = <0x1>; interrupt-parent = <0x3>; ranges;
ethernet@e000b000 { compatible = "cdns,zynq-gem", "cdns,gem", "cdns,macb"; reg = <0xe000b000 0x1000>; status = "okay"; interrupts = <0x0 0x16 0x4>; clocks = <0x1 0x1e 0x1 0x1e 0x1 0xd>; clock-names = "pclk", "hclk", "tx_clk"; #address-cells = <0x1>; #size-cells = <0x0>; phy-mode = "rgmii-id"; phy-handle = <0x4>;
ethernet-phy@0 { reg = <0x0>; linux,phandle = <0x4>; phandle = <0x4>; }; }; }; }; ---- zynq.dts end ----
---- zedboard.devs begin ---- local Res = Io.Res local Hw = Io.Hw
Io.hw_add_devices(function() NIC = Hw.Device(function() compatible = {"cdns,zynq-gem", "cdns,gem", "cdns,macb"}; Property.hid = "cdns,zynq-gem"; Property.flags = Io.Hw_device_DF_dma_supported; Resource.irq = Io.Res.irq(54); Resource.mem = Res.mmio(0xe000b000, 0xe000bfff); end); end); ---- zedboard.devs end ----
---- hw_devices.io begin ----
local Hw = Io.system_bus()
Io.add_vbus("l4linux", Io.Vi.System_bus { ethernet = wrap(Hw.NIC); })
---- hw_devices.io end ----
---- l4lx.cfg begin ---- local L4 = require("L4");
local loader = L4.default_loader;
local lxname = "vmlinuz";
-- Start io
vbus_l4linux = loader:new_channel(); local vbus_input = loader:new_channel();
loader:start( { caps = { sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0); icu = L4.Env.icu; input = vbus_input:svr(); l4linux = vbus_l4linux:svr(); }, log = { "IO", "y" }, l4re_dbg = L4.Dbg.Warn, }, "rom/io rom/zedboard.devs rom/hw_devices.io");
L4.default_loader:start( { caps = { vbus = vbus_l4linux; }, l4re_dbg = L4.Dbg.Warn, log = L4.Env.log:m("rws"), },
"rom/vmlinuz mem=312M console=ttyLv0 " .. "l4x_dtb=rom/zynq-zed.dtb " .. "l4x_rd=rom/ramdisk-" .. L4.Info.arch() .. ".rd " .. "root=1:0 ramdisk_size=5000");
---- l4lx.cfg end ----
Hi,
On Fri Sep 22, 2017 at 17:05:58 +0300, Manolis Ragkousis wrote:
Hello everyone,
I am having trouble getting the network to work on L4Linux running on the zedboard. I have enabled the macb driver which my net card needs, I have created a device tree telling l4linux where to find the device and I have written the io configuration.
The problem is that L4linux doesn't have access to the 3 clocks it needs for the network device to work. Those are "pclk", "hclk", "tx_clk". I understand that I have to assign those clocks to l4linux. But how can I do that? I cannot find any examples of assigning clocks. Won't this create an issue to the Fiasco kernel? Should the driver use "l4kipclk" instead of "pclk"?
Those clocks are part of a clock device that has mmio registers just as the network device. So you need to give access to those so that it can set the clocks as needed. Another trick might be to let u-boot initialize the network, and thus the clocks, so that they still work when L4 has been booted. Do you boot other network in u-boot?
Adam
Below you will find the dmesg output, my io files, my cfg file and the device tree.
Thank you for your time and help! Manolis
----dmesg output part begin---- __l4x_ioremap: Mapping physaddr e000b000 [0x1000 Bytes, e000b000+001000] to 00002000+000000 /amba/ethernet@e000b000: could not find phandle ERROR: could not get clock /amba/ethernet@e000b000:pclk(0) macb e000b000.ethernet: failed to get macb_clk (4294967294) macb: probe of e000b000.ethernet failed with error -2 ----dmesg output part end----
---- zynq.dts begin ---- { model = "L4Linux (DT)"; compatible = "L4Linux";
#address-cells = <1>; #size-cells = <1>; chosen { }; aliases { };
amba { compatible = "simple-bus"; #address-cells = <0x1>; #size-cells = <0x1>; interrupt-parent = <0x3>; ranges;
ethernet@e000b000 { compatible = "cdns,zynq-gem", "cdns,gem", "cdns,macb"; reg = <0xe000b000 0x1000>; status = "okay"; interrupts = <0x0 0x16 0x4>; clocks = <0x1 0x1e 0x1 0x1e 0x1 0xd>; clock-names = "pclk", "hclk", "tx_clk"; #address-cells = <0x1>; #size-cells = <0x0>; phy-mode = "rgmii-id"; phy-handle = <0x4>; ethernet-phy@0 { reg = <0x0>; linux,phandle = <0x4>; phandle = <0x4>; }; };}; }; ---- zynq.dts end ----
---- zedboard.devs begin ---- local Res = Io.Res local Hw = Io.Hw
Io.hw_add_devices(function() NIC = Hw.Device(function() compatible = {"cdns,zynq-gem", "cdns,gem", "cdns,macb"}; Property.hid = "cdns,zynq-gem"; Property.flags = Io.Hw_device_DF_dma_supported; Resource.irq = Io.Res.irq(54); Resource.mem = Res.mmio(0xe000b000, 0xe000bfff); end); end); ---- zedboard.devs end ----
---- hw_devices.io begin ----
local Hw = Io.system_bus()
Io.add_vbus("l4linux", Io.Vi.System_bus { ethernet = wrap(Hw.NIC); })
---- hw_devices.io end ----
---- l4lx.cfg begin ---- local L4 = require("L4");
local loader = L4.default_loader;
local lxname = "vmlinuz";
-- Start io
vbus_l4linux = loader:new_channel(); local vbus_input = loader:new_channel();
loader:start( { caps = { sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0); icu = L4.Env.icu; input = vbus_input:svr(); l4linux = vbus_l4linux:svr(); }, log = { "IO", "y" }, l4re_dbg = L4.Dbg.Warn, }, "rom/io rom/zedboard.devs rom/hw_devices.io");
L4.default_loader:start( { caps = { vbus = vbus_l4linux; }, l4re_dbg = L4.Dbg.Warn, log = L4.Env.log:m("rws"), },
"rom/vmlinuz mem=312M console=ttyLv0 " .. "l4x_dtb=rom/zynq-zed.dtb " .. "l4x_rd=rom/ramdisk-" .. L4.Info.arch() .. ".rd " .. "root=1:0 ramdisk_size=5000");---- l4lx.cfg end ----
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hello Adam,
On 10/05/2017 01:25 AM, Adam Lackorzynski wrote:
Those clocks are part of a clock device that has mmio registers just as the network device. So you need to give access to those so that it can set the clocks as needed. Another trick might be to let u-boot initialize the network, and thus the clocks, so that they still work when L4 has been booted. Do you boot other network in u-boot?
I followed you advice and managed to fix everything and l4linux now has access to both the network and the sd cards.
What took me time to understand is that access to all the clocks in zynq is controlled from the zynq-slcr. I first needed to add that mmio registers to the l4linux vbus. Next I ported the driver from the normal arm linux arch to the l4 arch and made sure it was properly initialized.
Then I just needed to modify the clkc driver to work under l4linux and only enable the clocks for the peripherals I needed. With all this done the drivers for each device work as is.
All my work can be found in https://gitlab.com/l4-fiasco-thesis/l4-linux and https://gitlab.com/l4-fiasco-thesis/l4
Everything I changed is specific to L4_PLATFORM_ZYNQ, the new config option I created. In the future I will move the whole Zynq slcr initialization out of l4linux and in l4, so the l4linux kernel will not control devices it shouldn't.
If anyone has any question on the how and why please ask :).
Finally I have a question, Are you accepting patches for L4 and L4Linux? I could make my git patches more presentable and send them here if you want, to be added to your upstream repo.
Thank you for your help!! Manolis
On Wednesday 11. October 2017 15.33.58 Manolis Ragkousis wrote:
Finally I have a question, Are you accepting patches for L4 and L4Linux? I could make my git patches more presentable and send them here if you want, to be added to your upstream repo.
I would be interested to know about this as well. I sent some patches to the list a while back, but nothing was really said about whether there was any interest in incorporating them upstream.
One of the patches made the stated CI20 support actually work, thanks to Sarah's guidance, so it must surely be of interest to more than just me. The other patches attempted to support gcc instead of the vendor compiler, which I would also think would be desirable (especially given the corporate "pass the parcel" game going on with the vendor in question at the moment).
Paul
On Sat Oct 14, 2017 at 17:09:46 +0200, Paul Boddie wrote:
On Wednesday 11. October 2017 15.33.58 Manolis Ragkousis wrote:
Finally I have a question, Are you accepting patches for L4 and L4Linux? I could make my git patches more presentable and send them here if you want, to be added to your upstream repo.
I would be interested to know about this as well. I sent some patches to the list a while back, but nothing was really said about whether there was any interest in incorporating them upstream.
Principally yes but this also depends on time etc., see other mail.
One of the patches made the stated CI20 support actually work, thanks to Sarah's guidance, so it must surely be of interest to more than just me. The
You're talking about the cache instruction issue?
other patches attempted to support gcc instead of the vendor compiler, which I would also think would be desirable (especially given the corporate "pass the parcel" game going on with the vendor in question at the moment).
Well, then lets discuss those changes.
Adam
On Monday 16. October 2017 00.48.38 Adam Lackorzynski wrote:
On Sat Oct 14, 2017 at 17:09:46 +0200, Paul Boddie wrote:
On Wednesday 11. October 2017 15.33.58 Manolis Ragkousis wrote:
Finally I have a question, Are you accepting patches for L4 and L4Linux? I could make my git patches more presentable and send them here if you want, to be added to your upstream repo.
I would be interested to know about this as well. I sent some patches to the list a while back, but nothing was really said about whether there was any interest in incorporating them upstream.
Principally yes but this also depends on time etc., see other mail.
Yes, from my own perspective I understand this well. :-)
One of the patches made the stated CI20 support actually work, thanks to Sarah's guidance, so it must surely be of interest to more than just me. The
You're talking about the cache instruction issue?
Yes (ci20-rdhwr.diff). I was also potentially interested in supporting other instructions that related SoCs do not support, at least where those do not support floating point instructions natively, and where L4Re/Fiasco.OC might not be buildable using "soft float" instructions (advice welcome!), but this is a different topic altogether (and one that I am not likely to explore in the near future).
other patches attempted to support gcc instead of the vendor compiler, which I would also think would be desirable (especially given the corporate "pass the parcel" game going on with the vendor in question at the moment).
Well, then lets discuss those changes.
Thinking back, there was some uncertainty about whether it was appropriate to generate position-independent code when building Fiasco.OC, where I had introduced initialisation of t9 so that global offset table lookups functioned correctly (ci20-gcc-cpload.diff). There was also a trivial patch changing the compiler prefix for Debian (ci20-gcc-debian.diff).
You also mentioned the following patch when I experienced problems that had something to do with variable or member initialisation:
http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008005.html
Was this merged upstream in the end?
I was rebasing my own large patch against an updated upstream repository, but other matters took priority and I haven't looked at it again. I had been trying to write a few device drivers for the CI20, specifically for GPIO, CPM and I2C, with the latter being unreliable and rather annoying.
Paul
On Mon Oct 16, 2017 at 15:35:22 +0200, Paul Boddie wrote:
On Monday 16. October 2017 00.48.38 Adam Lackorzynski wrote:
On Sat Oct 14, 2017 at 17:09:46 +0200, Paul Boddie wrote:
On Wednesday 11. October 2017 15.33.58 Manolis Ragkousis wrote:
Finally I have a question, Are you accepting patches for L4 and L4Linux? I could make my git patches more presentable and send them here if you want, to be added to your upstream repo.
I would be interested to know about this as well. I sent some patches to the list a while back, but nothing was really said about whether there was any interest in incorporating them upstream.
Principally yes but this also depends on time etc., see other mail.
Yes, from my own perspective I understand this well. :-)
One of the patches made the stated CI20 support actually work, thanks to Sarah's guidance, so it must surely be of interest to more than just me. The
You're talking about the cache instruction issue?
Yes (ci20-rdhwr.diff). I was also potentially interested in supporting other instructions that related SoCs do not support, at least where those do not
What I don't understand is why this needs to be done in asm. I'd favor something in C.
support floating point instructions natively, and where L4Re/Fiasco.OC might not be buildable using "soft float" instructions (advice welcome!), but this is a different topic altogether (and one that I am not likely to explore in the near future).
Fiasco is typically built not using floating point, as most kernels. Which problem are you hinting at?
other patches attempted to support gcc instead of the vendor compiler, which I would also think would be desirable (especially given the corporate "pass the parcel" game going on with the vendor in question at the moment).
Well, then lets discuss those changes.
Thinking back, there was some uncertainty about whether it was appropriate to generate position-independent code when building Fiasco.OC, where I had introduced initialisation of t9 so that global offset table lookups functioned correctly (ci20-gcc-cpload.diff).
This diff addresses user-level programs, and are meant to have them being able to be compiled as PIC?
There was also a trivial patch changing the compiler prefix for Debian (ci20-gcc-debian.diff).
It is debatable which prefix shall be preferred. In any case CROSS_COMPILE can be set on the command line and in files such as Makeconf.local.
You also mentioned the following patch when I experienced problems that had something to do with variable or member initialisation:
http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008005.html
Was this merged upstream in the end?
Yes.
I was rebasing my own large patch against an updated upstream repository, but other matters took priority and I haven't looked at it again. I had been trying to write a few device drivers for the CI20, specifically for GPIO, CPM and I2C, with the latter being unreliable and rather annoying.
I don't know but maybe the Ci40 is a better board, having interAptiv cores.
Adam
Hello,
A quick reply as it is rather late...
On Monday 23. October 2017 00.55.53 Adam Lackorzynski wrote:
On Mon Oct 16, 2017 at 15:35:22 +0200, Paul Boddie wrote:
On Monday 16. October 2017 00.48.38 Adam Lackorzynski wrote:
You're talking about the cache instruction issue?
Yes (ci20-rdhwr.diff). I was also potentially interested in supporting other instructions that related SoCs do not support, at least where those do not
What I don't understand is why this needs to be done in asm. I'd favor something in C.
I haven't looked at how the floating point emulation is done in the Linux kernel, as another example of this kind of thing, but I imagine that you have to do some assembly language programming here just to recover from the exception. In this case, however, the emulated instruction is very simple, although I did take the liberty of rearranging the emulation mechanism slightly.
In fact, someone with more familiarity than me with low-level MIPS programming could probably reproduce my patch with little effort, but I imagine that it isn't of significant interest any more.
[MIPS systems without floating point support]
Fiasco is typically built not using floating point, as most kernels. Which problem are you hinting at?
I was just wondering about use of floating point. If I can build user space programs that also don't need floating point then I save myself some work, potentially.
[...]
Thinking back, there was some uncertainty about whether it was appropriate to generate position-independent code when building Fiasco.OC, where I had introduced initialisation of t9 so that global offset table lookups functioned correctly (ci20-gcc-cpload.diff).
This diff addresses user-level programs, and are meant to have them being able to be compiled as PIC?
Yes. Various L4Re components do not work when compiled with gcc unless I introduce these changes. It was suggested that I do not compile such things as position-independent code, but I don't remember any further explanation.
There was also a trivial patch changing the compiler prefix for Debian (ci20-gcc-debian.diff).
It is debatable which prefix shall be preferred. In any case CROSS_COMPILE can be set on the command line and in files such as Makeconf.local.
OK.
You also mentioned the following patch when I experienced problems that had something to do with variable or member initialisation:
http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008005.html
Was this merged upstream in the end?
Yes.
OK.
I was rebasing my own large patch against an updated upstream repository, but other matters took priority and I haven't looked at it again. I had been trying to write a few device drivers for the CI20, specifically for GPIO, CPM and I2C, with the latter being unreliable and rather annoying.
I don't know but maybe the Ci40 is a better board, having interAptiv cores.
The CI40 is aimed at a different sector, being IoT-related rather than a desktop-style single-board computer. Indeed, the CI20 has 1GB RAM - far more than the CI40 - but some trickery appears necessary to make more than 256MB visible to Fiasco due to the physical memory map layout, but I haven't looked into this yet. Obviously, Linux can make use of all of the RAM.
For me, my interest in the CI20 is driven by its choice of SoC which is in the same family as various other products I have access to. I don't think I'll be buying another board for the time being: the CI20 is tangential enough to my core interests as it is.
Paul
Hi,
On Mon Oct 23, 2017 at 01:50:47 +0200, Paul Boddie wrote:
A quick reply as it is rather late...
So often :)
On Monday 23. October 2017 00.55.53 Adam Lackorzynski wrote:
On Mon Oct 16, 2017 at 15:35:22 +0200, Paul Boddie wrote:
On Monday 16. October 2017 00.48.38 Adam Lackorzynski wrote:
You're talking about the cache instruction issue?
Yes (ci20-rdhwr.diff). I was also potentially interested in supporting other instructions that related SoCs do not support, at least where those do not
What I don't understand is why this needs to be done in asm. I'd favor something in C.
I haven't looked at how the floating point emulation is done in the Linux kernel, as another example of this kind of thing, but I imagine that you have
Linux has FP emulators to support applications with FPU code on processors that don't have an FPU. It does the obvious, catching the traps and handling them. Whether it's a good idea to do that in a microkernel is another thing. Technically it could be done of course but building the code with softfloat has always been a good alternative.
to do some assembly language programming here just to recover from the exception. In this case, however, the emulated instruction is very simple, although I did take the liberty of rearranging the emulation mechanism slightly.
Yes, it is probably simple but that does not necessarily mean it would need to be done in asm. Exceptions are caught and handled of course, the actual processing can be done in C.
In fact, someone with more familiarity than me with low-level MIPS programming could probably reproduce my patch with little effort, but I imagine that it isn't of significant interest any more.
[MIPS systems without floating point support]
Fiasco is typically built not using floating point, as most kernels. Which problem are you hinting at?
I was just wondering about use of floating point. If I can build user space programs that also don't need floating point then I save myself some work, potentially.
Exactly, and it will be faster too.
[...]
Thinking back, there was some uncertainty about whether it was appropriate to generate position-independent code when building Fiasco.OC, where I had introduced initialisation of t9 so that global offset table lookups functioned correctly (ci20-gcc-cpload.diff).
This diff addresses user-level programs, and are meant to have them being able to be compiled as PIC?
Yes. Various L4Re components do not work when compiled with gcc unless I introduce these changes. It was suggested that I do not compile such things as position-independent code, but I don't remember any further explanation.
Hmm, does that mean that with Debian's gcc (6? 7?) there might be issues?
I was rebasing my own large patch against an updated upstream repository, but other matters took priority and I haven't looked at it again. I had been trying to write a few device drivers for the CI20, specifically for GPIO, CPM and I2C, with the latter being unreliable and rather annoying.
I don't know but maybe the Ci40 is a better board, having interAptiv cores.
The CI40 is aimed at a different sector, being IoT-related rather than a desktop-style single-board computer. Indeed, the CI20 has 1GB RAM - far more than the CI40 - but some trickery appears necessary to make more than 256MB visible to Fiasco due to the physical memory map layout, but I haven't looked into this yet. Obviously, Linux can make use of all of the RAM.
For me, my interest in the CI20 is driven by its choice of SoC which is in the same family as various other products I have access to. I don't think I'll be buying another board for the time being: the CI20 is tangential enough to my core interests as it is.
Ok, I see, there's a background. And obviously the available memory can make a big difference.
Adam
Sorry for the delayed reply! Other things have been getting in the way, and some mild illness certainly hasn't helped matters.
On Wednesday 25. October 2017 00.42.59 Adam Lackorzynski wrote:
On Mon Oct 23, 2017 at 01:50:47 +0200, Paul Boddie wrote:
I haven't looked at how the floating point emulation is done in the Linux kernel, as another example of this kind of thing, but I imagine that you have
Linux has FP emulators to support applications with FPU code on processors that don't have an FPU. It does the obvious, catching the traps and handling them. Whether it's a good idea to do that in a microkernel is another thing. Technically it could be done of course but building the code with softfloat has always been a good alternative.
I'll most likely take the soft-float route for other SoCs when I get round to looking at them.
to do some assembly language programming here just to recover from the exception. In this case, however, the emulated instruction is very simple, although I did take the liberty of rearranging the emulation mechanism slightly.
Yes, it is probably simple but that does not necessarily mean it would need to be done in asm. Exceptions are caught and handled of course, the actual processing can be done in C.
The instruction being emulated is rdhwr with argument $1 (SYNCI_Step). Other arguments of this instruction were already implemented in src/kernel/fiasco/src/kern/mips/exception.S, and so it was natural to add support for this argument there as well. For example, the existing support covered argument $29 (ULR) which seems to be concerned with accessing task/thread-local storage, if I interpret "TLS" correctly.
Meanwhile, argument $1 (SYNCI_Step) is concerned with accessing data from a configuration register that would normally only be accessible in kernel mode, with the purpose of this instruction variant being to expose the cache details to user mode. So the only way to actually implement the instruction as intended would be in kernel mode by doing the necessary read from the CONFIG1 register.
A hack that I did consider was to just replace the instruction with code that just loads a constant that is set up according to the SoC parameters. A user space handler could certainly do such work and be invoked by the exception handler, but the resulting functionality would not exactly be equivalent to that provided by the patch because it would not dynamically ask the hardware about itself.
[...]
Yes. Various L4Re components do not work when compiled with gcc unless I introduce these changes. It was suggested that I do not compile such things as position-independent code, but I don't remember any further explanation.
Hmm, does that mean that with Debian's gcc (6? 7?) there might be issues?
Here's my version information:
mipsel-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516
However, I was told that gcc typically compiles position-independent code as the default for mipsel. My guess is that any version would be a problem, and I think it was already noted that development was done with the MIPS vendor compilers, not gcc, so this is why this issue wasn't noticed before.
[Accessing 1GB]
Ok, I see, there's a background. And obviously the available memory can make a big difference.
If the entire 1GB appears at a different physical address than zero, which is my understanding of the situation, is it possible to set some kind of configuration variable to let Fiasco know about this, while still preserving the addresses used for things like peripherals in the usual zero-based region?
Paul
Hi,
On Mon Oct 30, 2017 at 18:38:40 +0100, Paul Boddie wrote:
to do some assembly language programming here just to recover from the exception. In this case, however, the emulated instruction is very simple, although I did take the liberty of rearranging the emulation mechanism slightly.
Yes, it is probably simple but that does not necessarily mean it would need to be done in asm. Exceptions are caught and handled of course, the actual processing can be done in C.
The instruction being emulated is rdhwr with argument $1 (SYNCI_Step). Other arguments of this instruction were already implemented in src/kernel/fiasco/src/kern/mips/exception.S, and so it was natural to add support for this argument there as well. For example, the existing support covered argument $29 (ULR) which seems to be concerned with accessing task/thread-local storage, if I interpret "TLS" correctly.
Yes, that's about TLS.
Meanwhile, argument $1 (SYNCI_Step) is concerned with accessing data from a configuration register that would normally only be accessible in kernel mode, with the purpose of this instruction variant being to expose the cache details to user mode. So the only way to actually implement the instruction as intended would be in kernel mode by doing the necessary read from the CONFIG1 register.
A hack that I did consider was to just replace the instruction with code that just loads a constant that is set up according to the SoC parameters. A user space handler could certainly do such work and be invoked by the exception handler, but the resulting functionality would not exactly be equivalent to that provided by the patch because it would not dynamically ask the hardware about itself.
I just modified the code to have a fixed value and that worked for me as a quick hack. I don't think the value will ever change for a particular CPU. But it's still a hack and there's a smarter way definitely.
Yes. Various L4Re components do not work when compiled with gcc unless I introduce these changes. It was suggested that I do not compile such things as position-independent code, but I don't remember any further explanation.
Hmm, does that mean that with Debian's gcc (6? 7?) there might be issues?
Here's my version information:
mipsel-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516
However, I was told that gcc typically compiles position-independent code as the default for mipsel. My guess is that any version would be a problem, and I think it was already noted that development was done with the MIPS vendor compilers, not gcc, so this is why this issue wasn't noticed before.
Debian is building pie code per default nowadays, I think that's where it's coming from, and we should handle this.
The MIPS vendor compiler is actually gcc but an older one: https://www.mips.com/develop/tools/codescape-mips-sdk/download-codescape-mip...
[Accessing 1GB]
Ok, I see, there's a background. And obviously the available memory can make a big difference.
If the entire 1GB appears at a different physical address than zero, which is my understanding of the situation, is it possible to set some kind of configuration variable to let Fiasco know about this, while still preserving the addresses used for things like peripherals in the usual zero-based region?
There's a hole, and it also looks like the first 256MB is mirrored at 512MB. However, using all the memory is just a matter actually making it known, I've just tried it and it seems to work. All Ci20's have 1GB, right?
Adam
On Wednesday 1. November 2017 00.38.23 Adam Lackorzynski wrote:
[Cache detail querying]
I just modified the code to have a fixed value and that worked for me as a quick hack. I don't think the value will ever change for a particular CPU. But it's still a hack and there's a smarter way definitely.
In a lot of systems, I guess people would use a configuration setting for this kind of thing (U-Boot seems to have a lot of this going on). I'd have to look at the code to see how this instruction got included, though.
[...]
Debian is building pie code per default nowadays, I think that's where it's coming from, and we should handle this.
The MIPS vendor compiler is actually gcc but an older one: https://www.mips.com/develop/tools/codescape-mips-sdk/download-codescape-mi ps-sdk-essentials/
I'm guessing that there might have been different defaults and therefore corresponding assumptions that don't hold true for vanilla gcc.
[Accessing 1GB]
There's a hole, and it also looks like the first 256MB is mirrored at 512MB. However, using all the memory is just a matter actually making it known, I've just tried it and it seems to work. All Ci20's have 1GB, right?
Yes. My interpretation was also that the first 256MB resides at zero for compatibility with earlier SoCs in the family, and that they "started again" at a higher location (at 512MB, I guess, if you've looked it up!) when their products needed more address space.
Thanks for taking a look at this! I doubt that the CI20 is so high priority now, but who knows what its corporate parents will do after their separation?
Paul
On Wed Nov 01, 2017 at 01:03:36 +0100, Paul Boddie wrote:
On Wednesday 1. November 2017 00.38.23 Adam Lackorzynski wrote:
[Cache detail querying]
I just modified the code to have a fixed value and that worked for me as a quick hack. I don't think the value will ever change for a particular CPU. But it's still a hack and there's a smarter way definitely.
In a lot of systems, I guess people would use a configuration setting for this kind of thing (U-Boot seems to have a lot of this going on). I'd have to look at the code to see how this instruction got included, though.
It's the MIPS-related cache handling in l4sys.
Debian is building pie code per default nowadays, I think that's where it's coming from, and we should handle this.
The MIPS vendor compiler is actually gcc but an older one: https://www.mips.com/develop/tools/codescape-mips-sdk/download-codescape-mi ps-sdk-essentials/
I'm guessing that there might have been different defaults and therefore corresponding assumptions that don't hold true for vanilla gcc.
Yes, that might actually be, but Debian/Ubuntu is pretty widespread so it should work too.
[Accessing 1GB]
There's a hole, and it also looks like the first 256MB is mirrored at 512MB. However, using all the memory is just a matter actually making it known, I've just tried it and it seems to work. All Ci20's have 1GB, right?
Yes. My interpretation was also that the first 256MB resides at zero for compatibility with earlier SoCs in the family, and that they "started again" at a higher location (at 512MB, I guess, if you've looked it up!) when their products needed more address space.
Thanks for taking a look at this! I doubt that the CI20 is so high priority now, but who knows what its corporate parents will do after their separation?
The Ci20 has a somewhat special CPU which needs some special treatment. For that reason I was mentioning the Ci40 which is better in this regard.
Adam
Hi,
On Wed Oct 11, 2017 at 16:33:58 +0300, Manolis Ragkousis wrote:
On 10/05/2017 01:25 AM, Adam Lackorzynski wrote:
Those clocks are part of a clock device that has mmio registers just as the network device. So you need to give access to those so that it can set the clocks as needed. Another trick might be to let u-boot initialize the network, and thus the clocks, so that they still work when L4 has been booted. Do you boot other network in u-boot?
I followed you advice and managed to fix everything and l4linux now has access to both the network and the sd cards.
What took me time to understand is that access to all the clocks in zynq is controlled from the zynq-slcr. I first needed to add that mmio registers to the l4linux vbus. Next I ported the driver from the normal arm linux arch to the l4 arch and made sure it was properly initialized.
Then I just needed to modify the clkc driver to work under l4linux and only enable the clocks for the peripherals I needed. With all this done the drivers for each device work as is.
All my work can be found in https://gitlab.com/l4-fiasco-thesis/l4-linux and https://gitlab.com/l4-fiasco-thesis/l4
Everything I changed is specific to L4_PLATFORM_ZYNQ, the new config option I created. In the future I will move the whole Zynq slcr initialization out of l4linux and in l4, so the l4linux kernel will not control devices it shouldn't.
If anyone has any question on the how and why please ask :).
Ok, great it works.
Finally I have a question, Are you accepting patches for L4 and L4Linux? I could make my git patches more presentable and send them here if you want, to be added to your upstream repo.
Principally yes but obviously that also requires work, time and being stringent on my/our side. This might not be pleasent and I also might not find the proper time. We'd also require a CLA to be signed.
The Zynq is a popular SoC, so support for it is good. Which parts of your work would you like to see in?
Adam
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Manolis Ragkousis -
Paul Boddie