How can i read sysfs attributes - c

How can i read sysfs attributes from user app. It is similar content from cat command. Such as I have a tag is brightness. How can i get the value of brightness tag? Because i need to read the USB infor from my app and i see they were exported to sysfs like below topology:
ls /sys/bus/usb/devices/1-1
1-1:1.0 busnum port
authorized configuration power
avoid_reset_quirk descriptors product
bConfigurationValue dev quirks
bDeviceClass devnum removable
bDeviceProtocol devpath remove
bDeviceSubClass driver serial
bMaxPacketSize0 ep_00 speed
bMaxPower idProduct subsystem
bNumConfigurations idVendor uevent
bNumInterfaces ltm_capable urbnum
bcdDevice manufacturer version
bmAttributes maxchild

Open the file using e.g. fopen("//sys/bus/usb/devices/1-1/version", "rt") and read its contents like with any other file. Not sure about brightness, you don't mention which file its in and there's no file with that name.

Related

How do I change the SD card controller that's used by U-boot for the Raspberry Pi 3 Model B+?

The Raspberry Pi 3 Model B+ has two SD card controllers.
There is custom controller called sdhost as shown by the device tree node:
/* SDHOST is used to drive the SD card */
&sdhost {
pinctrl-names = "default";
pinctrl-0 = <&sdhost_gpio48>;
status = "okay";
bus-width = <4>;
};
And an SDHCI-compliant controller as shown by the following device tree node:
/* SDHCI is used to control the SDIO for wireless */
&sdhci {
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&emmc_gpio34>;
status = "okay";
bus-width = <4>;
non-removable;
mmc-pwrseq = <&wifi_pwrseq>;
brcmf: wifi#1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
};
};
As referenced by the U-boot comments, U-boot is using SDHOST as the SD card controller and SDHCI as the WiFi controller.
/* SDHOST is used to drive the SD card */
...
/* SDHCI is used to control the SDIO for wireless */
The problem I'm facing is that I'm unable to run this SD card driver (source code here) via U-boot, which uses the Pi's SDHCI controller to interact with SD cards.
The SD card driver runs successfully bare-metal via the Pi's existing bootloader as shown by the output below:
EMMC: GPIO set up
EMMC: reset OK
sd_clk divisor 00000068, shift 00000006
EMMC: Sending command 00000000 arg 00000000
EMMC: Sending command 08020000 arg 000001AA
EMMC: Sending command 37000000 arg 00000000
EMMC: Sending command 29020000 arg 51FF8000
EMMC: CMD_SEND_OP_COND returned VOLTAGE CCS 0000000040F98000
...
However, when I try to run the binary via U-Boot using the go command, the code is stuck during the initialisation phase of the SDHCI controller (exact line in source code here) as shown below:
EMMC: GPIO set up
EMMC: reset OK
sd_clk divisor 00000068, shift 00000006
EMMC: Sending command 00000000 arg 00000000
EMMC: Sending command 08020000 arg 000001AA
ERROR: failed to send EMMC command
My suspicion is that since U-boot has configured the SDHCI controller for Wifi (and not for SD cards), I can no longer use it as an SD card controller. However, I want to use the SDHCI controller as the SD Card controller.
What is the best way to get my SD card binary running via U-boot?
Is the only option to configure/recompile U-boot to use the SDHCI controller as the main SD card controller (and forget about WiFi)?
If so, some pointers on how to go about this would be much appreciated.
Alternatively, is there a U-boot shell command (like some sort of reset command) that give binaries a runtime environment similar to a bare-metal environment that has been un-modified by U-boot?
Edit:
Here is my progress so far. I've figured out how to exclude the custom SDHOST driver from being initialised via two methods:
Modifying the DTS file by replacing status = "okay" with status = "disabled" for the custom SDHOST driver.
Adding CONFIG_MMC_BCM2835=n to U-Boot's configs/rpi_3_b_plus_defconfig file.
When I launch U-boot, and run mmc list, I see only the SDHCI controller, which is great:
U-Boot> mmc list
mmc#7e300000: 0
I know the above is the SDHCI controller because its device registers are mapped to the physical address of 7e300000 as shown in arch/arm/dts/bcm283x.dtsi below:
sdhci: mmc#7e300000 {
compatible = "brcm,bcm2835-sdhci";
reg = <0x7e300000 0x100>;
interrupts = <2 30>;
clocks = <&clocks BCM2835_CLOCK_EMMC>;
status = "disabled";
};
However, as shown in the following boot logs, U-boot is still not happy to use this controller as the SD card controller:
MMC: mmc#7e300000: 0
Loading Environment from FAT... Card did not respond to voltage select! : -110
** Bad device specification mmc 0 **
Below is the entire boot log:
U-Boot 2023.01-00790-g8c80619653-dirty (Feb 11 2023 - 10:04:49 +1100)
DRAM: 948 MiB
RPI 3 Model B+ (0xa020d3)
Core: 63 devices, 14 uclasses, devicetree: embed
MMC: mmc#7e300000: 0
Loading Environment from FAT... Card did not respond to voltage select! : -110
** Bad device specification mmc 0 **
In: serial
Out: vidconsole
Err: vidconsole
Net: No ethernet found.
starting USB...
Bus usb#7e980000: USB DWC2
scanning bus usb#7e980000 for devices... 4 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
U-Boot> mmc list
mmc#7e300000: 0
My suspicion is that the SDHCI controller is still being treated by U-Boot as a WiFi controller (I can't tell for sure). What are some troubleshooting steps I can take to figure out what is going on?
My solution is to change the following line in the sdhci node of the DT located at arch/arm/dts/bcm2837-rpi-3-b-plus.dts from
pinctrl-0 = <&emmc_gpio34>;
to
pinctrl-0 = <&sdhost_gpio48>;
Then I recompile U-boot and use the resultant U-boot binary as the Pi’s bootloader.
The final and desired result is that:
U-boot can still use the sdhost driver and controller to access the SD card when it is running (which is U-boot’s default preference).
The binary run by U-boot (via the go command) can also manipulate the sdhci controller’s device registers to interact with the SD card.
For additional context around the solution, the sdhost_gpio48 reference above is located in this DTSI file located at arch/arm/dts/bcm283x.dtsi:
sdhost_gpio48: sdhost_gpio48 {
brcm,pins = <48 49 50 51 52 53>;
brcm,function = <BCM2835_FSEL_ALT0>;
};
The pinctrl-0 parameter we have changed refers to “Pin Control” and detailed documentation about this parameter can be found here.
From my understanding, our change specifies the same GPIO pins that are being used for the SDHOST controller for the SDHCI controller, which enables us to use the SDHCI controller as an SD card controller.

Uboot NAND flash or mtd partition auto-changes to ubi(?)

I am not sure whether the following situation is normal.
I have the following command to boot to kernel from uboot:
set mtdids nand0=pxa3xx_nand-0
set mtdparts mtdparts=pxa3xx_nand-0:0x600000(boot)ro,0x400000(kernel),-(rootfs)
usb start
fatload usb 0:1 0x201000000 ubifs.img
nand erase.part rootfs; ubi part rootfs; ubi create nand_rootfs
ubi write 0x201000000 nand_rootfs $filesize
fatload usb 0:1 0x206000000 Image;
fatload usb 0:1 0x201000000 dtb.dtb;
set bootargs mem=2G console=ttyS0,115200 earlycon=uart8250,mmio32,0x7f012000 ubi.mtd=2 root=ubi0 rootfstype=ubifs rw cpuidle.off=1;
booti 0x206000000 - 0x201000000;
As you can see, since the Image and dtb are not stored internally, I have to plug in a USB to boot my device with this method. To get rid of using USB every time, I modified the cmds as follows:
set mtdparts mtdparts=pxa3xx_nand-0:0x600000(boot)ro,0x3200000(kernel),0x100000(dtb),0x100000(dtb_spare),0x5C80000(rootfs),-(rootfsubi); //I will explain why I made that many partitions
set kernelsize 0x2916808;
set dtbsize 0x1f15;
set ubifsimgsize 0x2cc0ff0;
nand erase.chip;usb start;
fatload usb 0:1 0x210000000 ubifs.img;
ubi part rootfs; ubi create nand_rootfs;
ubi write 0x210000000 nand_rootfs $ubifsimgsize;
nand write 0x210000000 rootfsubi $ubifsimgsize; // will be explained below
fatload usb 0:1 0x206000000 Image;
fatload usb 0:1 0x201000000 dtb.dtb;
nand write 0x206000000 kernel $kernelsize;
nand write 0x201000000 dtb $dtbsize;nand write 0x201000000 dtb_spare $dtbsize;
setenv boot_device 'nand read 0x206000000 kernel $kernelsize;nand read 0x201000000 dtb $dtbsize;set bootargs mem=2G console=ttyS0,115200 earlycon=uart8250,mmio32,0x7f012000 ubi.mtd=3 root=ubi0 rootfstype=ubifs rw cpuidle.off=1;booti 0x206000000 - 0x201000000;'
set boot_cmd run boot_device;
set bootargs mem=2G console=ttyS0,115200 earlycon=uart8250,mmio32,0x7f012000 ubi.mtd=2 root=ubi0 rootfstype=ubifs rw cpuidle.off=1;
saveenv
booti 0x206000000 - 0x201000000;
The first time boot using the above command was always successful. My problem happened when I reboot to uboot from kernel.
The "nand write" ubifs img appears because the ubi volume was gone but every time I boot to uboot from kernel. This command was meant to do the ubi device and volume process again without using USB.
Moreover, when the first time booted to the kernel, and reboot to enter uboot again, I discovered with the commands md address, ubi read and nand read that, the memory in the partition changed into UBI something. Please take a look at the picture below
Picture: Auto-changes to ubi something(?)
Basically all partition except the first 0x400000 bytes of kernel and boot behave as above when booted to uboot from kernel.
I did not find anything relevant online. I wonder if this is something normal when using ubi or ubifs to boot to kernel. Please let me know if you have any hints or clues about how to achieve booting to kernel without external USB.
Post the mtd part here if it matters:
uboot>> mtd
device nand0 <pxa3xx_nand-0>, # parts = 6
#: name size offset mask_flags
0: boot 0x00600000 0x00000000 1
1: kernel 0x03200000 0x00600000 0
2: dtb 0x00100000 0x03800000 0
3: dtb_spare 0x00100000 0x03900000 0
4: rootfs 0x05c80000 0x03a00000 0
5: rootfsubi 0x06980000 0x09680000 0
active partition: nand0,0 - (boot) 0x00600000 # 0x00000000
defaults:
mtdids :
mtdparts:

Write to eMMC boot0 partition from u-boot

I am using eMMC based on 5.1 Version, which has boot0, boot1, rpmb and userarea.
Inorder to write to eMMC from u-boot, mmc commands can be used.
mmc read commands is of below form.
$mmc read addr blk# cnt
if i give blk to 0x0, where it will write boot0 partition or user area ?
Thanks in advance

Load u-boot.ldr in bf548 ezkit using sd card

i am working on BF548 EZKIT LITE, i had done tftp booting in it. Kernel and jffs2 file system loaded successfully and got the root prompt.
But now i need to use SD card for booting, I had made ext2 partition into sd card and copy u-boot.ldr(boot loader) in it, but when try to load this file after inserting SD card into board i had got an error like
tranfering data failed
** ext4fs_devread read error - block
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
search on net but could not find anything , add log for detail which shows SD card is detected.
bfin> mmcinfo
Device: Blackfin SDH
Manufacturer ID: 3
OEM: 5344
Name: SD02G
Tran Speed: 25000000
Rd Block Len: 512
SD version 2.0
High Capacity: No
Capacity: 1.8 GiB
Bus Width: 4-bit
bfin>
bfin> ext2load mmc 0 0x1000000 u-boot.ldr
tranfering data failed
** ext4fs_devread read error - block
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
bfin>
I had tried different sd card also but still got the same problem, Any one have clue about this? Please share.
U-boot version= 2014.07.
Linux kernel = 4.5.4
I am using Buildroot for making board support package.
Thank in advance....
Ah, so your problem is:
bfin> ext2load mmc 0 0x1000000 u-boot.ldr
and this should be:
bfin> ext4load mmc 0:1 0x1000000 u-boot.ldr
as you need to specify both the MMC device (0) and the partition on the device (1 as you made 1 partition on the SD card and formatted that). Just saying 0 causes it to try and read the whole device as where the filesystem is which fails when it runs into the partition table. And you need to use 'ext4load' (or just load, if you have the generic commands enabled) as well since you've got ext3/ext4 most likely and not just ext2.

uboot mmc write issue on beagleboard black

I have some toubles with mmc write on beagleboard black.
Here is the problem :
U-Boot# usb start
(Re)start USB...
USB0: scanning bus 0 for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
U-Boot# fatload usb 0 ${loadaddr} ${rootfs_file}
reading rootfs.ext4
18742272 bytes read in 12384 ms (1.4 MiB/s)
U-Boot# mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
U-Boot# mmc part
Partition Map for MMC device 1 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type
1 63 1028097 00000000-01 0c Boot
2 1028160 1028160 00000000-02 83
3 2056320 1686825 00000000-03 83
U-Boot# mmc dev 1 2
switch to partitions #2, OK
mmc1(part 2) is current device
U-Boot# mmc write $loadaddr 0x0 0x20000
MMC write: dev # 1, block # 0, count 131072 ... MMC: block number 0xffff exceeds max(0x800)
0 blocks written: ERROR
So why ? Partition 2 is supposed to be 64MB
moreover
U-Boot# mmc info
Device: OMAP SD/MMC
Manufacturer ID: fe
OEM: 14e
Name: MMC02
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.41
High Capacity: No
Capacity: 1 MiB <=== ??? WHY ???
Bus Width: 4-bit
Thanks for your replys
Fred
AFAIK "mmc write" performs raw writes to the MMC device. It does not perform write via the filesystem. There is no "write" support to most of the filesystem access commands. Only ext4 seems to have "write" operation (but I have not personally tested this). The "mmc write" you performed probably overwrote the MMC partition table.

Resources