headers
Masao Uebayashi | 1 Jan 2010 06:50
Picon

pmap - VIPT PVF_DIRTY condition in pmap_enter()

pmap_enter() has this:

    892 #ifdef PMAP_CACHE_VIPT
	:
    895         if ((pg->mdpage.pvh_attrs & (PVF_DMOD|PVF_NC)) != PVF_NC)
    896                 pg->mdpage.pvh_attrs |= PVF_DIRTY;
    897         KASSERT((pg->mdpage.pvh_attrs & PVF_DMOD) == 0 || \
		    (pg->mdpage.pvh_attrs & (PVF_DIRTY|PVF_NC)));
    898 #endif

According to the log Rev. 1.185, the intention was to set PVF_DIRTY only for
cached & dirty pages.  The above "if" is equivalent to:

	if ((pg->mdpage.pvh_attrs & (PVF_DMOD|PVF_NC)) == PVF_NC)
		;
	else
		pg->mdpage.pvh_attrs |= PVF_DIRTY;

which means:

	cached? modiified?
	      n          0 -
	      n          1 DIRTY
	      y          0 DIRTY
	      y          1 DIRTY

I think this should be:

	cached? modiified?
	      n          0 -
(Continue reading)

Permalink | Reply | 1 comment |
headers
Masao Uebayashi | 1 Jan 2010 07:41
Picon

Re: pmap - VIPT PVF_DIRTY condition in pmap_enter()

At least the assertion I wrote was wrong.  Please don't try that patch.

Masao

--

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Permalink | Reply | 0 comments |
headers
Mark Davies | 3 Jan 2010 20:29
Picon
Picon

Re: KuroBox Pro support

On Sunday 20 December 2009 01:46:28 KIYOHARA Takashi wrote:
> > What is the current status of KuroBox Pro support?  Middle of last
> > year there were some patches needed.  Have these been incorporated
> > into -current?  5.0_STABLE?
> 
> not yet... ;-<

Is there something holding up the commit?  Is it still being worked on?

I've taken the 20091017 patchset and applied it to current (hat to tweak it 
a little) and have a booting system but it still suffers from the two 
problems mentioned in the "status for Marvell Orion support" thread from 
last March:

* Need to power cycle to reboot.

* After a little bit of usage (pkgsrc building) it panics:

panic: atastart: channel waiting for irq
cpu0: Begin traceback...
0xc269dc58
        scp=0xc269dc58 rlv=0xc269dc30 (0xc269dc30)
        rsp=0xc03914e4 rfp=0xc02328e4
Bad frame pointer: 0xc02328e4
cpu0: End traceback...

cheers
mark
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Fleischer | 8 Jan 2010 23:19
Picon

Re: Initial support for the FriendlyArm Mini2440

Hi again,

I have been working some more with the MINI2440 board and NetBSD.
My patch[1] now provides the following:
- Support for the DM9000 PHY+MAC (16-bit transfer mode only).
- S3C2440 SD Controller (at least non-SDHC cards).
- Very basic usage of the S3C2440 DMA Controller (used by SD Controller driver).
- Some hacks to the S3C24x0 LCD controller driver to support
WSDISPLAYIO_LINESBYTES and HPCFBIO_GCON ioctls.
- Preliminary support for NEC NL2432HC22 3,5" TFT display (the timings
are not quite right).
- S3C2440 Touch Controller, with a simple averaging filter.
- Profiling support (had to replace __set_cpsr_c with an assemby version).
- Event counters to the S3C2xx0 interrupt driver, such that sysstat
can show interrupts.

The touchscreen can be calibrated using the tpctl utility due to the
HPCFBIO_GCON ioctls in the display driver.

Most of the code still needs quite a bit of cleanup, but I thought I
would share it to let people comment on it.

On a somewhat related note, I have successfully compiled and run the
Qt sample programs using the Qt/Embedded  <at>  wscons patch[2] and a bit
of extra hacking.

Cheers,
Paul

[1]: http://xpg.dk/files/File/netbsd/mini2440-20100108.patch
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Litchard | 11 Jan 2010 00:45
Gravatar

attempting to boot gumstix kernel via QEMU

Hi,
    My larger goal is to install a netbsd kernel inside a emulation of
a gumstix machine using QEMU. For now, I just want to get a uboot
prompt. Here's what I tried.

 dd of=cflash.img bs=1k conv=notrunc
if=/home/michael/Downloads/u-boot-connex-400-r1578.bin

lucius# qemu-system-arm -M connex -m 289 -pflash cflash.img
qemu: fatal: Trying to execute code outside RAM or ROM at 0x01000000

R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=00000000 R15=01000000
PSR=400001d3 -Z-- A svc32
Abort (core dumped)

I can't find anything using google that specifically talks about using
qemu on NetBSD to run an emulated gumstix. Guidance for my more
immediate goal,
and perhaps my larger goal would be appreciated.

                                                         Michael Litchard.
Permalink | Reply | 2 comments |
headers
Robin Randhawa | 11 Jan 2010 10:10
Picon

