coreboot March 2014

coreboot@coreboot.org

57 participants
180 discussions

Re: [coreboot] Following the instructions on the NXM page causes problems
by ron minnich 15 Mar '14

15 Mar '14

I'll try to fix that, my bad. ron On Sat, Mar 15, 2014 at 11:13 AM, Gregg Levine <gregg.drwho8(a)gmail.com>wrote: > Hello! > Okay, I'll give it a go from there. But the Coreboot page is still up > with the location on the main repository. > ----- > Gregg C Levine gregg.drwho8(a)gmail.com > "This signature fought the Time Wars, time and again." > > > On Sat, Mar 15, 2014 at 2:10 PM, ron minnich <rminnich(a)gmail.com> wrote: > > NxM is done. We took it down last year. > > It's no longer available via coreboot.org > > > > If you're still interested in giving it a try, > > > > > > https://github.com/rminnich/NxM > > > > > > > > > > On Sat, Mar 15, 2014 at 10:49 AM, Gregg Levine <gregg.drwho8(a)gmail.com> > > wrote: > >> > >> Hello! > >> I just tried to retrieve the latest NXM code via git. Instead of > >> seeing the usual things happen when the tool started working, I saw > >> instead an HTTP 502 error message. It translated it as bad gateway. > >> And even trying to click on the link to bring it up in the browser > >> (Chrome) caused that to happen. > >> ----- > >> Gregg C Levine gregg.drwho8(a)gmail.com > >> "This signature fought the Time Wars, time and again." > >> > >> -- > >> coreboot mailing list: coreboot(a)coreboot.org > >> http://www.coreboot.org/mailman/listinfo/coreboot > > > > >

1 0

Re: [coreboot] Following the instructions on the NXM page causes problems
by Gregg Levine 15 Mar '14

15 Mar '14

Hello! Okay, I'll give it a go from there. But the Coreboot page is still up with the location on the main repository. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again." On Sat, Mar 15, 2014 at 2:10 PM, ron minnich <rminnich(a)gmail.com> wrote: > NxM is done. We took it down last year. > It's no longer available via coreboot.org > > If you're still interested in giving it a try, > > > https://github.com/rminnich/NxM > > > > > On Sat, Mar 15, 2014 at 10:49 AM, Gregg Levine <gregg.drwho8(a)gmail.com> > wrote: >> >> Hello! >> I just tried to retrieve the latest NXM code via git. Instead of >> seeing the usual things happen when the tool started working, I saw >> instead an HTTP 502 error message. It translated it as bad gateway. >> And even trying to click on the link to bring it up in the browser >> (Chrome) caused that to happen. >> ----- >> Gregg C Levine gregg.drwho8(a)gmail.com >> "This signature fought the Time Wars, time and again." >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot > >

1 0

Re: [coreboot] Following the instructions on the NXM page causes problems
by ron minnich 15 Mar '14

15 Mar '14

NxM is done. We took it down last year. It's no longer available via coreboot.org If you're still interested in giving it a try, https://github.com/rminnich/NxM On Sat, Mar 15, 2014 at 10:49 AM, Gregg Levine <gregg.drwho8(a)gmail.com>wrote: > Hello! > I just tried to retrieve the latest NXM code via git. Instead of > seeing the usual things happen when the tool started working, I saw > instead an HTTP 502 error message. It translated it as bad gateway. > And even trying to click on the link to bring it up in the browser > (Chrome) caused that to happen. > ----- > Gregg C Levine gregg.drwho8(a)gmail.com > "This signature fought the Time Wars, time and again." > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Following the instructions on the NXM page causes problems
by Gregg Levine 15 Mar '14

15 Mar '14

Hello! I just tried to retrieve the latest NXM code via git. Instead of seeing the usual things happen when the tool started working, I saw instead an HTTP 502 error message. It translated it as bad gateway. And even trying to click on the link to bring it up in the browser (Chrome) caused that to happen. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

1 0

Re: [coreboot] GSoC-2014 Project for Coreboot
by Kevin O'Connor 15 Mar '14

15 Mar '14

On Fri, Mar 14, 2014 at 08:58:01AM -0500, Aaron Durbin wrote: > On Thu, Mar 13, 2014 at 10:15 PM, mrnuke <mr.nuke.me(a)gmail.com> wrote: > > I'm glad you brought that up. I ran into several problems, most of which were > > a result of CBFS's x86-centric design rather than the shortage of SRAM. A lot > > of CBFS callers love to generate map() calls, which means we as the backend > > need to provide the cache where to map that. When I get a map() call to map > > 20+ KiB of romstage into an area of SRAM I must provide, which must not > > overlap the final destination of romstage, I am wasting SRAM. If I only got a > > call to read(), with the destination being the resting place of romstage, that > > would eliminate the SRAM pressure a bit. > > CBFS is definitely not friendly to environments that can't map() the > storage area of the CBFS itself. Beyond that in-storage format with > metadata tightly coupled to the data itself leads to needing to stream > large amounts of data through the working set just to locate the piece > that is desired. CBFS is a neat system for accessing flash that can be linearly mapped into memory. If one has a flash device that can't be mapped into memory, I don't understand why one would want to use CBFS. Trying to adapt CBFS to block devices is going to complicate the CBFS code, and it still isn't going to be a good solution for those block devices. There are a number of filesystems already developed for block devices - why not just use one of them? The coreboot code's interaction with the "filesystem" after memory init (should) largely boil down to load_file(char *name, void *address, int maxsize). Why not just end the abstraction there (ie, on these arm devices, implement a completely different "load_file" function). -Kevin

2 1

MacBook2,1 Wiki Page
by Mono 15 Mar '14

15 Mar '14

fyi, I've started a wiki page about the MacBook. http://www.coreboot.org/Board:apple/macbook21 It is not yet linked anywhere else in the wiki. It contains currents status and known issues. Mono

1 0

Re: [coreboot] CBFS bullfart (forked from GSoC-2014 Project for Coreboot)
by mrnuke 14 Mar '14

14 Mar '14

On Friday, March 14, 2014 12:03:01 PM you wrote: > Just to step back here. > > The flash is 8M. The system has 4G. What do I care if I leak memory? What's > the issue you are solving? > Thank you! You have pointed out the number one issue with this bullfart: that CBFS design is x86-centric. When you're in the bootblock on ARM, before ram is up, and you're leaking 20+ KiB of SRAM, when you only have 40 KiB left for stack + CBFS cache + romstage destination... See where, I'm going? Alex

2 1

Re: [coreboot] CBFS bullfart (forked from GSoC-2014 Project for Coreboot)
by mrnuke 14 Mar '14

14 Mar '14

On Friday, March 14, 2014 02:07:59 PM Aaron Durbin wrote: > I don't recall the "coreboot runs only very briefly." However, once > you do have ram the question is where does one get the ram? I think > you are trivializing the problem -- not impossible, but it's > definitely not just malloc(). > I think we have a malloc() that just increments a free_ram_pointer. Whether this design is appropriate is beyond the scope of the CBFS problem. The malloc question belongs in coreboot core. Alex

1 0

Re: [coreboot] CBFS bullfart (forked from GSoC-2014 Project for Coreboot)
by mrnuke 14 Mar '14

14 Mar '14

