This is the .inf file. It is just a sample from
https://github.com/microsoft/Windows-driver-samples/tree/master/print/OEM%20Printer%20Customization%20Plug-in%20Samples/C%2B%2B/bitmap
I have all the 3 files bitmap.DLL, bitmap.ini,bitmap.gdp all in the same folder at C:\windows.
Why does it complain about bitmap.gdp and bitmap.ini
I am getting this error:
Errors:
22.9.1: bitmap.gdp in [bitmapgdp] of Driver Package1\bitmap.inf is missing or cannot be decompressed from source media. Please verify all path values specified in SourceDisksNames, SouceDisksFiles, and CopyFiles sections resolve to the actual location of the file, and are expressed in terms relative to the location of the inf.
22.9.1: bitmap.ini in [bitmapini] of Driver Package1\bitmap.inf is missing or can
not be decompressed from source media. Please verify all path values specified in SourceDisksNames, SouceDisksFiles, and CopyFiles sections resolve to the actual location of the file, and are expressed in terms relative to the location of the inf.
; bitmap.INF
;
; INF file for bitmap Driver
; - for Windows XP (SP2), NT2003 (R2), Vista, Win7, NT2008 (x86 and x64)
;
; Copyright 2007-2010 MS
[Version]
Signature="$windows NT$"
ClassGUID={4D36E979-E325-11CE-BFC1-08002BE10318}
Class=Printer
Provider=MS
DriverVer=04/21/2010, 5.0.10.4211505
catalogfile = bitmapnew.cat
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Manufacturer Section
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
[Manufacturer]
"Microsoft"=Microsoft, NTx86, NTamd64, NTia64, NTarm64
[Microsoft]
"Bitmap Driver" = BITMAP
[Microsoft.NTx86]
"Bitmap Driver" = BITMAP
[Microsoft.NTamd64]
"Bitmap Driver" = BITMAP
[Microsoft.NTia64]
"Bitmap Driver" = BITMAP
[Microsoft.NTarm64]
"Bitmap Driver" = BITMAP
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Models Section
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
[bitmapGDP]
bitmap.GDP
[bitmapINI]
bitmap.INI
[bitmapDLL]
bitmap.DLL
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Install Section
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
[BITMAP]
CopyFiles=bitmapGDP,bitmapINI,bitmapDLL
DataSection=UNIDRV_DATA
Include=NTPRINT.INF
Needs=UNIDRV.OEM,UNIDRV_DATA
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Source Media Section
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
[DestinationDirs]
DefaultDestDir=66000
[SourceDisksFiles]
bitmap.DLL = 1,
bitmap.GDP = 1,
bitmap.INI = 1
[SourceDisksNames]
1 = %DiskName%,
2= %CWIN%
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Control Flags Section
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Strings Section
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
[Strings]
DiskName="Disk Drive",
CWIN = "C:\Windows\bitmap"
Related
I'm trying to build a LittleFS file system binary on my PC and flash it to my WeMos D1 Mini Pro (16MB) ESP8266.
I used the following code on the ESP
LittleFS.begin()
FSInfo info;
LittleFS.info(info);
Serial.print("LittleFS block size:");
Serial.println(info.blockSize);
Serial.print("LittleFS total bytes:");
Serial.println(info.totalBytes);
To determine the block size and total bytes, which gave me 8192 and 14655488 respectively. 14655488 / 8192 = 1789 so I used 1789 as the block size in the below python:
from littlefs import LittleFS
fs = LittleFS(block_size=8192, block_count=1789)
with open( 'index.html', 'rb' ) as f:
data = f.read()
with fs.open( '/index.html', 'w') as fh:
fh.write( data )
with open('fs.bin', 'wb') as fh:
fh.write(fs.context.buffer)
This creates a 14655488 bytes .bin file.
I then looked in boards.txt and found these lines:
d1_mini_pro.menu.eesz.16M14M=16MB (FS:14MB OTA:~1019KB)
d1_mini_pro.menu.eesz.16M14M.build.flash_size=16M
d1_mini_pro.menu.eesz.16M14M.build.flash_size_bytes=0x1000000
d1_mini_pro.menu.eesz.16M14M.build.flash_ld=eagle.flash.16m14m.ld
d1_mini_pro.menu.eesz.16M14M.build.spiffs_pagesize=256
d1_mini_pro.menu.eesz.16M14M.upload.maximum_size=1044464
d1_mini_pro.menu.eesz.16M14M.build.rfcal_addr=0xFFC000
d1_mini_pro.menu.eesz.16M14M.build.spiffs_start=0x200000
d1_mini_pro.menu.eesz.16M14M.build.spiffs_end=0xFFA000
d1_mini_pro.menu.eesz.16M14M.build.spiffs_blocksize=8192
This confirms the block size and gives the SPIFFS (but LittleFS is equivalent here, right?) start address as 0x200000
Checking these Arduino bits, i get:
FS_PHYS_ADDR: 2097152 (0x200000)
FS_PHYS_SIZE: 14655488
FS_PHYS_PAGE: 256
FS_PHYS_BLOCK: 8192
So then I used:
python upload.py --chip esp8266 --port COM6 --baud 460800 write_flash 0x200000 fs.bin
which outputs:
esptool.py v2.8
Serial port COM6
Connecting....
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: ec:fa:bc:6e:19:90
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 16MB
Compressed 14655488 bytes to 215596...
Writing at 0x00234000... (100 %)
Wrote 14655488 bytes (215596 compressed) at 0x00200000 in 56.7 seconds (effective 2067.0 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
However, when I then use code like the below
Dir root = LittleFS.openDir("/");
while (root.next())
{
Serial.print(root.fileName());
}
I get nothing, and
LittleFS.exists("/index.html")
returns false.
What am I doing wrong, or how do I debug this?
I'm uploading my firmware (not the filesystem) via Visual Studio Code, and the board configuration I'm using is
"xtal=80,vt=flash,exception=legacy,ssl=all,eesz=16M14M,ip=lm2f,dbg=Disabled,lvl=None____,wipe=none,baud=921600"
If I open the bin in a hex editor, I can see:
Which is some javascript inside the html file.
If I do this:
uint32_t b;
ESP.flashRead(0x006C2800 + 0x200000, &b, 1);
Serial.println(b);
then it returns 115/0x73, so it looks like the binary has flashed successfully, so that leaves me with either the binary being flashed in the wrong place, or it being corrupted/invalid....
I haven't fixed this exact problem, but I have achieved what I want.
This:
C:\Users\Andrew Bullock\AppData\Local\Arduino15\packages\esp8266\tools\mklittlefs\2.5.0-4-fe5bb56\mklittlefs.exe
exists (instructions here https://github.com/earlephilhower/mklittlefs) which works. So I can only assume that the Python wrapper or the version of LittleFS it's using is somehow incompatible or broken.
The only problem here i can see is that the block_count you gave in your python script is wrong. block_count actually refers to the pageSize of the Filesystem, that holds number of bytes every page is going to hold, in ESP littleFS the pageSize is 256.
So your object initialisation should be like this:
fs = LittleFS(block_size=8192, block_count=259)
I have a set of HDF5 files that have the following header:
netcdf control-A-2017-05-12-090000-g1 {
dimensions:
phony_dim_0 = 16 ;
phony_dim_1 = 16 ;
phony_dim_2 = 200 ;
phony_dim_3 = 2 ;
phony_dim_4 = 1 ;
phony_dim_5 = 4 ;
variables:
...
Since it's HDF5, the dimensions are created as phony_dim_x. In this case, phony_dim_0 and phony_dim_1 are the y and x coordinates, respectively. I would like to rename the dimensions appropriately. Since renaming dimensions in HDF5 is not possible (since they don't technically exist), I need to convert to netcdf first. to do so I use ncks in.h5 out.nc.
However, the header info of the converted file is:
netcdf control-A-2017-05-12-090500-g1 {
dimensions:
phony_dim_0 = 16 ;
phony_dim_1 = 200 ;
phony_dim_2 = 2 ;
phony_dim_3 = 1 ;
phony_dim_4 = 4 ;
variables:
...
Here's the important part: the two phony_dim_[0,1] dimensions have been combined to a single dimension, phony_dim_0. I assume this is because they have the same value, and so the netcdf conversion assumes they're the same.
A variable that was listed in the hdf5 file as
ACCPA(phony_dim_0, phony_dim_1) ; is now ACCPA(phony_dim_0, phony_dim_0) ;, with two identical dimensions.
Thus, I am not able to rename the dimensions individually. If I do ncrename -d phony_dim_0,y out.nc, I get ACCPA(y, y) ;
Can anyone point me in the right direction to get around this?
The problem ended up being with ncks. Converting the file with ncks resulting in repeated dimensions (e.g. ACCPA(phony_dim_0, phony_dim_0) ;)
Using nccopy instead, the converted netCDF file did not produce repeated dimensions (ACCPA(phony_dim_0, phony_dim_1) ;)
I use Channel as a backup in flume without any sink and it's working correctly. Below is my working code, but how can I give directory or file name dynamically? (I want to give name date wise when date is change new directory is created Dynamically and exist previous as a backup.)
# Name the components on this agent
a1.sources = r1
a1.channels =c1
# Describe/configure the source r1
a1.sources.r1.type = http
a1.sources.r1.port = 40441
a1.sources.r1.bind = X.X.X.X
a1.sources.r1.channels = c1
# Use a channel which buffers events in file
a1.channels.c1.type = file
a1.channels.c1.dataDirs = /data/disk11/flume/Test/dataDirs{**%y%m%d**}
a1.channels.c1.checkpointDir =data/disk11/flume/Test/checkpointDir{**%y%m%d**}
a1.channels.c1.capacity = 1000
a1.channels.c1.transactionCapacity = 100
While trying to install a network driver on win server 2008, i received the following msg box:
{Unable to find any drivers for this device}
In addition, this was setupapi.app.log output:
>>> [Build Driver List - unknown device]
>>> Section start 2014/11/12 14:59:09.946
cmd: C:\windows\Explorer.EXE
! dvi: Driver list already built
<<< Section end 2014/11/12 14:59:09.946
<<< [Exit status: SUCCESS]
This driver was previously installed on win server 2003.
Here is the INF file:
; -- NETSF.INF --
;
; Passthru driver INF file - this is the INF for the service (protocol)
; part.
;
; Copyright (c) 1993-2001, Microsoft Corporation
;
; ----------------------------------------------------------------------
; Notes:
; 0. The term "filter" is used in this INF to refer to an NDIS IM driver that
; implements a 1:1 relationship between upper and lower bindings.
;
; 1. Items specifically required for a filter have been marked with
; "!!--Filter Specific--!!" keyword
; 2. In general a filter DOES NOT require a notify object for proper installation.
; A notify object is only required if one wants to have better control
; over binding operations or if one wants to receive notifications
; when other components get installed/removed/bound/unbound.
; Since Windows 2000 systems do not have support for CopyINF directive,
; a notify object is required to programmatically copy the miniport INF
; file to the system INF directory. Previous versions of this INF file
; erroneously used to copy the INF files directly by using the CopyFiles
; directive.
; On Windows XP, you can install a filter IM without a notify object.
; by following the instructions in (4).
;
; 3. If you want to use this INF file with your own IM driver, please
; make the following modifications:
; File netsf.inf
; --------------
; a. In section [SourceDiskFiles] and [Passthru.Files.Sys]
; change passthru.sys to the name of your own driver binary.
; b. In section [Passthru.ndi.AddReg], change values of
; BindForm and MiniportId to appropriate values.
; File netsf_m.inf
; ----------------
; a. Replace MS_PassthruMP with InfId of your miniport.
; b. In section [PassthruMP.AddService],
; change ServiceBinary appropriately.
; c. In section [PassthruMP.ndi.AddReg],
; change "Passthru" in the line having "Service"
; to reflect the appropriate name
;
;
; ----------------------------------------------------------------------
[Version]
Signature = "$Windows NT$"
Class = NetService
ClassGUID = {4D36E974-E325-11CE-BFC1-08002BE10318}
Provider = %Msft%
DriverVer = 06/24/1999,5.00.2071.1
[Manufacturer]
%Msft% = MSFT
[ControlFlags]
;=========================================================================
;
;=========================================================================
[MSFT]
%Passthru_Desc% = Passthru.ndi, ms_passthru
[Passthru.ndi]
AddReg = Passthru.ndi.AddReg, Passthru.AddReg
Characteristics = 0x4410 ; NCF_FILTER | NCF_NDIS_PROTOCOL !--Filter Specific--!!
CopyFiles = Passthru.Files.Sys
CopyInf = netsf_m.inf
[Passthru.ndi.Remove]
DelFiles = Passthru.Files.Sys
[Passthru.ndi.Services]
AddService = Passthru,, Passthru.AddService
[Passthru.AddService]
DisplayName = %PassthruService_Desc%
ServiceType = 1 ;SERVICE_KERNEL_DRIVER
StartType = 3 ;SERVICE_DEMAND_START
ErrorControl = 1 ;SERVICE_ERROR_NORMAL
ServiceBinary = %12%\passthru.sys
LoadOrderGroup = PNP_TDI
AddReg = Passthru.AddService.AddReg
[Passthru.AddService.AddReg]
; ----------------------------------------------------------------------
; Add any miniport-specific parameters here. These are params that your
; filter device is going to use.
;
;HKR, Parameters, ParameterName, 0x10000, "MultiSz", "Parameter", "Value"
;HKR, Parameters, ParameterName2, 0x10001, 4
; ----------------------------------------------------------------------
; File copy
;
[SourceDisksNames]
1=%DiskDescription%,"",,
[SourceDisksFiles]
passthru.sys=1
[DestinationDirs]
DefaultDestDir = 12
Passthru.Files.Sys = 12 ; %windir%\System32\drivers
[Passthru.Files.Sys]
passthru.sys,,,2
; ----------------------------------------------------------------------
; Filter Install
;
[Passthru.ndi.AddReg]
HKR, Ndi, HelpText, , %Passthru_HELP%
; ----------------------------------------------------------------------
; !!--Filter Specific--!!
;
; Note:
; 1. Other components may also have UpperRange/LowerRange but for filters
; the value of both of them must be noupper/nolower
; 2. The value FilterClass is required.
; 3. The value Service is required
; 4. FilterDeviceInfId is the InfId of the filter device (miniport) that will
; be installed for each filtered adapter.
; In this case this is ms_passthrump (refer to netsf_m.inf)
;
HKR, Ndi, FilterClass, , failover
HKR, Ndi, FilterDeviceInfId, , ms_passthrump
HKR, Ndi, Service, , Passthru
HKR, Ndi\Interfaces, UpperRange, , noupper
HKR, Ndi\Interfaces, LowerRange, , nolower
HKR, Ndi\Interfaces, FilterMediaTypes, , "ethernet, tokenring, fddi, wan"
[Passthru.AddReg]
; The following key is Required
; The following key is Passthru specific
HKR, Parameters, Param1, 0, 4
; ----------------------------------------------------------------------
[Strings]
Msft = "Microsoft"
DiskDescription = "Microsoft Passthru Driver Disk"
Passthru_Desc = "Passthru Driver"
Passthru_HELP = "Passthru Driver"
PassthruService_Desc = "Passthru Service"
The issue was caused due to a change in the Manufacturer's section.
Since Windows 2003 SP1, driver's INF files must contain the operating system's version (x86 or 64 versions).
INF Models Section
Important Starting with Windows Server 2003 SP1, INF files must
decorate models-section-name entries in the INF Manufacturer section,
along with the associated INF Models section names, with .ntia64 or
.ntamd64 platform extensions to specify non-x86 target operating
system versions. These platform extensions are not required in INF
files for x86-based target operating system versions or non-PnP driver
INF files (such as file system driver INF files for x64-based
architectures). Each entry in a Models section is sometimes called a
driver node.
Sample INF Models Sections for One or More Target Operating Systems
[Manufacturer]
%Msft% = Msft, NTx86.6.0, NTamd64.6.0
; ----------------------------------------------------------------------
; Models Section
; ----------------------------------------------------------------------
;For Windows 2000 and Windows XP
[Msft]
%NetVMini.DeviceDesc% = NetVMini.NTx86.ndi, root\NetVMini ; Root enumerated
%NetVMini.DeviceDesc% = NetVMini.NTx86.ndi, {b85b7c50-6a01-11d2-b841-00c04fad5171}\NetVMini ; Toaster Bus enumerated
;For Windows Vista and later
[Msft.NTx86.6.0]
%NetVMini.DeviceDesc% = NetVMini.NTx86.ndi, root\NetVMini ; Root enumerated
%NetVMini.DeviceDesc% = NetVMini.NTx86.ndi, {b85b7c50-6a01-11d2-b841-00c04fad5171}\NetVMini ; Toaster Bus enumerated
[Msft.NTamd64.6.0]
%NetVMini.DeviceDesc% = NetVMini.NTamd64.ndi, root\NetVMini ; Root enumerated
%NetVMini.DeviceDesc% = NetVMini.NTamd64.ndi, {b85b7c50-6a01-11d2-b841-00c04fad5171}\Ne
Here's my linker script:
MEMORY {
text (rx) : ORIGIN = 0x000000, LENGTH = 64K
data (rw!x) : ORIGIN = 0x800100, LENGTH = 0xFFA0
}
SECTIONS {
.vectors : AT (0x0000) { entry.o (.vectors); }
.text : AT (ADDR (.vectors) + SIZEOF(.vectors)) { * (.text.startup); * (.text); * (.progmem.data); _etext = .; }
.data : AT (ADDR (.text) + SIZEOF (.text)) { PROVIDE (__data_start = .); * (.data); * (.rodata); * (.rodata.str1.1); PROVIDE (__data_end = .); } > data
.bss : AT (ADDR (.bss)) { PROVIDE (__bss_start = .); * (.bss); PROVIDE (__bss_end = .); } > data
__data_load_start = LOADADDR(.data);
__data_load_end = __data_load_start + SIZEOF(.data);
}
And this is my initialization code. init is called at reset.
.section .text,"ax",#progbits
/* Handle low level hardware initialization. */
.global init
init: eor r1, r1
out 0x3f, r1
ldi r28, 0xFF
ldi r29, 0x02
out 0x3e, r29
out 0x3d, r28
rjmp __do_copy_data
rjmp __do_clear_bss
jmp main
/* Handle copying data into RAM. */
.global __do_copy_data
__do_copy_data: ldi r17, hi8(__data_end)
ldi r26, lo8(__data_start)
ldi r27, hi8(__data_start)
ldi r30, lo8(__data_load_start)
ldi r31, hi8(__data_load_start)
rjmp .L__do_copy_data_start
.L__do_copy_data_loop: lpm r0, Z+
st X+, r0
.L__do_copy_data_start: cpi r26, lo8(__data_end)
cpc r27, r17
brne .L__do_copy_data_loop
rjmp main
/* Handle clearing the BSS. */
.global __do_clear_bss
__do_clear_bss: ldi r17, hi8(__bss_end)
ldi r26, lo8(__bss_start)
ldi r27, hi8(__bss_start)
rjmp .L__do_clear_bss_start
.L__do_clear_bss_loop: st X+, r1
.L__do_clear_bss_start: cpi r26, lo8(__bss_end)
cpc r27, r17
brne .L__do_clear_bss_loop
The problem is that the initialization code hangs sometime during the copying process. Here's an edited dump of my symbol table, if it's helpful to anyone.
00000000 a __tmp_reg__
...
00000000 t reset
...
00000001 a __zero_reg__
...
0000003d a __SP_L__
...
00000074 T main
0000009a T init
000000ae T __do_copy_data
000000c6 T __do_clear_bss
...
00000446 A __data_load_start
00000446 T _etext
0000045b A __data_load_end
00800100 D __data_start
00800100 D myint
00800115 B __bss_start
00800115 D __data_end
00800115 b foobar.1671
00800135 B ticks
00800139 B __bss_end
C is designed to work on von Neumann architectures. AVR is Harvard based. This means that C expects strings to be in RAM. As a consequence, if you ever take a look at the disassembly for any elf binary that would eventually be copied as a hex to your AVR chip, you will see two sections: __do_copy_data and __do_clear_bss [when required]. These routines, which are added in the linking stages, take care of the basic needs of the C language. As a consequence, what you are seeing here with your pointers is likely that they are pointing to the wrong addresses. In other words, they are either pointing to an address in program space but you are reading from data space [different address bus]. Or you are purposely reading from data space but have not copied the strings over.
See:
avr/pgmspace.h
FAQ: ROM Array and scroll down for strings
and of course, the AVR instruction set as provided by Atmel, especifically, the instruction to copy program memory over to data memory
Edited to reflect new question and comment: Your assembly for both sections look ok to me. I will have to take a look at your linker scripts with closer scrutinity to check if there any funny businesses going on there. Since you are writing a bootloader, do you mind if I ask if you have taken a look at bootloader support on AVR-libc?
http://deans-avr-tutorials.googlecode.com/svn/trunk/Progmem/Output/Progmem.pdf
This document may help to clarify the use of flash/ram memories of AVR.
I actually got it to work. All I had to do was enable reading from and writing to external RAM in the SREG. It was mindblowingly obvious and simple, I know, but it was buried in the data sheet and it was poorly documented.
This resource was helpful, but didn't have any documentation for my chip. If you're having this problem, look in the data sheet for your AVR and see how it is related. The process is not the same for all variations of AVRs.
How to use external RAM.