coreboot March 2014

coreboot@coreboot.org

57 participants
180 discussions

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

14 Mar '14

Fucking Kmail is broken. How many times did it reply to the original sender instead of the list? On Friday, March 14, 2014 11:51:54 AM you wrote: > On Friday, March 14, 2014 08:58:01 AM you wrote: > > 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. > > > > On top of that the CBFS API doesn't allow for freeing up of used > > resources. Yes, there is the construct of map() and unmap(), but the > > used API in the code base returns pointers from map() and that means > > there is no way to free up the internal cache. > > 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. > > However, read() doesn't > > solve the map() problem. read() and map() both need memory so in a > > constrained environment w/o memory-mapped access to the CBFS storage. > > The CBFS core doing map() + memcpy() doubles the resource requirements with > no real gain. > > > 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. > > For the non-lzma files read() will work exactly as you described. > > Not for non-lzma stages, which is the relevant bit for the bootblock, before > you get to romstage, where supposedly, you'll have RAM later on. > > I don't care that much anymore about this problem. I found a workaround for > it, but someone else will drop the soap when doing the next little SoC. > > > I noticed in your code [1] you just read in all of the CBFS in-core. > > Or did I misread that? And your init_default_cbfs_media() always > > re-initializes and reads the CBFS again? I take it that function only > > gets called once? Most likely because that is 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. > > > > [1] > > > https://github.com/mrnuke/coreboot/blob/369998920685852246dcae4c3e88b268 > > > c1 > > > c9f2dc/src/cpu/allwinner/a10/bootblock_media.c

2 1

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

14 Mar '14

On Fri, Mar 14, 2014 at 9:23 AM, Naman Govil <namangov(a)gmail.com> wrote: > > > I agree with the long term goal, but from the point of view of a project > in GSoC, is'nt it better for me to implement the block device API first, > and then in the course of time think about the generic device interface? > > > you should do what you think best. Block device APIs are a much-worked-on problem, as are generic device interfaces. The special needs of firmware make them tricky. I prefer generic because it's too easy to work out a block device interface that won't fit into a generic framework -- that's been done, frequently -- but a well designed generic framework will easily accommodate a block device interface -- see Unix or Plan 9. 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. ron

1 0

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

14 Mar '14

Hi All, Sorry if I am a bit OT to this thread, due to my limited knowledge about coreboot CBFS at this stage, but I would like add few points. Firstly, as Alex mentioned If, on the other hand, you have a well designed, unified block dev API, you can select your block device based on some some heuristic to decide which media to boot from. Why is this better? You don't need two implementations of alternate_cbfs, which are extra code size, extra code, and generally look ugly and complicate the code. This was the motivation behind the goal that we had initially set for this particular project, a simple coreboot-specific blockdev API that will allow the block device to interface with the host. Then as Aaron pointed out the issues with CBFS API: like the inability to free resources and internal cache, would'nt it be a good idea to actually implement a new API that could resolve these issues? Also, I would like to ask Ron, he said: I think we need to step back from the small problems just a bit (i.e. generic block device interface) and think about generic device interfaces. It's doable: see Unix. We don't have as broad a range of devices as Unix had to contend with (no paper tape). And we've got tons of different examples to draw from. I agree with the long term goal, but from the point of view of a project in GSoC, is'nt it better for me to implement the block device API first, and then in the course of time think about the generic device interface? Regards, Naman On Fri, Mar 14, 2014 at 8:48 PM, ron minnich <rminnich(a)gmail.com> wrote: > > > > On Fri, Mar 14, 2014 at 8:14 AM, Patrick Georgi <patrick(a)georgi-clan.de>wrote: > >> Am Freitag, den 14.03.2014, 08:07 -0700 schrieb ron minnich: >> > There's not much point in fighting the tide here. The idea of >> linux-as-bios >> > was nice, but we have come to the point where linux-as-bios requires a >> > small firmware kernel just to load it. >> Which could just as well be UEFI. >> >> > we've walked this argument many times. > > I have a real problem with UEFI, namely, that the code is badly designed, > and badly implemented, and badly written. I can't stand to look at it. It's > the sort of thing that literally gives me a headache. > > Other than that, it's a fine starting point. > > ron > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

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

14 Mar '14

Am Freitag, den 14.03.2014, 08:07 -0700 schrieb ron minnich: > There's not much point in fighting the tide here. The idea of linux-as-bios > was nice, but we have come to the point where linux-as-bios requires a > small firmware kernel just to load it. Which could just as well be UEFI. Patrick

2 1

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

14 Mar '14