On Friday, March 14, 2014 12:23:03 PM Aaron Durbin wrote: >> I found out that keeping track of the last map() pointer allows you to free >> the cache during unmap(), as currently, operations come in map/unap pairs. >> Sadly, this is just an accident of how CBFS core works. This design also >> places the burden of cache management on the backend, which also has to >> deal with whatever device it deals with. A pretty bad abstraction model. > Those map/unmap pairs are only when walking. The following functions > offer no ability to free the used resources in the common case usage > of CBFS_DEFAULT_MEDIA: > > struct cbfs_file *cbfs_get_file(struct cbfs_media *media, const char *name); > void *cbfs_get_file_content(struct cbfs_media *media, const char > *name, int type, size_t *sz); > const struct cbfs_header *cbfs_get_header(struct cbfs_media *media); > > If one is using cbfs with those functions resources are leaked. So CBFS design is really b0rk3d then. I don't think the excuse that coreboot runs only very briefly is valid in this case. > I don't think the cache management is a bad abstraction. It allows for > the backing store to optimize, but I can see the downsides as well. > All this talk is very cbfs-centric, but if something is needing > multiple pieces of data at once from that then those buffers need to > be managed. Either that is done explicitly by the caller or internally > to the storage supplier. The issue is finding a solution that targets > the least common denominator: not everything has a large amount of > memory to play with at the time of cbfs accesses. > map(...) { void *buf = buffer_gen(size); read (offset, buf); return buf } unmap(void * trilulilu) { buffer_free(trilulilu); } And no, you can't use the simple_buffer concept to do this elegantly. Another idea is to abstract this into a buffered_cbfs_reader class, which provides the CBFS backend with buffer management, then calls read(), and only read() on the backend media. static blablabla buffered_reader_memory_map(blablabla) { void *buf = chuck_norris_buffer_create(size); media->context->read(offset, buf); return buf; } static blablabla buffered_reader_unmap(void *blablabla) { chuck_norris_buffer_release(blablabla); } int init_default_cbfs_media(struct cbfs_media *media) { static struct non_mmapped_backed default_backend; default_mmapped_backed_init(&default_backend); media->open = default_backend.open; media->close = default_backend.close; media->map = buffered_reader_memory_map; media->unmap = buffered_reader_unmap; media->read = default_backend.read; media->context = &default_backend; } This is of course just a shim which connects CBFS, Chuck Norris buffer management, and a non-mmapped media backend. The buffer management is not necessarily an easy task, but this is as simple as it gets, given the current CBFS API. But, the difficulty now lies in making chuck_norris_buffer efficient, which is a smaller problem than the initial. OK, this doesn't solve the issue of resource leakage. Here, the CBFS core needs to release its resources. It's a cleanup problem, however, not a trivial one. >> The CBFS core doing map() + memcpy() doubles the resource requirements with >> no real gain. > > I agree, but depending on where those memcpy()'s are happening it is > somewhat minor (which I think is the current reality). I will point > out that cbfs_meda has a read() function. You could have addressed > that with a patch, no? > No. The design of the CBFS core generally assumes mmapped storage is used. That's the same reason you guys had a hard time refactoring the CBFS core back in 2011 for ARM. It's the same reason you guys didn't do the best job at it (no bashing/disrespect meant). It's the same reason we have this awkward caching need, and the same reason I can't fix this with just a simple patch. I estimate more than a dozen patches to do "get romstage from CBFS with only one read()" The Right Way. I actually looked at reducing usage of map(). It's nowhere near as straightforward as it seems. You either break/create inefficient usage on MM, or non-MM media. This is an apple and orange problem, >> > Lastly, the big reason for large map() requests is because we don't >> > have a pipelined lzma path. >> >> Compression is "don't care" for the CBFS core until the stage is >> decompressed. By the time you realize you don't need to decompress, you've >> already map()ed the whole of romstage, which you now need to memcpy() to >> its destination. > > Agreed, but see my list of functions above which are the cause of > that. e.g. cbfs_load_stage() calls cbfs_get_file_content(). That's > your big mapping. However, the compression case I brought up is still > not possible to pipeline because of the lzma infrastructure we have. > That still needs to be addressed. > Remember that "coreboot runs only very briefly"? Once you have RAM up, this excuse becomes valid. So anything in from late romstage onwards can malloc() whatever it pleases, and forget about free()ing it. Since we don't bother with compressed files until ramstage decompression, I don't generally care about such inefficiencies at this point. Short story: There's no use case for optimizing lzma paths. So, if we can somehow figure out how to read(), instead of map() romstage while we're still in the bootblock... >> I only initialize the CBFS mirror once. If the code finds a valid CBFS >> signature in RAM, it skips the whole re-read-this step. > > Duh. I missed this piece: > > if (CBFS_HEADER_MAGIC == ntohl(header->magic)) { > printk(BIOS_ERR, "Already have CBFS master header at %p\n", header); > return 0; > } > I figured optimizations can't hurt :). Alex

3 2

Re: [coreboot] GSoC-2014 Project for Coreboot
by mrnuke 14 Mar '14

14 Mar '14

On Friday, March 14, 2014 09:46:53 AM ron minnich wrote: > In other words, you can design a special case that makes doing a good > design of the general case almost impossible. That's been done too; see > UEFI. :)

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2014