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.
Related
How can we find the naming of available gpios in an arbitrary board that runs Linux and then to use the Linux commands echo "gpionumber" >/sys/class/gpio so then we can control this gpio?
Gpio and gpiocontrollers are numbered. Gpiocontrollers may have labels, but they may not be unique.
The linux kernel documentation on gpio sysfs driver can be found here and is a good read.
The linux kernel uses device tree file to know which gpiocontrollers are available to him. A gpiocontroller may have multiple gpios. Each board has it's own unique device tree compiled with the kernel or loaded at boot time.
Gpiocontrollers are identified by the register and register length they refer too, see here. You can specify the label of the gpiocontroller as described in device tree file format and you can query the gpiocontroller label using /sys/class/gpio/gpiochipN/label, they may be not unique and they don't let you identify the gpio. Also, they may change between device tree file versions.
There is no "naming", just numbering. You can query all gpios available on a particular board by just inspecting/adding the /sys/class/gpio/gpiochip*/ngpio Usually a board manufacturer/provider/seller/etc provides documentation with the kernel it ships with the board with explanation, which gpio has which number/address, like for Colibri VF61. For some popular boards it is just a matter of googling to find nice looking images with gpio numbers, like for RaspberryPi3 or
Using Linux 3.14.52 on a imx6sx hardware platform (NXP embedded ARM).
The problem is that PCF8575 I2C GPIO expanders specified in the device tree are not instantiated as devices in the /sys/class/gpio structure unless they are present during kernel boot. The devices are listed in the /sys/bus/i2c/devices/i2c-1 (i2c bus 1) structures but are not given gpiochip 's in the /sys/class/gpio structure.
Is there a way to have these devices assigned as gpiochip after boot once they are added to the system?
On previous (PowerPC) platform, all devices listed in the device tree were assigned gpiochip's regardless of whether they were on during kernel boot. But with our ARM platform, the devices must be available during kernel boot. I have tried changing the kernel i2c/gpio options (via .config) as close to the previous platform as possible but this seems to have no effect.
For sure the kernel worked differently regarding sysfs in the 2.6 kernel branch. I have experienced similar issues as well. It has to do with handling of the device tree. The device tree will get unflattened, but this only kicks off the actual discovery of devices. If the devices do not actual exist, they will not be probed and will not have entries created in sysfs.
Device Tree Usage
Linux board support code calls of_platform_populate(NULL, NULL, NULL, NULL)
to kick off discovery of devices at the root of the tree. The
parameters are all NULL because when starting from the root of the
tree, there is no need to provide a starting node (the first NULL), a
parent struct device (the last NULL), and we're not using a match
table (yet). For a board that only needs to register devices,
.init_machine() can be completely empty except for the
of_platform_populate() call.
So the device tree will only tell the kernel what to discover, it will not actually add anything if it is not found.
I can confirm the gpiochip is ONLY added at probe of your device:
gpio-pcf857x.c
Notice the call on line 397 to gpiochip_add
What I would recommend is to try compiling your kernel with the gpio expander set as a module and then insmod it after it has actually been attached.
I'm trying to backport a Linux kernel driver (the PCF85063 RTC, specifically) from the 3.17+ kernel into a 3.14 kernel I'm using, and I'm running into a few issues. I don't have any experience with adding/modifying kernel drivers, so I'm not sure if what I've done so far is correct:
I took the rtc-pcf85063.c file from the newer kernel, and added it to my drivers/rtc/ directory in the kernel source.
I added the following line to drivers/rtc/Makefile:
obj-$(CONFIG_RTC_DRV_PCF85063) += rtc-pcf85063.o
I added this snippet to drivers/rtc/Kconfig
config CONFIG_RTC_DRV_PCF85063
tristate "NXP PCF85063"
help
If you say yes here, you get support for the NXP PCF85063 RTC.
From my understanding, that should be all it takes to add driver support for the new RTC. When I execute make menuconfig, I can see my new RTC entry under Device Drivers > Real Time Clock, labeled as NXP PCF85063 with the correct help information. So it's clear that the third step above was successful.
The problem is, when I include this driver (by selecting it in menuconfig and saving/exiting) in my kernel build, it doesn't actually get built in. If I deploy the kernel and read /lib/modules/3.14.17/modules.builtin, the new driver is nowhere to be found. Also, if I check drivers/rtc/ after building the kernel, there are object files for every RTC driver included through menuconfig except the new one; the kernel isn't even compiling the driver.
I found one interesting thing that might give some hint as to what's going on. When I go to include/config in the linux source after running menuconfig, I have a bunch of directories, some of which correspond to drivers. There's an rtc directory, and when I navigate to include/config/rtc/drv, there's a header file for every RTC driver included in the build except the one I added.
The thing is, the header file corresponding to the new driver is in include/config; it's hidden away in include/config/config/rtc/drv. It looks like menuconfig isn't treating the new driver as a regular RTC driver.
I know this is a pretty specific problem, but I was hoping that someone might notice that I'm missing a step or going about this the wrong way. Thanks.
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.
I have a problem probably with my arm toolchain but maybe there's something other that I do wrong. I have Chinese made dev board qq2440 using Samsung s3c2440 ARM9 uC. I'm using Ubuntu x86 with native gcc(4.3.3) and cross-compile version arm-unknown-linux-uclibc-gcc (crosstool-NG-1.3.2) 4.3.2
I followed tutorials from http://blog.leshak.ru/english/pages/how-to-install-u-boot-linux-2629-rootfsjffs2-busybox-1132-into-nand-qq2440/
and used Leshak's kernel patches for that board. Problem is that his binaries work perfectly and mine don't...
I communicate with my board over RS232 (serial port) and I have serial terminal configured on target Linux. I use Leshak's uboot image. To configure my kernel I use following command line:
qq2440> setenv bootargs 'noinitrd root=/dev/mtdblock2 rootfstype=jffs2 rw console=ttySAC0,115200'
For target I use vanilla Linux sources version 2.6.29, with patches created by Leshak. I don't honestly believe that this will ever be supported officially by Linux as it's not mainstream product.
My kernel image starts booting up, but it probably changes bandwidth (or CPU frequency) to some non standard value (tried all standard ones already). Instead of dots indicating loading kernel into memory I've got only trash instead. Unfortunately it doesn't probably finish the boot process as the network interface nor file system don't come up. So I figured out that it panics somewhere in the middle.
Any ideas what should I do next?
Thanks & regards,
Chris
There are a lot of different things that could be going on here.
It sounds like you are talking about a serial port, and that it appears to be giving garbage once control is passed to the kernel from uboot. Am I understanding that correctly?
Look into specifying the baud rate, parity, etc. for the serial console on the kernel commandline.
Oh, and IIRC, there was some 'early_printk' thing in the ARM Linux tree that might help you debug serial console problems. (But I'll warn you -- it's been a couple years since I dealt with that so my memory is fuzzy.)
Double-check that the memory address layout (the locations of all the various devices) matches what your board has. (I think this is probably not the issue, but wanted to mention it for completeness.)
You say that you have a binary kernel that works correctly; compare the kernel config of that kernel to the config you are using for building your kernel. Investigate every difference, particularly any specific to ARM.
You may want to double-check the endianness of your toolchain vs what your board is expecting. Some of the ARM / XScale processors can be configured to big-endian or little-endian in software, so it might be worth double-checking.
Just enable the debug build of the kernel[while building the uImage] so that you get a more clearer picture of the scenario [Just would make your boot up somewhat slow since all the printk's would be enabled].
Can you check whether you are passing the correct parameters to the UART ie. Serial Port Name, it's baud rate etc This would be provided by the board manufacturer-Samsung
WRT the network instead of DHCP can you just assign a static ip address to your system as it might be possible that the DHCP process is still not ON.
Also a better option would be to use NFS but yeah, it depends on your choice and the purpose of your application. To use NFS, your network should be UP & running and your filesystem should be shared.
As retracile has already pointed out "Endianness" could be a point to look into !!!
You can refer this link which might help you out since it is specific to S3C2440
Hope this helps.
-hjsblogger
I had a similar problem at one point when I omitted --send-cmd from picocom. this is the command I issue to picocom for serial uBoot comms with the mini2440.
picocom -b 115200 /dev/ttyS0 --send-cmd "sx -vv"