On Thursday, March 13, 2014 04:29:06 PM David Hendricks wrote: > On Tue, Mar 11, 2014 at 7:55 AM, Naman Govil <namangov(a)gmail.com> wrote: > > Hi! > > Hi! > Hi! > > a generic interface for > > accessing block devices on ARM SoCs so that coreboot could launch its > > stages from the block devices (an MMC for example). > > Seems interesting, but I am a little bit worried that the project is too > narrow. We updated CBFS about a year ago to allow CBFS content to come from > any media. This was required for the earlier ARM-based platforms which use > SPI ROM since the content was not memory mapped as it is on x86 platforms. > It should be reasonably easy to follow that model using MMC as a backing > media. > The problem is not that CBFS is not easily extendable to incorporate MMC; that's a 100 liner [1]. The problem is creating yet another API for accessing stuff, besides which we'll add an MTD and NAND API, etc. etc. etc. This would make us EFI-ish. > IIRC Alexandru ran into issues with adapting the A10's MMC driver from > u-boot to coreboot and making it fit into the bootblock, which was > constrained by the amount of SRAM available on the A10. I am worried that > you will end up fighting implementation-specific problems on the platform > you choose instead of doing more interesting infrastructure work. > 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. My first solution was to make the CBFS cache and the romstage destination overlap. That needed a trivial change in CBFS, but that patch dropped the soap for various reasons. The alternate_cbfs implementation for that was also clumsy and difficult to read. Another problem I almost had was caused by problem #1. Since I needed a ton of RAM for the CBFS cache, I had to initialize RAM in the bootblock. Adding that code almost caused overgrowing the maximum bootblock size. I was getting close to the 24KiB limit with the MMC driver in there as well. I moved a bunch of non-essential stuff to romstage, and optimized the code layout a bit to not compile big bloat in bootblock. If I nuke the MMC debug messages, the bootblock goes under 13KiB, with MMC and raminit. Seems like there's also room for an MTD/NAND driver. So, I hope I killed any worries about "fighting implementation-specific problems on the platform", which brings me back to the awkward design of CBFS. If we go the way of separate API for every possible bootblock media, you can have a Kconfig to select which to boot from. If, on the other hand, you have a well designed, unified block dev API, you can select your block device based on some some heuristic to decide which media to boot from. Make it a GPIO. Why is this better? You don't need two implementations of alternate_cbfs, which are extra code size, extra code, and generally look ugly and complicate the code. I hope I convinced both of you that this is not an easy, trivial problem, and will take a big chunk of GSoC time, as well as tons of dedication to get done right. The purpose is not to hack something together to boot. I already did that in my github branch [2]. The purpose is to Do It Right (TM). Naman, that means that if you pull this off, you'll need to be completely involved with the community for the twelve or so weeks of coding. You'll need to have patches up on gerrit early, take feedback, and involve in lots of discussion about the design. You will often be rewriting patches in the afternoon, in order to conform to the new design ideologies you discussed in the morning. You will repeat this process many times. You'll have to get intimate with the coding standards and ideologies of coreboot. I suggest you demonstrate a profound understanding of the foundation of our coding standards in your application, by correctly formatting any example code included therein. Your goal must be to have your work merged in coreboot master, and your board booting from MMC/SD with that code, by the pencils down date. Alex [1] https://github.com/mrnuke/coreboot/blob/369998920685852246dcae4c3e88b268c1c… [2] https://github.com/mrnuke/coreboot/commits/cubie_mmc

4 3

Re: [coreboot] GSoC-2014 Project for Coreboot
by David Hendricks 13 Mar '14

13 Mar '14

On Tue, Mar 11, 2014 at 7:55 AM, Naman Govil <namangov(a)gmail.com> wrote: > Hi! > Hi! > I am Naman, a junior year college undergrad with interest in Open Source > Hardware-Software Development. > > I have been actively participating in coreboot community (mainly through > the irc) for more than a month now, and have had lots of discussions with > community mentors, while setting up coreboot on QEMU. I have had success > working with basic payloads like the SeaBIOS and FILO. After having a basic > understanding about coreboot, I was fascinated to work and learn more. I > searched and found a project that I would like to do and began to draft my > proposal for it. I am planning to pursue the project "Infrastructure for > Accessing Block Devices on ARM SoCs" as a part of GSoC-2014. I have had > encouraging support from Marc and other community mentors for this. > > Currently, I am in the process of drafting my proposal, and wanted some > assistance on the same. > > I have been able define the goal for the project: a generic interface for > accessing block devices on ARM SoCs so that coreboot could launch its > stages from the block devices (an MMC for example). After discussions with > Alex (mrnuke), I learnt about the existing support for coreboot on > cubieboard, and hence will use this to test the interface. > Seems interesting, but I am a little bit worried that the project is too narrow. We updated CBFS about a year ago to allow CBFS content to come from any media. This was required for the earlier ARM-based platforms which use SPI ROM since the content was not memory mapped as it is on x86 platforms. It should be reasonably easy to follow that model using MMC as a backing media. IIRC Alexandru ran into issues with adapting the A10's MMC driver from u-boot to coreboot and making it fit into the bootblock, which was constrained by the amount of SRAM available on the A10. I am worried that you will end up fighting implementation-specific problems on the platform you choose instead of doing more interesting infrastructure work. I needed some assistance on methods for developing the block device > interface. One possibility is to work on the customizing uboot to our > needs. (i.e do something like this: http://linux-sunxi.org/U-Boot#SD_Card) > and create a simple API which would act as a MMC driver. I wanted to know > how could I improve upon this. Or if there are other ways to accomplish > this? > > I also wanted to ask whether I need to widen the goal of the project? And > include some other functionalities? If yes, can I have some suggestions for > the same? Some possibilities could be to have the API such that it can > work in any stage (including bootblock), etc. > Good question. It's been a while since I've looked at this stuff in detail. I'll look at it further and try to add some ideas here. > > Hope to get a feedback on this. :) > > Regards, > Naman Govil > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Friendly reminder: Please just send plain text messages to the list
by Paul Menzel 13 Mar '14

