I want to add multiple Virtual Displays to my Linux PC, for VNC Purposes. I have an NVIDIA GeForce GTX 750 Ti and an Ryzen 3 1200 with no On-Board Graphics.
I have already tried:
The Option "ConnectedMonitor" in /etc/X11/xorg.conf (Works, but only allows for one output at the moment, because xrandr only shows 5 outputs. When I try and add the fifth output tho, nvidia-settings throws me some kind of error, that i can only use 4 Monitors, and other programs just straight up crash when they try to change the X Screen Config...)
The EVDI Driver (After the Modprobe the X Screen crashes as expected, but xrandr --listproviders doesn't show the driver and xrandr --setprovideroutputsource doesn't work either...)
Wayland (I am an KDE Plasma user and Wayland support of KDE is Trash with the proprietary NVIDIA Driver)
Adding the Dummy Driver (Doesn't work because of NVIDIA's Proprietary trash Xinerama [I also have multiple Physical Displays])
Is it maybe possible to somehow use the nouveau driver at the same time? Or am i just adding the Dummy Driver wrong? Is it possible to get the EVDI Driver working?
I really hope someone helps me very soon...
I'm studying boot steps on a Pandaboard. According to this how-to, they have multiple boot steps (Boot rom > X-loader or SPL > U-boot > Linux kernel). Actually, I do not understand why they have such steps inefficiently. Can't I just load u-boot instead of using file called "MLO"? What does "MLO" actually do? Are there any important reasons that they have to put "MLO" instead of loading u-boot directly?
From eLinux.org:
http://elinux.org/Panda_How_to_MLO_%26_u-boot
The first-stage bootloader runs directly on the board from power-up. I
don't know the name of this bootloader(From TI official wiki, it
called Boot Rom). This bootloader initializes a minimal amount of CPU
and board hardware, then accesses the first partition of the SD card
(which must be in FAT format), and loads a file called "MLO", and
executes it. "MLO" is the second-stage bootloader.
The second-stage bootloader can apparently be one of either the
X-loader or SPL. This bootloader apparently also just reads the first
partition of the SD card, and loads a file called "u-boot.bin", and
executes it. "u-boot.bin" is the third-stage bootloader.
The third-stage bootloader is U-boot, which is a popular bootloader
for many different embedded boards and products. This bootloader has
lots of different features, including an interactive shell, variables,
ability to access the SD card and show its contents, etc. What happens
next depends on the version of U-boot you have for the Panda board,
and how it is configured. In a very simple configuration, U-Boot will
look for the file "uImage" in the root of the first partition of the
SD card (which, again, must be formatted as a FAT partition), and
execute that. This is the Linux kernel. U-Boot passes the kernel a
command line argument. Depending on how the kernel is configured it
may accept the command line from U-Boot, or use one that was compiled
into it when it was built.
This is a "Panda Board thing", not necessarily true of Linux in general.
However, most all systems have some kind of "multi-stage" boot like the one above. For example, booting a PC running Windows, you see:
BIOS startup
Boot sector is loaded from disk or USB; or a PXE boot record is read from the network
The windows kernel starts (the stuff you see before/during the "splash screen")
Finally, "Windows" itself starts
So it's neither "inefficient", nor unusual.
PS:
This link also has a good description of the boot load sequence:
http://omappedia.org/wiki/Bootloader_Project
PPS:
"MLO" stands for "Mmc LOader"
When the board comes up, the Memory Management Unit (MMU) still needs to be setup before the CPU can start using the SDRAM. The SoC has 56KB of SRAM which can be used at that point, but it is too small for u-boot to run from. The extra step is code running from SRAM will load and start u-boot.
I am using a rockchip 3188 based system on board which has 8 gb NAND flash.
I want to test the reliability of the NAND flash.
At least , I want to identify boards with bad NAND flashes shipping from factory.
I am using Ubuntu 14.04.
The NAND flash is partitioned into two parts :
1. mtd0: contains bootloader, kernel and initrd
2. mtd1: contains RFS
I tried running mtd_stresstest by "modprobe mtd_stresstest dev=1" and it never says a word. If I run it for too long, my system is getting corrupted. The corruption is expected as it is playing with the same device / is mounted on.
But the command is not returning even if I use count=1.
Please let me know what is going wrong.
I tried the following too:
Flashed a USB stick with ubuntu rfs meant for arm and plugged it to SOB.
bind mounted /proc to /media//proc
bind mounted /sys to /media/
cd /media/
chroot .
init 1
modprobe mtd_stresstest dev=1 count=1 ----> never says a word
Could you please also suggest if there is any other way test the NAND flash device reliability.
I have just ported uboot and the linux kernel to my imx31 based board. The kernel boots up because I can see the kernel messages in the ring buffer in ram, but I am not seeing and text on the serial port after ... decompressing kernel, done, booting kernel"
I am passing "console=ttySMX0,115200" on the kernel arguement line, but I am not seeing the serial device being probed by the kernel (the serial driver is being registered, but no probe is happening).
I don't understand the relationship between the serial console name "ttySMX" and what the kernel expects.
I have built the kernel under openembedded with support for the LogicPD liteboard and Freescale ADS31 board, as these are closest to my board.
Any help much appreciated ... I have been trying to get this going for two weeks.
Amongst other things need to have both CONFIG_SERIAL_IMX and CONFIG_SERIAL_IMX_CONSOLE selected in your kernel configuration.
It's possible these tags could have other names in your build. In the one I looked at, they were referenced in driver/tty/serial/imx.c - if there is a different file that embodies the driver in your build, look for similar options in its source and in the Makefile in that directory.
In my ARM based custom board, I flash u-boot to NAND whenever I do changes on that. (putting some debug statements/modification). Is there any way to directly load the uboot image in RAM memory instead of flashing it every time?
For linux kernel image I do load it in memory and use bootm to boot that image. Similarly for u-boot I am trying out. Kindly provide your suggestions.
Someone at Freescale has done this, for their P1022DS evaluation system (and some others as well). They have provided a somewhat useful document about the process in the file ${UBOOTROOT}/doc/README.ramboot-ppc8500 (in U-Boot V2010.12). This document is pretty terse and leaves many questions unanswered, but I found it a reasonable place to start when I needed to debug U-Boot for a new board, before the flash memory for that board was operating correctly.
In fact, having non-functional flash memory is one reason you might want to debug U-Boot in RAM. (There are a few reasons listed in the README, and they all sound pretty reasonable to me, in contrast to some of the other advice available on this subject)
In our situation, it was found that early prototype target board hardware included an error in the address bus connection to the flash memory that prevented us from using that flash memory. While the hardware was being redesigned and re-fabricated, we wanted to continue testing/debugging those parts of our U-Boot configuration that did not depend on flash memory, for example, I2C, Ethernet, FPGA configuration, PCIe, etc. (there are plenty of things that are independent of where the U-Boot image comes from).
Running U-Boot after loading it into RAM via a JTAG interface (using Codewarrior and the USB TAP) allowed us to continue our U-Boot bring-up tasks, even though we had no functional flash memory. Once we received a newer version of the target board with correctly functioning flash memory, we returned to debugging those parts of U-Boot that we hadn't been able to test earlier. After that, U-Boot was fully functional, and we did not have to wait for a board spin to make any progress.
Debugging a bootloader is a bit difficult, but with the right tools it should be relatively painless.
I deal with the PowerPC achitecture and with a BDI-3000 I can load and debug directly to RAM (of course, after initializing the DDR controller).
One option is if you have on-chip SRAM or L2 Cache that can be configured as on-chip SRAM. The BDI can copy to the SRAM area first, u-boot does it's thing (initialize DDR controller for example), then relocates itself to DDR RAM afterwards. Definitely faster that re-writing to slow Flash all the time.
It wasn't possible in 2004, at least.
It should be possible, if the U-Boot image you want to run has startup code that allows running it from arbitrary addresses. Whether or not that is the case for your board I can't tell.
If the startup code begins by copying the code section from the current (PC-relative) address to the final execution address (usually this is preceded by a check that these areas don't overlap), then you can load the .bin file to any address in RAM, and invoke it using go.
The second obstacle I could see would be unconditional RAM setup code at the beginning, which a number of boards have.
This is what can be read on the u-boot documentation FAQ:
Question:
I don't want to erase my flash memory because I'm not sure if my new U-Boot image will work. Is it possible to configure U-Boot such
that I can load it into RAM instead of flash, and start it from my old
boot loader?
Answer:
No. (Unless you're using a Blackfin processor, or Socfpga board, but you probably aren't.)
Question:
But I've been told it is possible??
Answer:
Well, yes. Of course this is possible. This is software, so everything is possible. But it is difficult, unsupported, and fraught
with peril. You are on your own if you choose to do it. And it will
not help you to solve your problem.
source:http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM
The problem here is that what you are trying to do goes against the philosophy of what a bootloader is. Most processors require that code starts from Flash. That code is called a bootloader. That is what U-boot is.
However, if you want to modify U-boot so that it is not a true bootloader, then you can do whatever you want. It's just software. But don't expect any mainline support for the above reasons.
Just take in mind (be care of) the hardware that you are configuring in your modified U-Boot. U
Boot is intended to initialize critical modules, some of them are not able to be re-configured on the fly or they may not performe as if they were initialized/configured at startup.
If your Target board support network booting, you can load uboot image from host machine to RAM through network.
You can use usb boot. TI and Freescale provides their usb boot utilities. I don't know about other vendors.
Yes, It is possible most of the compilation structure at the end U-Boot provides a u-boot.bin file which is a flattened binary, if your target supports USB/TFTP or any other medium which current U-boot can detect on you target environment then we can load the u-boot.bin file to the static memory address area. This address is the entry point of U-Boot Code and U-boot can execute the flattened binaries by go 0x<memory_address>. The static memory address area can be deduced form u-boot.map file, This entry point is basically address to the .text area of compiled program usually can we searched in the .map file with string "Address of section .text set to 0x." Below is the example of doing it from USB.
usb start
load usb 0x<memory_address> u-boot.bin
go 0x<memory_address>
This should run you U-Boot from usb with out disturbing current code.