2008-03-21 20:51:42     2008-R1-RC8 and BF532 gotcha

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

2008-03-21 20:51:42     2008-R1-RC8 and BF532 gotcha

David Rowe (AUSTRALIA)

Message: 52899    Hi,

 

I just did a little work on porting uClinux-dist-2008R1-RC8 to the IP04 IP-PBX which uses a BF532.   To get the system to boot, under Blackfin Processor Options -> Blackfin Kernel Optimizations I had to uncheck:

 

[ ] Locate cacheline_aligned data to L1 Data Memory

 

Before I figured this out on the stack trace of the dud boots I could see l1_sram_free being called, which was causing the kernel to choke as there is no L1 sram available on the BF532 with the D-cache enabled.

 

Looking at the makemenu_config help it seems this option depends on !BF531, perhaps this should be !BF532 as well?

 

BTW a simple path I have for porting new uClinux-dist version to the BF532 - I start with a BF533 STAMP config - this usually boots as-is, I just need to change the clock frequency.  I then gradually fold in the other IP04 patches and linux-2.6.x.config and config/.config options.

 

Thanks,

 

David

 

 

 

QuoteReplyEditDelete

 

 

2008-03-21 21:51:18     Re: 2008-R1-RC8 and BF532 gotcha

Robin Getz (UNITED STATES)

Message: 52900    David:

 

Yes - the BF533 has more L1 data than the 532.

 

http://docs.blackfin.uclinux.org/doku.php?id=cache_management&s=bf532#differences_between_l1_sram_and_cache

 

The option would be to unselect 16k of cache (and allow it to be used as SRAM), or turn off some of the things that are located in SRAM. - which are dependant on the load.

 

I'll see if I can come up with something a little smarter. (without having a nightmare in Kconfig).

 

-Robin

QuoteReplyEditDelete

 

 

2008-03-21 22:36:48     Re: 2008-R1-RC8 and BF532 gotcha

David Rowe (AUSTRALIA)

Message: 52901    Actually for the 532 I think we have a choice of 32k D-cache/no L1 RSAM or no D-cache/32k L1 SRAM.  Looking at the data sheet there doesn't appear to be a 16k/16k option for D-memory.

QuoteReplyEditDelete

 

 

2008-03-21 22:44:56     Re: 2008-R1-RC8 and BF532 gotcha

Mike Frysinger (UNITED STATES)

Message: 52902    i dont think there is a clean option for us.  the only clean option would be a link failure, but that gets back to the topic of us having to extend the linker script language to allow LENGTH to be declared.  the only other clean solution imo would be ld to warn about the overflow and have it spill into the .data section, but i'm not sure ld can realistically handle that case today (if ever).

QuoteReplyEditDelete

 

 

2008-03-21 22:46:08     Re: 2008-R1-RC8 and BF532 gotcha

Mike Frysinger (UNITED STATES)

Message: 52903    i dont suppose things could get folded back sanely into mainline so you dont need an external patchset ?  at least the board files would be easy ...

QuoteReplyEditDelete

 

 

2008-03-22 01:06:49     Re: 2008-R1-RC8 and BF532 gotcha

David Rowe (AUSTRALIA)

Message: 52906    Sure Mike I would be happy to work with you on folding the basic IP04/IP08 support into the mainline.  My 2008R1-RC8 patches will need a little cleaning up, I have attached them as a starting point.  Maybe we can work on this outside the list - feel free to email me direct.

 

Cheers,

 

David

 

 

 

ip04-2008.patch

QuoteReplyEditDelete

 

 

2008-03-22 08:30:41     Re: 2008-R1-RC8 and BF532 gotcha

Mike Frysinger (UNITED STATES)

Message: 52919    so is your board actually "bf1" or did you just copy that too ?  first thing would be for you to start declaring your own board properly and then we can merge those pieces ASAP.

 

basically the steps laid out here:

http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:customizing_for_your_board

 

then we can chat about how to merge the other pieces ... somethings we'll have to do on our side to make it easier for board porters (like map support for the bfin_nand.c driver)

QuoteReplyEditDelete

 

 

2008-03-22 09:52:56     Re: 2008-R1-RC8 and BF532 gotcha

Robin Getz (UNITED STATES)

Message: 52921    David:

 

Nope - there are 2 banks of D-cache on the 532 (A & B), with individual bits for control in the control registers to select the cache or SRAM option. This gets exposed as a kernel option under Blackfin settings -> Cache support -> " [ ] Enable only 16k BankA DCACHE - BankB is SRAM".

 

