Hi Jaben, On 8 February 2016 at 19:35, Carsey, Jaben <[email protected]> wrote: > I think that the changes look fine. >
Unfortunately, this patch crashes my board when Shell runs startup.nsh. I have yet to track down what part of the patch is causing the problem, but I see this: Press ESC in 1 seconds to skip startup.nsh or any other key to continue. Shell> eh of??pa??8 ASSERT [BootMonFs] /working/platforms/uefi/edk2/MdePkg/Library/BaseLib/String.c(1066): *Source < 0x100 Or, on another board: FS5:\> type startup.nsh echo -off echo Juno startup.nsh from NOR flash echo Example command to start the kernel: echo norkern dtb=board.dtb initrd=ramdisk.img console=ttyAMA0,115200n8 root=/dev/sda2 rw rootwait earlyprintk=pl011,0x7ff80000 debug user_debug=31 androidboot.hardware=juno loglevel=9 sky2.mac_address=0xAA,0xBB,0xCC,0xDD,0xEE,0xFF FS5:\> startup.nsh FS5:\> eh of??pa??8 ASSERT [BootMonFs] /working/platforms/uefi/edk2/MdePkg/Library/BaseLib/String.c(1066): *Source < 0x100 > Note that we have switched to GIT for our source control. This would be must > better as a series of 3 or 4 changes. I had to manually edit all of the 3 > diff files (modified ones attached) to get them to be merged in. There was > "too much path" as you did the file path from above the root of the revision > controlled system. > Jaben, the changes have been committed with you as the author. I can see why that happened, saying as you committed them from diffs. For future reference, when you do a git commit, you can specify "--author "First Last <first.last@domain>" and the author will be set accordingly. It also looks like your GIT setup could do with a tweak also: your name is in lower case now, where it was mixed case previously. No big deal, but I'm guessing you don't want that. > There are additional changes required before this is committed. You need to > update the INF files for the library and the shell itself and change the > revision minor by +1. > I see you made the +1 mod yourself before pushing out. Cheers, Ryan. > -Jaben > > > From: [email protected] [mailto:[email protected]] > Sent: Monday, February 08, 2016 11:03 AM > To: Carsey, Jaben <[email protected]> > Cc: Qiu, Shumin <[email protected]> > Subject: RE: [edk2] [PATCH] ShellPkg Fix ASCII and UNICODE file pipes > Importance: High > > Strange. I didn't see them on the mailing list posting, but I assumed the > list had stripped > them. They are attached to the message that is in my outbox. I'll just blame > Outlook and > say that for no particular reason, it decided to cause trouble. :) > > I have attached them here too. Hopefully you'll get them this time. > > Regards, > Jim > > -----Original Message----- > From: Carsey, Jaben [mailto:[email protected]] > Sent: Monday, February 08, 2016 12:50 PM > To: Dailey, Jim > Cc: Carsey, Jaben > Subject: RE: [edk2] [PATCH] ShellPkg Fix ASCII and UNICODE file pipes > > I don't see any attachments... > >> -----Original Message----- >> From: edk2-devel [mailto:[email protected]] On Behalf Of >> [email protected]<mailto:[email protected]> >> Sent: Monday, February 08, 2016 9:45 AM >> To: [email protected]<mailto:[email protected]> >> Cc: Carsey, Jaben ; Qiu, Shumin >> >> Subject: [edk2] [PATCH] ShellPkg Fix ASCII and UNICODE file pipes >> Importance: High >> >> ShellPkg: Fix ASCII and UNICODE file pipes. >> >> Fix various errors when piping a UNICODE or ASCII file to a simple >> shell application that reads standard input and writes it to standard output. >> >> 1) When the memory file is created by CreateFileInferfaceMem() to >> capture the pipe output, no UNICODE BOM is written to the memory file. >> Later, when the memory file is read by the application using >> ShellFileHandleReadLine(), the function indicates that the file is ASCII >> because there is no BOM. >> >> 2) If the file is piped as ASCII, the ASCII memory image is not >> correctly created by FileInterfaceMemWrite() as each ASCII character >> is followed by '\0' in the image (when the ASCII data is written to >> the memory image, the file position should only be incremented by half the >> buffer size). >> >> 3) ShellFileHandleReadLine() does not read ASCII files correctly >> (writes to Buffer need to be cast as CHAR8*). >> >> 4) FileInterfaceMemRead() and FileInterfaceMemWrite() as somewhat hard >> to read and difficult to debug with certain tools due to the typecasting of >> This. >> Added a local variable (MemFile) of the correct type to these >> functions and used it instead of This. >> >> Enhancement: ShellFileHandleReadLine() now returns EFI_END_OF_FILE >> when appropriate. >> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Jim Dailey >> >> (diff files attached) >> >> >> _______________________________________________ >> edk2-devel mailing list >> [email protected]<mailto:[email protected]> >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