Re: attempting to boot gumstix kernel via QEMU

Hi Michael.

On Sun, Jan 10, 2010 at 11:45:29PM +0000, Michael Litchard wrote:

>  dd of=cflash.img bs=1k conv=notrunc
> if=/home/michael/Downloads/u-boot-connex-400-r1578.bin
> 
> lucius# qemu-system-arm -M connex -m 289 -pflash cflash.img
> qemu: fatal: Trying to execute code outside RAM or ROM at 0x01000000

Works for me. I pretty much replicated your setup and got this :

$ ./arm-softmmu/qemu-system-arm -M connex -pflash flash -monitor null
-nographic -s -m 289
pxa2xx_clkpwr_write: CPU frequency change attempt

U-Boot 1.2.0 (Dec 21 2007 - 13:31:10) - 400 MHz - 1578M

*** Welcome to Gumstix ***

DRAM:  64 MB
pflash_write: Unimplemented flash cmd sequence (offset 0000000000000000,
wcycle 0x0 cmd 0x0 value 0x90)
Flash: 16 MB
Using default environment

SMC91C1111-0
pflash_write: Unimplemented flash cmd sequence (offset 0000000000000000,
wcycle 0x0 cmd 0x0 value 0x90)
Net:   SMC91C1111-0
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Litchard | 11 Jan 2010 23:42
Gravatar

Re: attempting to boot gumstix kernel via QEMU

I am using qemu  pkgsrc-current from
20091015. so I suppose an update is in order.

On Mon, Jan 11, 2010 at 9:10 AM, Robin Randhawa
<robin.randhawa <at> gmail.com> wrote:
> Hi Michael.
>
> On Sun, Jan 10, 2010 at 11:45:29PM +0000, Michael Litchard wrote:
>
>>  dd of=cflash.img bs=1k conv=notrunc
>> if=/home/michael/Downloads/u-boot-connex-400-r1578.bin
>>
>> lucius# qemu-system-arm -M connex -m 289 -pflash cflash.img
>> qemu: fatal: Trying to execute code outside RAM or ROM at 0x01000000
>
> Works for me. I pretty much replicated your setup and got this :
>
> $ ./arm-softmmu/qemu-system-arm -M connex -pflash flash -monitor null
> -nographic -s -m 289
> pxa2xx_clkpwr_write: CPU frequency change attempt
>
>
> U-Boot 1.2.0 (Dec 21 2007 - 13:31:10) - 400 MHz - 1578M
>
> *** Welcome to Gumstix ***
>
> DRAM:  64 MB
> pflash_write: Unimplemented flash cmd sequence (offset 0000000000000000,
> wcycle 0x0 cmd 0x0 value 0x90)
> Flash: 16 MB
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Litchard | 15 Jan 2010 00:17
Gravatar

installing netbsd on an emulated connex gumstix.

I've got the u-boot binary running. How do I discover what address the
netbsd kernel expects to boot from?
Permalink | Reply | 4 comments |
headers
Hubert Feyrer | 15 Jan 2010 08:16
Picon
Favicon

Re: installing netbsd on an emulated connex gumstix.


On Thu, 14 Jan 2010, Michael Litchard wrote:
> I've got the u-boot binary running. How do I discover what address the
> netbsd kernel expects to boot from?

Maybe this helps, from src/sys/arch/evbarm/conf/std.gumstix:

 	options         KERNEL_BASE_EXT=0xc0000000
 	makeoptions     LOADADDRESS="0xc0200000"

What emulator do you do this with?

  - Hubert
Permalink | Reply | 1 comment |
headers
Robin Randhawa | 15 Jan 2010 10:06
Picon

Re: installing netbsd on an emulated connex gumstix.

On Thu, Jan 14, 2010 at 11:17:06PM +0000, Michael Litchard wrote:
> I've got the u-boot binary running. How do I discover what address the
> netbsd kernel expects to boot from?

Use objdump on the kernel elf image like so:

$ arm-unknown-linux-gnueabi-objdump -x netbsd-GUMSTIX | less

netbsd-GUMSTIX:     file format elf32-littlearm
netbsd-GUMSTIX
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0xa0200000

Program Header:
    LOAD off    0x00008000 vaddr 0xc0200000 paddr 0xa0200000 align 2**15
         filesz 0x00348d94 memsz 0x00348d94 flags r-x
    LOAD off    0x00358000 vaddr 0xc0550000 paddr 0xa0550000 align 2**15
         filesz 0x0006d35c memsz 0x0006d35c flags rw-
    LOAD off    0x003bd380 vaddr 0xc05bd380 paddr 0xc05bd380 align 2**15
         filesz 0x00000000 memsz 0x0005223c flags rw-
private flags = 602: [APCS-32] [VFP float format] [software FP] [has entry point]

<snip>

This indicates that the physical address that the image expects to at is
0xa0200000.

Here's a short excerpt from some mostly self explanatory and quick
experimentation that should be of help:
(Continue reading)

Permalink | Reply | 1 comment |

Gmane