[#4536] earlyprintk not early enough

Document created by Aaronwu Employee on Aug 29, 2013
Version 1Show Document
  • View in full screen mode

[#4536] earlyprintk not early enough

Submitted By: Mike Frysinger

Open Date

2008-10-16 10:28:02     Close Date

2009-06-29 15:19:24

Priority:

Low     Assignee:

Robin Getz

Status:

Closed     Fixed In Release:

N/A

Found In Release:

2008R1-RC8     Release:

Category:

N/A     Board:

N/A

Processor:

ALL     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Fixed

Uboot version or rev.:

    Toolchain version or rev.:

any

App binary format:

N/A     

Summary: earlyprintk not early enough

Details:

 

if you boot a kernel that uses the uClinux MTD map for a rootfs but there is no filesystem actually attached, then the kernel calls panic() ... but nothing is output the UART (running at 115200 baud)

 

Follow-ups

 

--- Robin Getz                                               2009-06-26 08:25:47

Since the default MTD_UCLINUX has no magic number, we just blindly

read 8 past the end of the kernel's image, and look at it.

When no image is attached, mtd_size is set to a random number, and we were

doing crazy things. Now we do some basic sanity checks before operating on

things

 

Fixed on trunk.

 

 

--- Mike Frysinger                                           2009-06-29 15:19:24

seems to be OK now

 

--- Robin Getz                                               2009-06-29 17:37:01

I followed things (in my head) a little more - the cause of the actual hang was

in :

__dma_memcpy()

 

        while (!(bfin_read_MDMA_D0_IRQ_STATUS() & DMA_DONE))

                if (bfin_read_MDMA_S0_CONFIG())

                        continue;

                else

                        return;

 

We never check DMA_ERR. If ERR - DMA_DONE is never set - so we spin here

forever...

 

Since there are no semantics for memcpy() failing - I'm not sure what the

"right" thing to return is - the only thing to do would be to panic

(which would suck).

 

-Robin

 

-Robin

 

--- Mike Frysinger                                           2009-06-29 17:52:54

well, we check NULL in places, but by and large, having dma_memcpy() and

isram_memcpy() return NULL never happens unless it's bad.  and we should call

panic in that case.

 

probably makes sense to change our memcpy functions to not return anything and

if things do fail, we panic()

 

and our dma_memcpy() functions should handle DMA_ERR

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes