Evan Felix wrote:
The Current way to boot a kernel and initrd is to use an option ROM,
Currently, the block infrastructure has this nasty hack that allows you
to set an override of the first sector of the disk (which is the boot
sector). It has the appropriate magic to do this in such a w
The Current way to boot a kernel and initrd is to use an option ROM,
bt it still needs a boot sector to hand to the bios so that it knows
where the code got loaded into ram. This patch makes a fake one just
before its needed.
I never though of the /dev/null trick. :)
Evan
On 7/25/07, Anthony
On 24/07/07, Juergen Lock <[EMAIL PROTECTED]> wrote:
I was under the impression that -append doesnt work, is this wrong?
Also /proc/cmdline on the zaurus is
console=ttyS0 root=/dev/mtdblock2 mtdparts=sharpsl-nand:[EMAIL
PROTECTED](smf),[EMAIL PROTECTED](root),-(home) jffs2_orphaned_inod
Evan Felix wrote:
Folks here is a patch i've made for qemu that adds a memory based
block device, it utilizes memory on the Host side to emulate a block
device.
I often use -hda /dev/null for -kernel/-append.
If you really want to implement a "proper" solution for -kernel/-append,
I think
Folks here is a patch i've made for qemu that adds a memory based
block device, it utilizes memory on the Host side to emulate a block
device.
I've tested this on a few boxes to allow a kernel/initramfs system to
boot without needing a specified block device(it automatically creates
a small one)
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/07/25 16:50:37
Modified files:
hw : usb-ohci.c
Log message:
Fix memory corruption after OHCI reset, by Ed Swierk.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb-ohc
When the USB OHCI controller starts, a periodic end-of-frame routine
writes to a chunk of memory set aside by the device driver. If the
machine reboots or the OS kexecs, the controller continues writing
even though the memory is no longer owned by the device driver,
causing random, mysterious corr
> Hi Clemens,
>
> if you enable "log asm_in,op,op_opt,asm_out" you will see the
> intermediate code used during translation.
>
> The opcodes are generated from the macros you already found in
> softmmu_header.h by target-i386/ops_mem.h included from target-i386/op.c
>
> Hope this helps,
> Eddie
found the functions in target-xxx/ops_mem.h
the macros confused my grepping, but how much more self-speaking can a
filename be *gg* ??
oh well... i found it :-)
Hi Clemens,
if you enable "log asm_in,op,op_opt,asm_out" you will see the
intermediate code used during translation.
The opcodes are generated from the macros you already found in
softmmu_header.h by target-i386/ops_mem.h included from target-i386/op.c
Hope this helps,
Eddie
On Wed, Jul 25, 20
i think to have found it in translate.c:
/* sign does not matter, except for lidt/lgdt call (TODO: fix it) */
static GenOpFunc *gen_op_ld_T0_A0[3 * 4] = {
gen_op_ldub_raw_T0_A0,
gen_op_lduw_raw_T0_A0,
gen_op_ldl_raw_T0_A0,
X86_64_ONLY(gen_op_ldq_raw_T0_A0),
#ifndef CONFIG_USER_ONL
hi!
i tried asking this in the irc but got no answer, hope someone can help me
here :-)
i'm working on memory-protection for my mather's thesis and have to dig into
qemu memory management... could someone help me here please? i have the
following problem:
i'm trying to understand the dynamic
> Am 24.07.2007 um 15:32 schrieb Clemens Kolbitsch:
> > i'm emulating i386 (what else when using windows *g*) [...]
> >
> > just in case someone knows :-)
>
> As far as I recall, in chronological order: alpha, ia64, amd64. ;-)
ok.. ok ... my fault ;-)
13 matches
Mail list logo