For most loads - cache selection is better, but we had at least a few people tell us that for hard real time, they needed the extra SRAM.

 

Thanks

-Robin

 

QuoteReplyEditDelete

 

 

2008-03-22 10:05:20     Re: 2008-R1-RC8 and BF532 gotcha

Robin Getz (UNITED STATES)

Message: 52922    Mike:

 

What I was thinking of (which isn't exactly clean) is putting some parts of include/asm-blackfin/mach-bfxxx/mem_map.h into a new file - include/asm-blackfin/mach-bfxxx/Kconfig.mem_map - so in arch/blackfin/Kconfig we could source "include/asm/mach/Kconfig.mem_map" - which would not provide any options, just set some L1_DSIZE and L1_ISIZE based on other configs.

 

Actually, the more I think about it, the more I realize that sucks in general.

 

How about something in the arch/blackfin/Makefile that just runs a quick size test (similar to checking the length of the bss section we use to do in ./vendors/...), and #errors out if things are too big for the given chip.

 

I think that might be better?

 

-Robin

QuoteReplyEditDelete

 

 

2008-03-22 13:42:05     Re: 2008-R1-RC8 and BF532 gotcha

Mike Frysinger (UNITED STATES)

Message: 52925    i think that'd be the same result as if we add LENGTH to section outputs.  doing this wouldnt be terribly difficult i dont think, and if the end goal here is a compile/link failure, i think that's the best route.

QuoteReplyEditDelete

 

 

2008-03-22 15:03:42     Re: 2008-R1-RC8 and BF532 gotcha

David Rowe (AUSTRALIA)

Message: 52927    The IP04 uses the bf1.c board definition file as the two designs are very close.  The IP04 was derived from the BlackfinOne V2 design and shares many of the peripherals, although a few of the addresses vary.  OK I will rename it to ip04.c

 

Another known issue is that I currently use the BF533 STAMP System type in <code>arch/blackfin/mach-bf537/boards/Kconfig</code>, I will need to make this BF532_IP04 and work through what this breaks.

 

I have also attached the vendors/Rowetel/IP04 directory for review.

 

Thanks,

 

David

IP04-2008.tgz

QuoteReplyEditDelete

 

 

2008-03-22 19:29:01     Re: 2008-R1-RC8 and BF532 gotcha

David Rowe (AUSTRALIA)

Message: 52928    Mike - have renamed bf1.c to ip0x.c (x means it supports both ip04 and ip08), and added a BFIN532_IP0X System type.  Have attached that latest patches.  I have also modified the vendors stuff and .configs to match this, also attached.  It uses the same vendors.mk as the STAMPs.  The uImage boots OK, will continue testing over the next few weeks.

 

Suggest we call it vendors/Rowetel/IP0X.

 

Thanks,

 

David

IP04-2008.tgz

ip04-2008.patch

QuoteReplyEditDelete

 

 

2008-03-23 14:36:34     Re: 2008-R1-RC8 and BF532 gotcha

Robin Getz (UNITED STATES)

Message: 52938    Mike:

 

I thought that the length attribute would only work with memory sections - which isn't the way that we do it anymore.

 

http://sourceware.org/binutils/docs-2.18/ld/MEMORY.html#MEMORY

 

I thought when you define things as sections (like we do) - there was no length - although from looking at ./m68knommu/kernel/vmlinux.lds.S - we might be able to combine them? - but then I am not sure if the L1 relocations that we use will then work properly - but there is only one way to find out

 

-Robin

QuoteReplyEditDelete

 

 

2008-03-24 04:34:28     Re: 2008-R1-RC8 and BF532 gotcha

Mike Frysinger (UNITED STATES)

Message: 52961    for vendors stuff in uclinux-dist, we just say go ahead and commit it.  the config.linux-2.6.x file though should be moved to the linux-2.6.x/arch/blackfin/configs/ directory accordingly though ...

 

i'll look at merging some pieces of the boards for the kernel

QuoteReplyEditDelete

 

 

2008-03-24 04:36:57     Re: 2008-R1-RC8 and BF532 gotcha

Mike Frysinger (UNITED STATES)

Message: 52962    right, that's why i said we'd have to add support so we could use it in output descriptions

 

the problem with utilizing MEMORY sections is that when we use common defines from the kernel, things fall apart as we cant control the load/link addresses

Outcomes