13 Mar '14

Dear coreboot folks, lately even long time contributors started to send messages to the list, which were not just plain text but included an HTML formatted part too. Besides that HTML formatting for text only adds advantage in rare cases, it also increases message size, which is bad in my case, as I only have a 30 MB flat rate on my mobile plan for example. So could you please recheck your email client setting and just send plain text from now on? That would be great. By the way, the Linux kernel mailing list (LKML) scrubs HTML parts by default and even blocks HTML message with no plain text to my knowledge. So it is no unusual policy. Thanks, Paul

3 2

Re: [coreboot] Friendly reminder: Please just send plain text messages to the list
by Philip Prindeville 13 Mar '14

13 Mar '14

You can do this with Mimedefang (hence the name) in the function remove_redundant_html_parts(). Mimedefang is callable from both Postfix and Sendmail, since they both use the libmilter. In this case, though, coreboot is hosted on Google so we wouldn’t have that degree of control. On Mar 13, 2014, at 1:32 PM, Corey Osgood <corey.osgood(a)gmail.com> wrote: > On Mar 12, 2014, at 6:56 PM, Kurt QH1 Qiao <qiaoqh1(a)lenovo.com> wrote: >> What about mail server run a script that convert HTML mail to be plain text mail? > > Most mail clients send html formatted emails as an additional format, > along with the plain text. A script to check for "Content-Type: > multipart/alternative" and, if found, strip the html part of the > message should suffice. If only html is found, reject the email with a > notice to the sender, trying to strip only the html could mess up > other parts of the message. Making the strip an option for mailing > list subscribers would be a bonus. > > -Corey

1 0

答复: Friendly reminder: Please just send plain text messages to the list
by Kurt QH1 Qiao 13 Mar '14

13 Mar '14

What about mail server run a script that convert HTML mail to be plain text mail? Kurt 发件人: coreboot-bounces(a)coreboot.org [mailto:coreboot-bounces@coreboot.org] 代表 ron minnich 发送时间: 2014年3月13日 2:42 收件人: coreboot 主题: Re: [coreboot] Friendly reminder: Please just send plain text messages to the list Works for me, but then what would we talk about :-) ron On Wed, Mar 12, 2014 at 11:38 AM, Peter Stuge <peter(a)stuge.se> wrote: mrnuke wrote: > Why don't we just configure the mail server to reject messages containing > HTML? I'd welcome that policy, and it is common on many lists. //Peter -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

3 2

Re: [coreboot] [Coreboot] About (re)flash BIOS utility
by yu chyuan fu 13 Mar '14

13 Mar '14

Hi Idwer & peter Yes,i already have compile crossgcc utility before 'make menuconfig'. Like Idwer said , The output debug code "0x02" not found from coreboot source code. So i don't have debug direction . My mainboard is company customization by sandybridge platform and flash chip is Winbond W25Q64V 8M Hardware spec please see attached file. So should i need to try use flashrom utility or still use vendors provide flash utility ?? Thanks for your reply and help!! 2014-03-12 19:40 GMT+08:00 Idwer Vollering <vidwer(a)gmail.com>: > > > > 2014-03-12 11:23 GMT+01:00 yu chyuan fu <fuh0826(a)gmail.com>: > > Hi All >> >> I am a novice with coreboot. I successfully build coreboot.rom follow >> www.coreboot.org. >> Now i want to burn it to flash chips. I tried using the vendors provide >> flash utility write to flash chips, it's can write success. >> > > The vendor BIOS bootblock was likely left intact/untouched. > > >> I plug in 0x80 debug card to mainboard then power on, coreboot stop >> working and debug card output code is 0x02. >> > > My guess is that the vendor BIOS' bootblock shows that particular code. > The files behind these links do not include POST code 0x02: > http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=documentation/POS… > and > http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/conso… > > Did you compile crossgcc right before 'make menuconfig'? > > >> I suspect vendors provide flash utility maybe not support coreboot when i >> reference FAQ<http://www.coreboot.org/FAQ#How_do_I_.28re-.29flash_the_BIOS.3F> page >> describe how to flash the BIOS. >> The FAQ page suggest use the universal flash utility called flashrom.So, >> if i don't use flashrom utility write to flash chips , even my >> coreboot.rom is good,it always can't work? >> >> Thanks!! >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
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