. Variables and constants in RAM (global, static), used 33060 / 80192 bytes (41%)
║ SEGMENT BYTES DESCRIPTION
╠══ DATA 1500 initialized variables
╠══ RODATA 5128 constants
╚══ BSS 26432 zeroed variables
. Instruction RAM (IRAM_ATTR, ICACHE_RAM_ATTR), used 60753 / 65536 bytes (92%)
║ SEGMENT BYTES DESCRIPTION
╠══ ICACHE 32768 reserved space for flash instruction cache
╚══ IRAM 27985 code in IRAM
. Code in flash (default, ICACHE_FLASH_ATTR), used 383656 / 1048576 bytes (36%)
║ SEGMENT BYTES DESCRIPTION
╚══ IROM 383656 code in flash
Failed uploading: no upload port provided
Code uploaded Successfully
I am trying to restore an Allwinner A13 based OEM board to working condition, because the original SD card died and there is currently no way to get an original backup image.
Only thing I have so far is the linux rootfs and a partition table it wants to use (The original sizes and filesystems are too unknown to me, so I used what i deemed purposeful).
I have created the partition table, put the rootfs into its partition and set up the toolchain to compile the u-boot + spl.
The board itself only has one Micro SD slot, and this card contains the u-boot + SPL on its first megabyte after the partition table.
The spl and u-boot layout I use:
sector (512b) start size usage
---------------------------------------
0-15 (16) 0kb 8kb MBR+GPT
16-79 (64) 8kb 32kb SPL
80-2047 (1968) 40kb 984kb u-boot
2048 (----) 1024kb (----) partitions
The partition table:
1 MBR 512MB FAT "mmcblk0p1" drive for recovery firmware dumps
2 MBR 512MB FAT "mmcblk0p2" boot volume. perhaps for u-boot environment
3 MBR GPT Container
4 GPT
5 GPT
6 GPT 2048MB ext2 "mmcblk0p6" rootfs
7 GPT 4096MB ext2 "mmcblk0p7" file system for user data
8 GPT 1024MB ext2 "mmcblk0p8" squash image and/or backup are stored here
The rootfs partition contains a folder named boot with these files inside, so I assume the SPL / u-boot eventually wants to boot from there:
/boot/script.bin 32KB
/boot/devicetree.dtb 38KB
/boot/uImage 5200KB
The SPL dies with the following error message on the serial (it doesn't even find the u-boot, the result is the same with only the SPL part dd-ed on the card):
U-Boot SPL 2020.07-rc4-STT-LMT-00022-gbe79009f3b (Jun 12 2020 - 23:40:45 +0000)
DRAM: 256 MiB
CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC2
MMC Device 1 not found
spl: could not find mmc device 1. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
How can I successfully have this boot the os on the rootfs?
I am trying to understand how a MLO is loaded into the on-chip of a SOC and do the minimal configuration. I am using TI DM8168 soc.
I have gone through the following link to understand the MLO or x-loader:
http://omappedia.org/wiki/Bootloader_Project
I got to know that the ROM Code loads the MLO (x-loader) to the on-chip RAM of the SoC which do the minimal configuration and finally loads the uboot (universal bootloader), that finally initiates the linux kernel.
My doubt here is that my on-chip RAM size is 64 KB and the MLO size is 116 KB, then how the ROM code is loading the MLO to the on-chip RAM
It seems that the DM8168 has more than 64KiB internal RAM: as explained in
the DM816x AM389x PSP 04.00.01.13 Feature Performance Guide, it has at least two more blocks of internal RAM, referenced OMC0 and OMC1, both being 256KiB in size.
Those two banks can be used by u-boot according to this document:
OCMC0 0x40300000 - 0x4033FFFF OCMC 0 will be used by ROM Code and U-boot. Once Linux kernel boots, OCMC0 is free and kernel can use it. If OCMC0 should not be used to load u-boot if loaded using CCS.
OCMC1 0x40400000 - 0x4043FFFF OCMC 1 will be used by ROM Code and U-boot. Once Linux kernel boots, OCMC0 is free and kernel can use it.
From u-boot-omap3/board/ti/ti8168/config.mk, it seems u-boot is using OMC1
TI_LOAD_ADDR = 0x40400000
This would explain why your 116KiB u-boot image can fit in the DM8168 internal RAM.
How can I determine the Physical Sector Size (e.g. if i have an Advanced Format drive with 4,096 byte sectors rather than the legacy 512 byte sectors) in Windows 7?
I know that by clicking on a file and get properties we can find out the NTFS Cluster Size, but that's not the same as the hard-drive's sector size.
Note: We ask about Windows 7 because it (and Windows Vista SP1) understand the existence of 4096 Advanced Format hard drives.
You want fsutil. Make sure you run Command Prompt as Admin.
C:\Windows\system32>fsutil fsinfo ntfsinfo c:
NTFS Volume Serial Number : 0xf4ca5d7cca5d3c54
Version : 3.1
Number Sectors : 0x00000000378fd7ff
Total Clusters : 0x0000000006f1faff
Free Clusters : 0x00000000000e8821
Total Reserved : 0x0000000000000910
Bytes Per Sector : 512
Bytes Per Physical Sector : 512
Bytes Per Cluster : 4096
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 0x00000000196c0000
Mft Start Lcn : 0x00000000000c0000
Mft2 Start Lcn : 0x000000000097ffff
Mft Zone Start : 0x000000000051f920
Mft Zone End : 0x000000000051f9a0
RM Identifier: 0652C3D3-7AA9-11DA-ACAC-C80AA9F2FF32
Windows 10 update:
There is now a sectorInfo sub-command which may provide better information:
C:\>fsutil fsinfo sectorInfo C:
LogicalBytesPerSector : 512
PhysicalBytesPerSectorForAtomicity : 4096
PhysicalBytesPerSectorForPerformance : 4096
FileSystemEffectivePhysicalBytesPerSectorForAtomicity : 4096
Device Alignment : Aligned (0x000)
Partition alignment on device : Aligned (0x000)
Performs Normal Seeks
Trim Not Supported
i wanted to expand on Chris Gessler's answer, and note that there is no known way to get the Physical sector of a drive using Windows Management Instrumentation (WMI), e.g. wmic.
Given that i have an Advanced Format drive (i.e. it uses 4,096 bytes per sector rather than 512):
C:\Windows\system32>fsutil fsinfo ntfsinfo d:
NTFS Volume Serial Number : 0xa016d8a616d87eaa
Version : 3.1
Number Sectors : 0x00000000747057ff
Total Clusters : 0x000000000e8e0aff
Free Clusters : 0x000000000e7b2813
Total Reserved : 0x0000000000000000
Bytes Per Sector : 512
Bytes Per Physical Sector : 4096
Neither WMI's DiskDrive:
wmic:root\cli>diskdrive
Availability BytesPerSector Capabilities CapabilityDescriptions Caption
512 {3, 4, 10} {"Random Access", "Supports Writing", "SMART Notification"} ST1000DM003-9YN162 ATA Device
nor Partition:
wmic:root\cli>partition get BlockSize, StartingOffset, Name, Index
BlockSize Index Name StartingOffset
512 0 Disk #0, Partition #0 1048576
can report the underlying physical sector size. It makes sense when you realize they both report the sector size that Windows is using. It is 512 bytes per sector - the drive just happens to be different inside.
That's because only Windows 8 supports use of 4k sectors. Windows 7 understands that the drive might be 4k, and works to align it's 4k Clusters with the hard-drive's underlying 4k Sectors.
Update
wmic diskdrive now does show physical bytes per sector in Bytes per Sector:
C:\Windows\system32>wmic
wmic:root\cli>diskdrive
Availability BytesPerSector Capabilities CapabilityDescriptions
4096 {3, 4} {"Random Access", "Supports Writing"}
While wmic partition continues to be wrong.
Windows 10.0.19041.804
Run msinfo32 in command line that should popup a GUI window called
"System Information"
In the left pane select "System Summary->Components->Storage->Disks". This should load info of all drives in the right pane
Find your desired drive and check the value for "Bytes/Sector". it should say "Bytes/Sector 4096"
If you want to have it programmatically, you need to send IOCTL_DISK_GET_DRIVE_GEOMETRY_EX and use Geometry.BytesPerSector from DISK_GEOMETRY_EX structure
You can use wmic from the command line:
C:\Windows\System32\wmic partition get BlockSize, StartingOffset, Name, Index
BlockSize Index Name StartingOffset
512 0 Disk #0, Partition #0 32256
512 1 Disk #0, Partition #1 370195176960
The BlockSize is the sector size of the drive.
Powershell:
$wql = "SELECT Label, Blocksize, Name FROM Win32_Volume WHERE FileSystem='NTFS'"
Get-WmiObject -Query $wql -ComputerName '.' | Select-Object Label, Blocksize, Name
Output example:
Label Blocksize Name
----- --------- ----
OSDisk 4096 C:\
Windows RE Tools 4096 \\?\Volume{b042c778-cd66-4381-9312-3f4311321675}\
PS C:\>
If you really want to have it programmatically, you need to send IOCTL_STORAGE_QUERY_PROPERTY providing STORAGE_PROPERTY_QUERY with PropertyId set to StorageAccessAlignmentProperty. This gives both physical and logical sector sizes.
Note: this only works on Windows Vista and higher.
Recent powershell versions have a Get-Volume
Get-Volume | Format-Table DriveLetter, FileSystemLabel, AllocationUnitSize
I'm writing some code with printk [i'm printing while in kernel mode] ,
but because dmesg is too small I'm losing the first few printk's.
How can I increase the size of dmesg ?
thanks in advance for the help!
You need to set CONFIG_LOG_BUF_SHIFT during compile time. The size of the buffer can not be modified in run time.
The size of the buffer is 2^CONFIG_LOG_BUF_SHIFT bytes
You can use the log_buf_len kernel parameter at boot time to set the kernel's printk() ring buffer size.
See: https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt
(You mentioned Linux 2.4; I don't know whether log_buf_len was present in Linux 2.4, which is very old.)
Printk is implemented by using a ring buffer in the kernel with a size of __LOG_BUF_LEN bytes where __LOG_BUF_LEN equals (1 << CONFIG_LOG_BUF_SHIFT) (see kernel/printk.c for details).
You can specify the size of the buffer in your kernel config by setting CONFIG_LOG_BUF_SHIFT to an appropriate value (e.g. 17 for 128Kb) (make menuconfig -> General Setup -> Kernel log buffer size).
Reference:https://elinux.org/Debugging_by_printing