search for: 0000h

...extended_dpcd_caps(struct drm_dp_aux *aux, > + u8 dpcd[DP_RECEIVER_CAP_SIZE]) > +{ > + u8 dpcd_ext[6]; > + int ret; > + > + /* > + * Prior to DP1.3 the bit represented by > + * DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved. > + * If it is set DP_DPCD_REV at 0000h could be at a value less than > + * the true capability of the panel. The only way to check is to > + * then compare 0000h and 2200h. > + */ > + if (!(dpcd[DP_TRAINING_AUX_RD_INTERVAL] & > + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT)) > + return 0; > + > + ret = d...

...======= --- /dev/null +++ syslinux-3.80-pre7/modules/poweroff.asm @@ -0,0 +1,86 @@ + absolute 0 +pspInt20: resw 1 +pspNextP: resw 1 + resb 124 +pspCmdLen: resb 1 +pspCmdArg: resb 127 + + section .text + org 0x100 + +_start: + mov ax,5300h ; APM Installation Check (00h) + xor bx,bx ; APM BIOS (0000h) + int 15h + jnc check_sig + + mov bx, msg_notpresent + jmp error + +check_sig: + cmp bx,504Dh ; signature 'PM' + je check_ver + + mov bx, msg_notpresent + jmp error + +check_ver: + cmp ax,0101h ; Need version 1.1+ + jae check_state + + mov bx, msg_notsup + jmp error + +check_st...

Hi, One of our customers uses INT 22h/AX=C to shut down UNDI interface. This interface is documented in http://www.syslinux.org/doc/comboot.txt. The excerpt is shown below: AX=000Ch [2.00] Perform final cleanup Input: AX 000Ch DX derivative-specific flags (0000h = clean up all) Output: None Apparently, device is not shut down based on the description of the problem. I am looking at int22() routine in comboot_call.c. I don't see it processes this request (AX=0xc) at all. Can someone help to clarify this? Thanks! Kevin

...al_edid_checksum); +static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux, + u8 dpcd[DP_RECEIVER_CAP_SIZE]) +{ + u8 dpcd_ext[6]; + int ret; + + /* + * Prior to DP1.3 the bit represented by + * DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved. + * If it is set DP_DPCD_REV at 0000h could be at a value less than + * the true capability of the panel. The only way to check is to + * then compare 0000h and 2200h. + */ + if (!(dpcd[DP_TRAINING_AUX_RD_INTERVAL] & + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT)) + return 0; + + ret = drm_dp_dpcd_read(aux, DP_DP13_DPCD_REV, &...

..._ext[DP_RECEIVER_CAP_SIZE]; + int ret; + + ret = nvkm_rdaux(aux, DPCD_RC00_DPCD_REV, outp->dp.dpcd, DP_RECEIVER_CAP_SIZE); + if (ret < 0) + return ret; + + /* + * Prior to DP1.3 the bit represented by + * DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved. + * If it is set DP_DPCD_REV at 0000h could be at a value less than + * the true capability of the panel. The only way to check is to + * then compare 0000h and 2200h. + */ + if (!(outp->dp.dpcd[DP_TRAINING_AUX_RD_INTERVAL] & + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT)) + return 0; + + ret = nvkm_rdaux(aux, DP_DP13_DPCD_...

...taking over as drive C:, meaning either no FAT partitions on harddisks and removable disks (as the DOS kernel enumerates them) or using the NOPASSANY parameter for MEMDISK. Different output: * ISO9660 found: drive E0 with address 0800h (omitting nopassany) * Nothing found: drive 70 with address 0000h (nopassany specified) My expectation was that only floppydrives and USB/harddisk units would be hidden. (for that matter I'd prefer booting from USB FAT32 yet hide USB drive but not harddisk, but can't have it all). Original Boot order: BIOS -> CD -> Isolinux 4.04 -> Memdisk 4....

...+ * + * APM poweroff module + */ + +#include <stdio.h> +#include <string.h> +#include <com32.h> + +int main() +{ + com32sys_t inregs, outregs; + + memset(&inregs, 0, sizeof inregs); + + inregs.eax.l = 0x5300; /* APM Installation Check (00h) */ + inregs.ebx.l = 0; /* APM BIOS (0000h) */ + __intcall(0x15, &inregs, &outregs); + + if (outregs.eflags.l & EFLAGS_CF) { + printf("APM not present.\n"); + return 1; + } + + if ((outregs.ebx.l & 0xffff) != 0x504d) { /* signature 'PM' */ + printf("APM not present.\n"); + return 1; + } + + if...

Hi, I would like to point out an issue with the enumeration of ISA serial devices in Syslinux. If I interpret the snippet below correctly, Syslinux looks up the device order with the BIOS, while Linux uses the fixed order 3F8,2F8,3E8,2E8. Note that this inconsistency is a real problem, as some motherboards (like e.g. a Supermicro X10DRi with default BIOS settings) have a different order

...rent boards to play with to give you an accurate answer on which SM boards/firmware revisions are affected, but it isn't the first time I have seen something like this. > RBIL MEMORY.LST release 61 starting at line 31: > > --------S-M00400000-------------------------- > MEM 0040h:0000h - BASE I/O ADDRESS OF FIRST SERIAL I/O PORT > Size: WORD > Notes: the BIOS sets this word to zero if is unable to find any serial ports > at the addresses it is programmed to check at boot > DOS and BIOS serial device numbers may be redefined by re-assigning >...

...r customers uses INT 22h/AX=C to shut down UNDI interface. This interface is documented in http://www.syslinux.org/doc/comboot.txt. The excerpt is shown below: > > AX=000Ch [2.00] Perform final cleanup > Input: AX 000Ch > DX derivative-specific flags (0000h = clean up all) > Output: None > > Apparently, device is not shut down based on the description of the problem. I am looking at int22() routine in comboot_call.c. I don't see it processes this request (AX=0xc) at all. > > Can someone help to clarify this? comboot_cal...

...our customers uses INT 22h/AX=C to shut down UNDI interface. This interface is documented in http://www.syslinux.org/doc/comboot.txt. The excerpt is shown below: > > AX=000Ch [2.00] Perform final cleanup > Input: AX 000Ch > DX derivative-specific flags (0000h = clean up all) > Output: None > > Apparently, device is not shut down based on the description of the problem. I am looking at int22() routine in comboot_call.c. I don't see it processes this request (AX=0xc) at all. > > Can someone help to clarify this? comboot_call...

Hi folks! Running a dictionary program I get the following message before I get to the interesting part of the win program: err:int21:DOS3Call int21: unknown/not implemented parameters: int21: AX 5001, BX 01d7, CX 0437, DX 0000, SI 01e0, DI 03e7, DS 03af, ES 0437 wine: Unhandled exception, starting debugger err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x402a4c37

...give you an accurate answer on which > SM boards/firmware revisions are affected, but it isn't the first time I > have seen something like this. > >> RBIL MEMORY.LST release 61 starting at line 31: >> >> --------S-M00400000-------------------------- >> MEM 0040h:0000h - BASE I/O ADDRESS OF FIRST SERIAL I/O PORT >> Size: WORD >> Notes: the BIOS sets this word to zero if is unable to find any serial >> ports >> at the addresses it is programmed to check at boot >> DOS and BIOS serial device numbers may be redefined b...

I have a Dell 1435 system that will not respond correctly to a com32 call to Local boot Int 22h AX=14h DX = 0 This call should not return. It should unload the PXE+UNDI stacks and continue the boot process with the next boot device. This call is working fine for me on an HP DL360G2 and on a Dell PE 850. But, on this Dell 1435 the call is returning from the Int 22h. I am using syslinux 3.51

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

I am working on a Linux-based boot disk for my project (http://unattended.sourceforge.net/), and I have hit a snag. Under Linux 2.6, the kernel (via HDIO_GETGEO) always reports the C/H/S geometry of an IDE drive as X/16/63. But most BIOSes want to use the geometry Y/255/63. Most partitioning tools (including Parted) will take clues from an existing partition table and adapt to the BIOS values.

...-------------------------------- ; ; ID for SYSLINUX (reported to kernel) ; syslinux_id equ 031h ; SYSLINUX (3) version 1.x (1) ; ; Segments used by Linux ; ; Note: the real_mode_seg is supposed to be 9000h, but some device drivers ; hog some of high memory. Therefore, we load it at 7000:0000h and copy ; it before starting the Linux kernel. @@ -1198,20 +1201,24 @@ jz near no_config_file parse_config: call getkeyword jc near end_config_file ; Config file loaded cmp ax,'de' ; DEfault je pc_default cmp ax,'ap' ; APpend je pc_append...

...assumption is based on some material stating that '.' can not be in a short filename. Currently, I would classify this as BETA as it has had testing but only by me. I've been able to successfully handle short filenames, single entry long filenames, multi-entry filenames with an ending 0000h and multi-entry filenames ending on a directory entry line (32 bytes). Positive and negative testing results and constructive criticism are welcome. Based on current head plus the patch that HPA sent on Mon, Jan 12, 2009 at 2:59 PM EST, subject "Re: [syslinux] COMBOOT API: Add calls for dire...

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

..."..." respectively (makes sense with how it's coded. Time for a special case). Currently, I would classify this as BETA as it has had testing but only by me. I've been able to successfully handle short filenames, single entry long filenames, multi-entry filenames with an ending 0000h and multi-entry filenames ending on a directory entry line (32 bytes). Positive and negative testing results and constructive criticism are welcome. Based on current head. Conflicts with my patch for obtaining Full Config File Name. Includes my previous patch for getting current working directo...